Mein Plugin “wsl-gallery” löste in letzter Zeit folgendes Fehlverhalten aus: wenn man

• Nicht eingeloggt war (bin ich dauernd, drum fiels mir wohl erst später auf *g*)
• Sich die Bilder in der view “synoptic” betrachtete (Beispiel: )

wurden einem ALLE Kommentare, die es auf der ganzen Website gibt angezeigt, auch die, die nicht zum Posting passten. Das konnte ich nur dadurch abwenden, dass ich in den templates <?php comments_template(); ?> auskommentierte. Nachteil: es konnte auch niemand mehr einen Kommentar auf wiesel.lu abgeben.

Jetzt hab ich den Fehler gefunden. Mir war aufgefallen, dass irgendwie beim Aufruf meiner Funktion die Information, um welche Seite es sich handelt (vermutlich ist sie in der globalen Variablen $id gespeichert) verloren geht. Auch so Funktionen wie edit_post_link(‘(edit)’,”,’ ‘) funktionierten nicht meh richtig. Die Funktion comments_template(); wusste also nicht mehr, zu welchem Post sie die Kommentare rausrücken soll und dachte sich wohl: spuck ich sie eben alle aus.

Nun hab ich, wie gesagt den Fehler gefunden, aber er liegt leider nicht bei mir, so dass ich ihn nur so beheben kann, dass ich auf eine bestimmte Funktionalität verzichte (ein Link zum Editieren der Bildinformation, wenn man eingeloggt ist):

Ich überprüfte in meinem Script mit der Funktion current_user_can() ob ich eingeloggt bin, und diese eigentlich sehr praktische Funktion current_user_can() vernichtet wohl die ID irgendwo.

Die Tage kam jetzt das Upgrade von Wordpress auf 2.9.

Wie üblich habe ich auch dieses Verbesserung eher passiv hingenommen, aber meine Programme nicht erweitert. Bei den Bildern ist ein Feld “Alternate text” hinzugekommen, vielleicht lässt sich das irgendwie nutzen…
Was mir aber auffiel, es gab jede Menge ganz komischer Effekte:

• auf aachen.lu liess sich das menu “plugins” im Administration Panel nicht mehr aufruffen; mod_security schlug Alarm, wenn man dies beabsichtigte.
• Bei mir konnten von Beiträgen die sich über mehrere Seiten spannen (Text durch <!–nextpage–> getrennt) aufgerufen werden, weil die URL irgendwie falsch gebildet wird)
• zudem interferierte diese Version irgendwie ganz komisch mit meinem Programm itm_theme. ES tauchten ALLE Kommentare die es irgendwo gab, dann auf bestimmten Seiten auf. Abhängig war dies, jedoch vom Theme. Schaltete ich das Plugin aus, war alles wieder gut.

Mit 2.9.1 sind diese Probleme behoben. Das ist jetzt schon das zweite Mal dass mir das passiert. Ich hege den Verdacht, dass Wordpress die Gemeinschaft irgendwie als unfreiwillige Beta-Tester benutzt ;-) Ich überlege stark, bei meinen Vereinsauftritten künftig erst ein update auf die Version x.y.1 durchzuführen, und die glatte Version (3.0 z.B.) auszulassen….

A propos Comments, hier noch ein netter Tip auf den ich die Tage aufmerksam wurde:
Hör auf dich selbst zu pingen

[Edit 11.1.2010: ] Leider ist das Problem mit den an der falschen Stelle auftauchenden Kommentaren, beim Benutzen meines hausinternen Plugins wsl-gallery noch nicht gelöst. Diese Kommentare werden von der Wordpress Template Funktion comments_template() ausgespuckt. Vermutlich vergreife ich mich an irgendwelchen globalen Einstellungen. Provisorisch wurde daher die Möglichkeit, auf Pages einen Kommentar abzugeben abgeschaltet, bis ich das Problem gelöst habe.

