Ich dachte mir, bei der Umstellung von PyLucid auf Django 1.4 sollte für den Endanwender auch irgendein Mehrwert rauskommen. Mehr als das es mit einer neueren Version läuft...

In PyLucid sind fast alle Modelle mit django-reversion verknüpft. Aber bisher kann man quasi kaum erkennen welcher Inhalt denn geändert wurde. Ich denke es wäre ganz Sinnvoll eine Art Diff Ansicht zu implementieren.

Leider gibt es in django-reversion nichts out-of-the-box, siehe: https://github.com/etianen/django-reversion/wiki/Generating-Diffs

Bevor ich nun was eigenes mache, dachte ich mir, erweitere ich erstmal django-reversion um eine Allgemeinen Schnittstelle, damit man nicht von Null Anfangen muß. Also hab ich einen branch gemacht: https://github.com/jedie/django-reversion/compare/diff

Damit direkt etwas Nutzbares raus kommt, habe ich eine einfache "Generischen" Diff Ansicht gemacht: Es wird dabei ein difflib.ndiff() über eine Art Serialisierte Daten String gemacht. (wenn Pygments da ist, dann auch in Bund)

Screenshots, wie das ganze z.Z. aussieht, gibt es hier: http://www.pylucid.org/de/about/screenshorts/django-reversion/

Die Idee ist, das der Entwickler nur in seiner von VersionAdmin geerbten Admin Klasse die Methode make_diff() Sinnvoll implementieren muß. Denn ich denke viel mehr als ein diff über ein pformat kann man generisch nicht machen, oder? Sicherlich könnte man das noch weiter Optimieren. z.B. könnte man ein Datetime richtig Formatieren lassen. Aber auch da ist die Frage, ob ein Timedelta interessanter wäre...

Was haltet ihr von dem ganzen? Wer hilft mit?

Sieh auch:

• http://www.python-forum.de/viewtopic.php?f=7&t=29174
• https://github.com/etianen/django-reversion/issues/147

EDIT: Mittlerweile gibt es ein seperates Projekt:

• https://github.com/jedie/django-reversion-compare
• http://pypi.python.org/pypi/django-reversion-compare/

We worked on django v1.4 support in a new branch: https://github.com/jedie/PyLucid/tree/django1.4 But it's not ready, yet. PyLucid run's well, but we would like to test it more...

Note: This here is a public working draft.

The main goals of this release:

• run with new django v1.4 release
• use django.contrib.staticfiles (see below at 'media -> static files')
• add django-reversion-compare

Compare master...django1.4 diff.

↑ how to test  #

Create a test virtual environment with the django1.4 branch, just use the bootstrap file from the branch:

1
2
3
4
5

# get PyLucid boot script:
/home/FooBar$ wget https://raw.github.com/jedie/PyLucid/django1.4/bootstrap/pylucid-boot.py

# Create the PyLucid virtual environment:
/home/FooBar$ python pylucid-boot.py PyLucid_env

See also: http://www.pylucid.org/permalink/333/1a1-create-a-pylucid-environment-with-pylucid-boot

Django git repro: The new repro contains v1.5.x and the "1.4.X" branch does only exist in the old repro, see: https://code.djangoproject.com/ticket/18268
To switch to the old repro, do this:

1
2
3

/home/FooBar/PyLucid_env$ source bin/activate
(PyLucid_env)/home/FooBar/PyLucid_env$ pip uninstall django
(PyLucid_env)/home/FooBar/PyLucid_env$ pip install -e git+git://github.com/django/django-old.git@1.4.X#egg=django

install new dependencies:

1
2

/home/FooBar/PyLucid_env$ source bin/activate
(PyLucid_env)/home/FooBar/PyLucid_env$ pip install django_compressor==dev

These changes are made / steps for update:

Run these south migrations:

1
2
3
4
5

# schena migrations for django-reversion
/var/www/YourSite$ ./manage.py migrate reversion

# migrate new STATIC url prefixes in dbtemplates
/var/www/YourSite$ ./manage.py migrate pylucid

see also: https://github.com/etianen/django-reversion/wiki/Schema-migrations

↑ media -> static files  #

Now we used the django.contrib.staticfiles.

collect all static files:

1
2
3
4
5

# delete or rename the old files:
/var/www/YourSite$ rn media media_old

# To link files add --link to this:
/var/www/YourSite$ ./manage.py collectstatic # --link

Changes related to this:

1
2
3
4
5

- {{ Django_media_prefix }}
+ {{ STATIC_URL }}admin/

- {{ PyLucid_media_url }}
+ {{ STATIC_URL }}PyLucid/

Needed changes in your local_settings.py:

1
2
3
4
5
6
7

- MEDIA_ROOT = "/var/www/YourSite/media/"
+ STATIC_ROOT = "/var/www/YourSite/static/"

- MEDIA_URL = "/media/"
+ STATIC_URL = "/static/"

- ADMIN_MEDIA_PREFIX = "/media/django/"

↑ use django-compressor  #

Add this to your local_settings.py:

1
2

# Use compress js/css data with django-compressor:
COMPRESS_ENABLED = True

Edit your page templates like this, e.g.:
{% sourcecode ext=".diff" %} + {% compress js %} + {% endcompress %} + {% compress css %} + {% endcompress %} {% endsourcecode %}

