Iaddressbook für WordPress

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!

Die Unterlassungen der Theme-Designer

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. 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 ausdruckt, 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)

Recently Updated Pages

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 🙂

Make it Blason

Ich liebe Mikro-Plugins! Z.B. Change Attachment Parent (http://lacquerhead.ca/2009/07/change-attachment-parent/)> von Joel Sholdice, es hat nur 30 Zeilen Code, davon gehören 8 zum Header und zwei sind auskommentiert1 ; ideal um sich bestimmte Techniken an zueignen, da kein Ballast ablenkt.
Das Plugin bietet die Möglichkeit, ein Attachment an ein beliebiges Post oder Page (sog. Parent) anzuhängen, und fügt dazu dem Algorithmus zum Editieren von Attachments Code hinzu. Dies geschieht mit dem Befehl add_filter, und zwar muss man sich zwei Funktionen überlegen:

  1. Eine, die Formulare anbietet damit der Benutzer seine Daten eingeben kann (attachment_fields_to_edit) und
  2. eine, welche die Eingaben auswertet. attachment_fields_to_save

Auf der Suche war ich nach was ganz anderem, nämlich ein Plugin, mit dem man custom-fields für Attachments bearbeiten kann. Es ist nämlich so, dass meine Wappendaten-Bank in der Weise funktioniert, dass jedem Attachment zum Bild ein paar Custom Fields zugefügt werden, z.B. das Feld “blason”. Hat dieses den Wert 1, so wird es in der Datenbank als Wappen erkannt und in ihr geführt, wenn nicht, ist es ein ganz normales Attachment. Die bisherigen Einträge hatte mir das PHP Migrationsscript erstellt: es ging die in Form von csv Dateien vorliegenden Listen durch und setzte diese Wert mittlels einem Aufruf der Funktion

add_post_meta($id, $field, $new_value, $unique);

Mir fehlte aber noch eine einfache Möglichkeit, weitere Wappen in diese Liste aufzunehmen. Joël’s Plugin inspirierte mich dazu, meinem Heraldik-Plugin, noch (abgespeckt) die folgenden Zeilen hinzuzufügen:

Damit kann ich, wenn ich aus der Media Library ein Bild bearbeite, einfach bei “Blason” einen Haken machen, und schon wird das Bild in der Datenbank als Wappen geführt.
make it a blason

<?php
add_filter('attachment_fields_to_edit', 'add_makeitblason'    , 10, 2);
add_filter('attachment_fields_to_save', 'update_makeitblason' , 11, 2);

function add_makeitblason($form_fields, $post ){
    $id =$post->ID;
    $blason = get_post_custom_values('blason', $id);
    $checked = ($blason[0]==1)?"checked='checked'":'';
    $html    = "<input type='checkbox' name='attachments[$post->ID][blason]'";
    $html   .= "value='1' ".$checked." />" ;
    $form_fields['blason']=array(
        'tr'    =>'',
        'input' =>'html',
        'html'  =>$html,
        'helps' =>"In der Datenbank als Wappen f&uuml;hren?",
        'label' =>'blason?',
        );
    return $form_fields;
}
function update_makeitblason($post, $attachment){
    $id =$post[ID];
    $old_values     = get_post_custom_values('blason', $id);
    if ($attachment['blason']=='1') {
        if (!isset($old_values[0])) {
            //add_post_meta($id, $field, $new_value, false);
            add_post_meta($id, 'blason', 1, true); // it is a blason
        }
        //update_post_meta($post->ID, 'blason', 1, 0);
    }else {
        if (isset($old_values[0])) {
            //delete_post_meta($post_id, $key, $value);
            delete_post_meta($id, 'blason');
        }
    }
   return $post;
}?>

  1. wohl ein früherer Versuch []

Introducing my Plugin: Gallery Gimmicks

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!

Plugin Repository eingerichtet

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:

/wordpress

RunPHP und Exec PHP nun überall abgeschaltet.

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.

Wappendatenbank eingerichtet

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 Admin Panel besteht bereits.

Media Tags könnten helfen

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

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, weiß 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.

Neuer Hausserver

Am Wochenende kam mein Synology DS-209 NAS-Server die ich über Amazon bei JACOB Elektronik GmbH in Karlsruhe gekauft habe. Er ersetzt mir eine Übergangslösung, um von allen Rechnern in meiner Wohnung auf gemeinsame Dateien zugreifen kann.

Bis jetzt bin ich sehr zufrieden. Ich hatte das Produkt über Testbericht.de ausgesucht, wichtig war mir dass es keinen Krach macht. Es ist nicht der erste Hausserver, Ich hatte in Clemency schon mal so eine Lösung, aber der Freecom NAS konnte man nicht im Wohnzimmer behalten, er war viel zu laut!