Letztes Jahr entdeckte ich iaddressbook von Clemens Wacha. Ich brauchte dringend eine Adressbuchsoftware um meine dürftige Hausmacherlösung zu ersetzen, denn die funktionierte hinten und vorne nicht so richtig. Daher sprang ich gleich auf, trotz einiger Nachteile: die gewaltigen Vorteile überwogen.
Ich finde, es ist auch nach wie vor die beste in PHP geschriebene Adressbuchlösung, aber ein großer Haken ist der, dass von meinem Verein außer mir keiner sie benutzt und ich kann es meinen Kollegen nicht verübeln:

1. Die Benutzung ist gewöhnungsbedürftig, sie haben daher Angst Fehler zu machen,
2. vor allem aber hat Iaddressbook seine eigene, umständliche Benutzerverwaltung.

Das Grundproblem der Benutzung von Iaddressbook ist 2): Das Programm geht davon aus, einen ganzen Webauftritt nur für sich alleine zu haben. D.h. ein Comitard der alten Aachener der bei der Pflege der Adressen mitarbeiten muss sich also mit gleich mit zwei Logins rumschlagen, dem für Wordpress und dem für Iaddressbook. Dabei dürfte es kaum einen Verein geben, der sich gleich mehrere Webauftritte zulegt.

Hinzu kommt, dass von allen letztes Jahr von mir als Lösung in Betracht gezogenen Programmen ausgerechnet Iaddressbook kein Update erfahren hat.Die Befürchtung, dass Erweiterungen durch den Autor für mich dann unbenutzbar sind, hielt mich davon ab, es zu adoptieren, anzupassen und selber zu erweitern. So kam es, dass ich für aachen.lu eine Anpassung, parallel zum Code schreiben musste.

Das Logischste wäre also, aus dem Code von Iaddressbook ein Wordpress-plugin herauszuarbeiten. Man könnte den Overhead reduzieren, der nicht mehr benötigt wütde, wie die Datenbankabstraktion, die Nutzerverwaltung etc.

Leider dürfte das nicht so einfach werden. Clemens Wacha rühmt sich zwar, alles sehr modular verfasst zu haben, so dass Zusatzmodule einfach zu schreiben sein müssten, aber Iaddressbook selber als ein Modul zu behandeln (was es sein sollte), wird dadurch erschwert, dass er sehr stark auf globale Variablen mit sehr einfachen Namen gesetzt hat (z.B. DB für Datenbank). So wird sein Code zwar gut lesbar, aber auch aufwendig umzuschreiben, weil ja alles über zig Dateien verteilt ist.

Ich befürchte, ich werde keine Zeit finden, diese Arbeit durchzuführen, aber wenn jemand meiner Leser dies tun würde, meldet euch!

Heute hat ein uralter Bekannter ein Update vermeldet:
Ryan Boren hat seinen Themeswitcher auf die Version 1.0 gebracht. Die wohl wichtigste Neuerung: der Themeswitcher bietet nun ein Widget an, was seine Nutzung sehr stark vereinfacht. Musste man zuvor doch echt in jedem Theme die sidebar.php bearbeiten, und wehe man hatte das bei einem vergessen und ein Leser hatte sich dann zu diesem Theme vorangeklickt…

Das erinnert mich an ein Anliegen, über das ich schon länger gerne mal meckern wollte: Ich wechsele gerne von Zeit zu Zeit das Aussehen meiner Website und lade ein neues Theme auf. Leider muss ich immer wieder feststellen, dass unglaublich viele “Themer” sich zu sehr auf das Design konzentrieren, dabei aber lässliche Sünden der Unterlassung begehen. Es sind nur wenige Code-Zeilen, aber ständig muss ich sie nachführen, bevor das Theme für mich brauchbar ist. Meistens verzichte ich dann lieber gleich darauf, es zu benutzen.