Ich hab django-sync-server mit dem neuen Firefox v11 getestet und es funktioniert einwandfrei, auch das Syncronisieren der Addons ;)

Ich hab ein kleines Problem mit Suchmaschinen Bots, die meine Webseiten Indexieren.

Mein Blog kann man nach Tags filtern, dabei kann man die Tags kombinieren. Bsp.:

Das Problem: Die Suchmachinen reihen tags an tags und gehen so immer "tiefer", obwohl das natürlich keinen Sinn macht.

Ich habe deswegen mehrere Maßnahmen getroffen:

• Die Tag Filter URLs sind mit rel="nofollow" markiert.
• Die Seiten werden mit <meta content="noindex,nofollow" name="robots"> Ausgeliefert.

Die Änderungen sind nun schon eine weile Aktiv. Es sollte also jede Suchmaschine sie registriert haben. Dennoch Indexieren viele fröhlich weiter.

Deswegen werden Links zu einem weiteren Tag-Filter ab einer frei einstellbaren Anzahl nicht mehr eingebaut. Bsp:

• Die Seite mit 2 Filtern enthält noch Filter-Links: http://www.pylucid.org/de/blog/tags/pylucid/development/
• Diese Seite mit 3 Filtern nicht mehr: http://www.pylucid.org/de/blog/tags/pylucid/development/visible%20changes/

Wird dennoch mehr als 3 Filter verwendet, erhält man einen 500 und das ganze wird geloggt. Kommt es zu oft vor, wird die IP für eine einstellbaren Zeit gebannt.

Doch auch das scheint nicht richtig zu helfen. Deswegen habe ich eine statische robots.txt angelegt: http://www.pylucid.org/robots.txt darin ist u.a.:

Disallow: /de/blog/tags/
Disallow: /en/blog/tags/
Disallow: /*/blog/tags/*

Aber auch das beachten anscheinend nicht alle Bots.

Letztlich sehe ich diese Möglichkeiten:

1. Die Tags nicht mehr per URL, sondern als GET Parameter nutzten
2. Bots per "User Agent" feststellen und für diese überhaupt keine Tag-Filter-Links einbauen
3. Das Filtern nur noch als AJAX view zulässig

Zu 1. Die Frage ist ob das die Suchmaschinen auch wirklich ignorieren. Dazu habe ich in der robots.txt: Disallow: /*? Aber ob das reicht?

Zu 2. Wie erkennen? Man müßte eine ganze Liste an möglichen Strings im User Agent führen. Dann ist dennoch die Frage, ob man damit alle erreicht.

Zu 3. Das wird IMHO noch am besten klappen, wobei Suchmaschinen langsam auch JS beherrschen? Schade ist, das ohne JS kein Filtern mehr Funktionieren würde. Aber naja, wer hat es schon aus?

Meinungen/Ideen dazu?

(Crosspost: http://www.python-forum.de/viewtopic.php?f=5&t=28530 )

EDIT: Dank einiger Tipps aus den Python-Forum, gibt es nun die ersten Änderungen, mit v0.11.2, siehe commit 1267cb:

• Die Tags in der URL werden sortiert. Wenn aktuelle URL nicht "Canonical" ist, gibt es ein Redirect.
• es wird 404 zurück gegeben, wenn ein Tag Filter zuviel in der URL ist, bei mehr als einer zuviel dann wiederum SuspiciousOperation, welches geloggt wird.
• Es werden nur die [+] nicht mehr in der Seite eingebaut, wenn die Anzahl der max. Tag Filtern erreicht wurden.
• Für das alles gibt es nun unittests

Es scheint aber auch so zu sein, das es wirklich Wochen dauern kann, bis alle Bots das schnallen. Denn es schient so das jetzt erst einige der schon vor Tagen gemachten Änderungen ziehen.

↑ 500 Bugfix  #

Wir haben einen dummen Bug mit einigen Commits gefixed:

Man erhält hin und wieder eine 500 Fehler. Man kann scheinbar keine Regel dahinter ausmachen.

Das eigentliche Problem: Wir erstellen IP Ban-Einträge im Model Manager so:

1

self.model(ip_address=remote_addr).save()

...und im Model haben wir das:

1

createtime = models.DateTimeField(auto_now_add=True)

In dem Falle wird oft createtime zu None, keine Ahnung warum... Es kommt zu 500, weil immer davon ausgegangen wird, das es ein Datum ist und nicht None ;) Der Fehler lautet: AttributeError: 'NoneType' object has no attribute 'year'

Nun setzten wir das Datum explizit in save(). Außerdem gibt es temporär einen Work-A-Round, wenn kein Datum existiert. Der kommt aber später wieder weg.

↑ Bugfix in Kommentaren  #

Mit 61e1809 ist ein Bug im Kommentar System gefixed: Ein normaler User erhält einen CSRF Fehler

TODO: Wir müssen noch den Cache löschen, nachdem ein Kommentar geschrieben wurde.

In der Vergangenheit haben wir die Versionsnummern von PyLucid nicht mehr richtig aktualisiert. Für einen sehr langen Zeitraum (24.03.2009 - 29.12.2011) haben wir immer nur v0.9.xxx genommen. Siehe auch: Entstehungs Geschichte von PyLucid

Vorsatz für das neue Jahr: Wir wollen wieder gescheite Versionnummern machen, nach dem Schema:

• major.minor.maintenance.build