1. Ganz oft wird vergessen, dass es auch Leute gibt, die längere Beiträge verfassen, die sie der Übersicht halber dann mit
   <!−−nextpage−−>

   unterteilen, so dass sie sich dann mittels über mehrere Seiten erstrecken. Das Theme muss dann aber (mindestens) in den Dateien single.php und page.php diese Seitennavigation auch unterstützen. Dies ist aber ganz einfach. Man füge innerhalb der Loop, am besten unterhalb der von the_content() einfach die Zeile:

   <?php link_pages("<p><strong>Pages:</strong> ", "</p>", "number"); ?>

   ein.

2. Wenn ich meine eigenen Seiten inspiziere und da einen Fehler entdecke, will ich diese sofort verbessern können. Dazu möchte ich, sodann ich eingeloggt bin, auch gleich auf Edit (oder ähnliches) drücken können und und nicht erst lange im Admin Panel mich durch die Pages und Posts zu dem entsprechenden Artikel vorwühlen. Das geht aber nur, wenn das Theme das auch unterstützt. Auch dieses Problem kann der Themer mit ganz wenig Code lösen, das Zauberwort heisst hier:
   

   <?php edit_post_link('Edit this entry.', '<p>', '</p>'); ?>

3. 

   navigation beim printen unerwünscht

   Sind sie nie auf die Idee gekommen, dass es Leute gibt, die an einer Website nicht nur das Layout bewundern, sondern den Beitrag vielleicht auch lesen wollen? Und wenn er länger ist, dann druckt man sich das vielleicht auch gerne erst mal aus.
   Wer auf der Suche nach Informationen über den Zeitzonenzähler ist, und den eine Suchmaschine zu mir geschickt hat und sich die Studienarbeit zum Geschichte der Vermittlungstechnik ausdrucken lassen will, möchte nicht, dass die ersten drei Drucksseiten nicht mit einen Kurzaufriss über die Grundbegriffe der Blasonierung verschwendet wissen, weil das Theme auch die Navigation mit ausdrckt, weil der Themer es unterlassen hat, für diesen Fall eine eigenen Datei print.css zu anzulegen, und eine Zeile Code in der Datei header.php unterzubringen:

   <link rel="stylesheet" type="text/css" media="print" href="<?php bloginfo(‘template_directory’); ?>/print.css" />

   Wie Sie gesehen haben, liebe Themer spendiere ich Ihnen auch gleich noch die entsprechende Datei print.css
   (Dank an dieser Stelle übrigens an Scott Wallick und seine http://www.plaintxt.org/ bei dem ich den Tipp gelesen habe)

Vor ein paar Tagen entdeckte ich ein neues Plugin, das ich ausnahmsweise nicht nur ausprobieren, sondern auch verwenden will:

Recently Updated Pages von Ehsanul Haque.

Es macht ungefähr dasselbe wie mein eigenes Recent Post or Pages Widget, ist aber moderner und natürlich auch sophistiquierter. Hintergrund:

Auf wiesel.lu tut sich dauernd was, aber ich verkünde nicht gleich jede Micky Maus Änderung in einem neuen Post. Eher werden alte Beiträge, und hier vor allem Seiten aktualisiert, etwa z.Z. bei der Heraldik. Toll ist, dass man es auch so einstellen kann, dass Änderungen nicht nur auf den Seiten, sondern auch bei den Posts berücksichtigt werden. So kann der Leser leicht verfolgen wo in der letzten Zeit was auf den neusten Stand gebracht wurde. Dies ist auch eine besondere Erleichterung für mich selber, denn seit ich das Lexikon umgestellt habe, so dass jedem heraldischem Begriff (z.B. contre-écartelé) seine eigene Seite zur Verfügung steht ist die Zahl derselben explodiert, die Navigation im Admin Panel wurde reichlich umständlich. Das Plugin müsste noch die Attachments mit einbeziehen, dann wäre es perfekt :-)

Vorige und letzte Woche schrieb ich ein Plugin, das einige Spielereien (ich fand, “Gimmicks” ist noch die beste englische Umsetzung dafür) mit zusammengestellten Bildern betreibt. Es ist kein weiteres Gallery Plugin, erst recht keine “bessere Gallery”, es baut auf der Wordpress Gallery, bzw. den mittels Wordpress hochgeladenen Bildern auf! Wie bei den meisten Plugins die ich schrieb, vermute ich auch für dieses, dass es so speziell auf meine Wünsche zugeschnitten ist, dass ausser mir niemand es nutzen wird. Aber es ist andererseits allgemein genug geschrieben, dass ich

Gallery Gimicks

im am Montag bekannt gemachtem Repository zum Download bereit gestellt habe.

Die Entwicklung

Die Idee entstand natürlich im Rahmen meiner Versuche, meine Heraldikseiten von csv Listen auf datenbankgestütze Lösungen zu portieren. Gallery Gimmicks konnte ich daher auch in erstaunlich kurzer Zeit “entwickeln”, weil es in der Hauptsache nur eine Zusammenstellung ist, von Routinen die bereits existierten aber anders genutzt wurden. So sind die Ansichten “intro, alphabetic, oder Details und synoptic” ja schon sehr lange Teil der meisten meiner heraldischen Listen, wie jener der alten Herrschaftswappen. Neu ist lediglich der Rückgriff auf die eingebauten Funktionen von Wordpress.

Meine Motive

Die erste Version dieses Plugins, war keine andere, als mein demo_attach_link, das ich am 24. August vorgestellt hatte, um die Wirkungsweise der WP Funktion wp_get_attachment_link() zu demonstieren. Dort hatte ich mir ebenfalls eine Kopie der Wordpress Gallery zugelegt und an der rumgefummelt. Die anderen Ansichten ebenfalls darauf umzustellen lag also nahe.
Den definitiven Anstoß dazu aber gab mein Vorhaben, die Media-Tags des Code Devils einzusetzen! Hierzu würde ich gerne wissen, welche Bilder einer Gallery ich schon mit Media Tags versehen habe, und welche noch nicht! im Media-Center wird das zwar auch angezeigt, aber meine Sammlungen entstanden so nach und nach, die Bilder einer Gallery sind mitunter über alle 68 Seiten verteilt (ich hab zur Zeit 1326 Bilder im Center!)
Eine weitere Unzufriedenheit mit dem Media Center ist, dass in diesem die ID’s der Bilder so gut versteckt werden. Mir sind diese aber wichtig!

Eine lustige Anekdote zum Namen noch

Version 0.1. war, schimpfte sich, wie gesagt demo_attach_link, weil sie mehr auch kaum gemacht hat, und Version 0.2 nannte ich erst mal “Gallery Plus”, weil ich dachte, es ist die altbekannte Gallery, plus ein paar Ansichten. Dann sah ich abends

Eigentlich schreibe ich plugins, seit ich Wordpress nutze. “Eigentlich”, weil ich sie immer nur als eine Art Library nutzte, also Funktionen schrieb die Wordpress per aktiviertem Plugin dann zur Verfügung standen. An echte Plugins, welche die Wordpress Schnittstelle nutzen würde traute ich mich nicht ran, erst recht hab ich, von einer Ausnahme abgesehen nie eins veröffentlicht.. Inzwischen sind aber nicht nur meine Kenntnisse grösser sondern auch die Dokumentation von Wordpress deutlich besser geworden, insbesondere die Referenzseite der Funktionen nutze ich sehr gerne.

Meine Methode diese Plugins zu entwickeln ist recht unprofessionell:

1. ich suche mir möglicherweise passende Vorbilder,
2. passe sie an meine speziellen Bedürfnisse an, schneide sie also für den Zweck zurecht, für den ich sie haben wollte.
3. Erst dann versuche ich, sie wieder zu verallgemeinern, so dass sie auch auf anderen Websites, und zu anderen Zwecken genutzt werden können.

Dies kommt daher, dass ich einerseits ja kein Entwickler bin und andererseits aber ein paar Websites “in laufenden Betrieb” habe, und die Anpassungen immer möglichst schnell erfolgen müssen. Am Ende werde ich alle Plugins unter GPL stellen und zum Download zur Verfügung stellen.

Ich sehe mir ein Plugin, oft über Monate gar nicht an, und am Ende weiß ich dann oft selber nicht mehr, wie die Handhabung meiner Software jetzt genau von Statten ging, daher denke ich, es ist an der Zeit sie besser zu dokumentieren. Hauptsächlich deshalb habe ich jetzt den selber geschriebenen Plugins einen Platz nun auf meiner Seite eingeräumt:

http://www.wiesel.lu/wordpress

Auf keinem der von mir aktuell betreuten Websites läuft jetzt noch ein Skript, welches die Ausführung von PHP Code als Teil eines Beitrags erlaubt. Damit geht für mich eine Ära zu Ende.

Ich fand diese Plugins RunPHP und Exec-PHP sehr praktisch, und im Grunde sind sie auch gar nicht schlecht, wenn man sich mal an ihre Macken gewöhnt hat. Aber, neben meinem kleinen Backup Desaster vom letzten Winter hat vor allem die zunehmende Verbreitung von Mod_Security bei allen Hostern hat mir ihren Gebrauch abgewöhnt. Es ist mir einfach zu lästig, den Providern hinterher zu telefonieren mir dieses und jenes Script freizuschalten..

Selber geschriebene PHP Scripte kommen bei mir von nun an in Form von eigenen Plugins zum Einsatz.

Wiesel.lu proudly presents:

Die Wappendatenbank

Und zwar sind jetzt zum jetztigen Zeitpunkt 411 Wappen in der Datenbank und zu jedem dieser Wappen gibt es folgende Angaben.

1. Eine Zeichnung
2. Einen Titel (Name des Trägers)
3. Die Wappenbeschreibung
4. Typ des Wappens (Staatswappen, Gemeindewappen, persönliches Wappen, Familienwappen, usw.)
5. Angaben zur Quelle

Das allerschönste daran ist: es brauchte keine einzige MySQL Tabelle dazu angelegt zu werden, die Wordpressdatenbank reicht dazu völlig aus! Dies ist allerdings nur einer der Ansätze die ich verfolge, denn er hat einen Haken: Es muss zu jedem Wappen bereits eine Zeichnung da sein. Darum sind einige Wappen, wie das von Prince Henri oder die beiden letzten Abtwappen von St. Hubert, noch gar nicht in der Datenbank drin, weil ich eben zu diesen noch keine Zeichnung angefertigt habe. Marnach fehlt auch, mein eigenes Wappen etc.

Die Vorgeschichte

Der Heraldikteil auf wiesel.lu hat sich seit dem Sommer letzten Jahres mächtig entwickelt: Hatte ich bis 2003 nur mein eigenes Wappen hier ausgestellt, kamen 2004 die Gemeindewappen dazu, zu denen ich letztes Jahr jeweils eine eigene Zeichnung fabrizierte, dann kamen die Wappen des Ancien Régimes hinzu, von denen die Gemeindewappen Luxemburgs inspieriert, dann die Abtwappen usw. Ich plane noch, die Wappenrolle der ALGH, von der ich gestern erfuhr dass sie doch noch nicht untergegangen ist, aufzunehmen etc. Bis letztes Jahr, passten die Wappen bequem in eine und später mehrere ,csv Dateien, aber die Ausbaufähigkeit dieser Lösung ist nicht mehr vorhanden. So möchte ich langfristig auch zu jedem Wappen eine Taxonomie angeben, welche Elemente es enthält, vielleicht Statistiken etc.

1. Mein erster Ansatz war eine große gemeinsame CSV Datei, das klappte auch, aber ich will die Wappendatenbank auch browserbasiert bearbeiten können, wenn ich gerade mal kein FTP Programm zur Verfügung habe.
2. Der Versuch, diese große csv Datei in Wp-Tables reinzuladen, bereitete enorme Schwierigekeiten: Die Software kam nicht so recht damit klar, dass die französischen Wappenbeschreibungen so unglaublich viele Komma, Apostroph und Semicolons haben. Aber es gelang.
3. Zufrieden war ich nicht, denn bei den WP-Tables fehlt, anders als bei echten SQL Tabellen, das Feld, das den Datensatz eindeutig macht. Ausserdem werden die Inhalte von WP- “Search” Funktionen nicht erkannt. Bei normalen SQL Tabellen zwar auch nicht.
4. Dann kam mir die Idee, die Mediatags vom Codedevil einzusetzen. Zunächst nur zur Klassifizierung der Meubles. Dann begann ich die Meubles zu taggen. Leider hat Mediatags keine “mass edit” Funktionalität. Zu den Wappen würde ich zur Migration gerne ein Script einsetzen! Die notwendigen Informationen stehen ja bereits in den CSV Files!
5. Dann las ich, dass die attachments in Wordpress eigentlich Posts sind, also im Prinzip auch sogenannte custom fields benutzen könnnten. Und anders als bei den Posts kann ich bein den Attachments die Notwendigkeit dazu durchaus einsehen.

Inzwischen habe ich die Migration durchgeführt, sie wird aber vielleicht noch ein paar mal wiederholt. Auch ein rudimentäres Adim Panel besteht bereits.

Wenn ich meinen Log’s glauben darf, ist wiesel.lu inzwischen für zwei Sachen berühmt:

• die Hesper Kutsch und vorallem,
• für meine Heraldikseiten.

Zu letzteren gehört auch meine Sammlung von Wappenfiguren “die Meubles“. Ich zeichne diese Figuren nach und nach und lade sie dann hoch, wo sie dann in einer Gallery angezeigt werden.

Problem: sie liegen dort kreuz- und quer, Sterne neben, Löwen; pelican neben der quatrefeuille, dem ancre, der quatrefeuille tigée, der balance, oder der Crosse d’Abbé, diese wiederum neben der aigle eployée und diese neben der croix ancrée, halt in der Reihenfolge wie ich sie zeichnete.

Wenn ich (und wohl auch der Leser) mal eine bestimmte Figur suche, weiss ich gar nicht, wo anfangen! Vor ein paar Monaten, hatte ich mir mal die Mühe gemacht und die Bilder etwas geordnet. Dazu benutzte ich die eingebaute Funktionalität der Gallery, mit der man die Bilder in eine bestimmte Reihenfolge bringen kann. Aber erstens sind inzwischen wieder viele dazu gekommen und zweitens ist diese Flash-Funktion von Wordpress nicht unbedingt einfach zu bedienen und auch nicht stabil, wenn es ein paar mehr Bilder werden…

Ein zweiter Lösungsansatz war, neu erstellte Bilder ins Lexikon aufzunehmen. Aber auch das bedeutet, doppelter Aufwand: Die Beschreibungen müssen dann sowohl zum Bild, als auch in der Lexikontabelle erstellt werden!

Abhilfe verspreche ich mir jetzt von dem Plugin Media Tags 2.0 vom Codehooligan Paul Menard aus Austin, Texas. Google half mir ihn zu finden. Das Prinzip ist ganz einfach: jedes Bild kann mit mehreren Tags (so Schildchen) markiert werden. Z.B. wäre der Pelikan
[demo_attach_link id="3421" size="thumbnail"]

sowohl ein “meuble”, ein Vogel, ein Lebewesen, usw. Natürlich bedeutet dies auch einen gewissen Aufwand, so dass der Leser sich noch etwas gedulden muss, bis ihm die neue Ordnung zur Verfügung steht.