Archiv der Kategorie: WordPress

Jetzt wirds mir doch zu dumm: wir basteln uns einen CSV-Importer

Kostenpflichtige Plugins – seh ich doch gar nicht ein!

Wie ich schon mehrfach gesagt habe, habe ich erstens nicht das Budget, mir zu Testzwecken kostenpflichtige Plugins zu kaufen, und zweitens bin ich eine große Anhängerin der Open-Source-Idee. Das ist ja mit der Hauptgrund, warum WordPress so erfolgreich ist, es ist Open Source und kostenlos, es gibt fantastische Supportforen, es gibt für nahezu jedes Programmierproblem eine Lösung, ohne daß man Bares dafür hinlegen muß.

Da alle CSV-Import-Plugins die ich getestet habe in den kostenfreien Versionen keinen Import von Custom Fields können und ich diese Möglichkeit aber unbedingt brauche, gehen wir jetzt einen anderen Weg:

Wir schreiben unseren eigenen CSV-Importer

Ich bleibe dabei beim Beispiel des Turnverein Weiß-Blau mit dem Mitgliederverzeichnis. Die Vorgaben bleiben gleich:

die Adressdaten liegen als CSV-Datei vor (Spezifikation folgt)
für jeden Mitgliederdatensatz soll ein eigener Beitrag angelegt werden
im Beitragstitel brauchen wir die Mitgliedsnummer (ID) und den Namen
die restlichen Adressdaten sollen in Benutzerdefinierte Felder geschrieben werden.

Alles klar soweit? Na, dann wollen wir mal!

Die Spezifikation der CSV-Datei

Ich nehme da mal was ganz Rudimentäres, das kann sich jeder selber mit Excel und im Notepad++ zurechtschnitzen. Pro Datensatz eine Zeile, Zeilenende mit CR/LF markiert, Trennzeichen ein Semikolon (;), kein Textbegrenzungszeichen. Kodierung UTF-8 ohne BOM. Wir haben zehn Datensätze:

import_notepad

Der Anfang: wir basteln uns ein neues Plugin

Das haben wir schon ein paar mal gemacht, das wiederhole ich nur im Schnelldurchgang. Plugin-Verzeichnis anlegen, PHP-Datei anlegen, Header richtig ausfüllen, AdminScreen anlegen:

/*
Plugin Name: Evis CSV Importer
Plugin URI: http://localhost/wordpress/wp-content/plugins/evis-csv_importer
Description: Importiert eine CSV-Datei
Version: 1.0
Author: Evi Leu
Author URI: http://www.evileu.de
*/
add_action('admin_menu', 'evisbasicPluginMenu');

function evisbasicPluginMenu() {
$appName = 'EvisCSVImporter';
$appID = 'evis-csv-importer';
add_menu_page($appName, $appName, 'administrator', $appID, 'importerpluginAdminScreen');
}

function importerpluginAdminScreen() {
    echo "<h1>Importiere CSV Datei</h1>";
}

Import starten mit Button

Zum starten des Imports brauchen wir noch einen Button, den legen wir wie schon oft gehabt mit einem kleinen Formular an, das kommt als erstes in die Funktion importerpluginAdminScreen:

//Begin Formular
echo '<form method="post">';
echo '<input type="submit" name = "starten" value="Import starten"/>'."<br>";
echo "</form>";
// End Formular

if (isset($_POST['starten'])){

...

}

Pfad und Dateiname der Import-Datei fest verdrahtet

In die if-isset-Abfrage legen wir jetzt unsere Import-Funktionalität. Natürlich wäre es schick wenn man hier die Import-Datei mit einem Datei-öffnen-Dialog auswählen könnte, aber dazu brauchts eine Runde Javascript, und das sprengt hier definitiv den Rahmen. Ich machs mir einfach: da ich immer mit der selben Import-Datei arbeite, verdrahte ich den Pfad und den Dateinamen im Code, das kann sich dann jeder selber zurechtbiegen wie er es braucht. Jedenfalls wird die CSV-Datei mit fopen() geöffnet:

//Pfad zur Import-Datei fest verdrahtet
$datei=fopen("C:/xampp/htdocs/alte_programmierer/wp-content/plugins/evis-csv-importer/nur_adressen.csv","r+");

Datei zeilenweise einlesen und Debug-Ausgabe

Dann lege ich eine While-Schleife bis zum Dateiende (feof) an und lese mit fgets() zeilenweise ein. Jede Zeile wird mit explode() am Semikolon in ein Array eingespeist, und damit man gleich mal was sieht, gebe ich dieses Array dann noch zeilenweise aus, das ist nur zum Debuggen und fliegt später wieder raus. Ja, ich hörs schon, das müßte man mit einer for…next i Schleife machen, aber ich finde es so übersichtlicher.

//Begin Importdatei zeilenweise einlesen
while(!feof($datei))
{
    $zeile = fgets($datei);
    echo $zeile."<br>";

    //aktuelle Zeile am Semikolon in Array explodieren
    $arr_akt_zeile = explode(';',$zeile);

    //Debug-Ausgabe des Arrays
    echo $arr_akt_zeile[0]."<br>";
    echo $arr_akt_zeile[1]."<br>";
    echo $arr_akt_zeile[2]."<br>";
    echo $arr_akt_zeile[3]."<br>";
    echo $arr_akt_zeile[4]."<br>";
    echo $arr_akt_zeile[5]."<br>";
    echo $arr_akt_zeile[6]."<br>";
    echo $arr_akt_zeile[7]."<br>";
    echo $arr_akt_zeile[8]."<br>";
} //Ende Importdatei zeilenweise einlesen

fclose($datei);

Am Ende nicht vergessen mit fclose() die Importdatei wieder zu schließen.

(Zwischenbemerkung: ja, ich kenne die Funktion fgetcsv(), die ist aber ein bißchen hakelig in der Bedienung. wir nehmen lieber fgets().)

So, das wars schon mit dem zeilenweisen Import der CSV-Datei. Jetzt müssen wir die eingelesenen Daten noch entsprechend verarbeiten, aber dazu gibt es einen neuen Beitrag.

WordPress als führendes System für das Mitgliederverzeichnis: ein Anfang

Erstmal eine Hypothese

Ich habs ja sonst nicht so mit theoretischen Konstrukten, ich bin eher praktisch veranlagt. Aber der Turnverein Weiß-Blau möchte seine Mitgliederstammdaten in Zukunft mit WordPress verwalten, also an die Arbeit. Ich gehe mal davon aus, daß der Import zumindest der Adressdaten mit Custom Fields geklappt hat und unser bestehender Mitgliederstamm jetzt sauber in den WordPress-eigenen Tabellen abgelegt ist.Notfalls mit einem kostenpflichtigen Plugin, das wars uns jetzt wert.

Erstmal sehen sie: nichts.

Kurz zur Erinnerung: für jedes Mitglied gibt es einen eigenen Beitrag. Im Beitragstitel steht die Mitgliedsnummer und der Name. Im Beitragsinhalt möchten wir die Adressdaten sehen. Wieso möchten? Die haben wir doch importiert? Ja aaaber – nach dem Import sehen wir im Beitrag jetzt erst einmal – nichts. Nur wenn man im Dashboard auf „Alle Beiträge“ geht und da bei einem Beitrag „Bearbeiten“ wählt und dann ein bißchen runterscrollt, dann sieht man die Benutzerdefinierten Felder mit ihren Inhalten.

fridolin_CF

Das ist unser Editor für Bestandsdaten. Wenn sich an den Adressdaten eines Mitglieds etwas ändern sollte, suchen wir uns den entsprechenden Beitrag und gehen in den Bearbeitungsmodus, hier können wir unsere Änderungen direkt einpflegen. Kann ich damit leben, die Benutzer brauchen halt eine kurze Einweisung in den Beitragseditor und sollten auch nicht vergessen auf „Aktualisieren“ zu klicken, dann funktioniert das schon.

Und wenn es neue Mitglieder einzutragen gibt?

Natürlich könnte man einfach in WordPress einen neuen Beitrag erstellen und die Daten manuell eingeben, aber das ist dann schon ein bisschen sperriger in der Benutzerführung. Man muß nämlich die relevanten Benutzerdefinierten Felder einzeln hinzufügen, und das ist aufwendig und fehlerträchtig. Ausserdem muss man sich genau überlegen, woher man die Mitgliedsnummer nimmt, unsere so wichtige eindeutige ID. Was gibt es für Alternativen?

Man könnte die neuen Benutzer in der alten Excel-Liste eintragen, die Mitgliedsnummern fortlaufend weiterführen und einen neuen Import fahren, aber was passiert dann mit unseren Bestandsdaten? Werden die „alten“ Mitgliederdaten dann überschrieben? Was passiert mit Änderungen, die ich in den Bestandsdaten eventuell bereits gemacht habe? Wäre dann die Excel-Datei unser führendes System, und nicht WordPress? Lauter Fragen, auf die es so ad hoc keine einfachen Antworten gibt.

Noch ’ne Hypothese

Viele CSV-Import-Plugins, die ich ausprobiert habe, bieten zumindest in der Pro Edition ein Feature, mit dem man auswählen kann ob bereits bestehende Datensätze upgedated werden sollen oder nicht. Ausprobieren konnte ich das nicht, aber es scheint mir die einzig praktikable Lösung zu sein, wenn man neue Mitglieder-Datensätze nicht einzeln manuell eingeben, sondern per neuem Import hinzufügen möchte. Das würde natürlich bedeuten daß wir von unserer alten Excel-Tabelle nicht wegkommen, aber sei’s drum. Gehen wir mal davon aus, dass das funktioniert mit dem selektiven Import, und kümmern wir uns mal um das nächstliegende Problem:

Die immer noch unsichtbaren Custom Fields

Man sieht die benutzerdefinierten Felder ja nach wie vor nur im Beitragseditor, und das soll sich jetzt schnellstens ändern. Eine sehr kurze und praktische Lösung ist ein Shortcode, den wir wie gewohnt in die functions.php unseres Child-Themes setzen. Der kann zum Beispiel so aussehen:

function ms(){
    
    $aktID=get_the_id();
    $strassehsnr= get_post_meta($aktID, 'strassehausnummer', true);
    echo $strassehsnr;
        
}
add_shortcode('meinshortcode','ms');

Ich habs ein bisschen ausführlicher als unbedingt nötig hingeschrieben, aber so läßt sichs besser erklären. Die Funktion ms() macht Folgendes:

get_the_id() holt die WordPress-ID des aktuellen Beitrags
get_post_meta() holt zur aktuellen Beitrags-ID den Wert des Custom Field namens „strassehausnummer“, das „true“ am Ende bewirkt, daß eine Einzelvariable ausgegeben wird und kein Array
echo gibt die ganze Chose aus.

Fertig! Shortcode in einen Beitrag einsetzen, Beitrag ansehen und da steht sie, die Strasse und Hausnummer. Die anderen Custom Fields holt man sich mit genau der gleichen Mechanik, man muß halt nur den get_post_meta() mit dem korrekten Namen des Feldes füttern. Also, damit kann ich jetzt echt leben!

Verwendung im Theme

Man kann die Funktion get_post_meta() natürlich auch in einem Template nutzen, sie z.B. an geeigneter Stelle in ein Child seiner single.php einbauen, aber das ist sehr Theme-spezifisch, da muss jeder selber rumdoktern, das versuche ich zu vermeiden wo es nur geht. In der Praxis wird man sich wahrscheinlich einen benutzerdefinierten Post Type anlegen und dort die entsprechenden Ergänzungen vornehmen, aber davon laß ich hier mal die Finger, das sieht wie gesagt in jedem Theme anders aus. Mir reicht mein funktionaler Shortcode, der ist universell einsetzbar.

Ja, aber was ist jetzt mit dem Anlegen neuer Mitglieder?

Machen wir das echt im alten Excel?
Gute Frage, und ich glaube, dazu brauchts einen neuen Beitrag.

Andere Importer, zentrale Datenhaltung und Custom Fields

Noch mehr Testberichte?

Nein, da muß ich euch enttäuschen. Ich hab zwar noch eine ganze Latte anderer Import-Plugins ausprobiert, eine Auswahl davon findet ihr hier bei winningWP, aber so richtig begeistert war ich von keinem davon. Die mit den meisten Features sind nahezu beliebig kompliziert in der Bedienung und erfordern einen erheblichen Einarbeitungsaufwand, und die einfacheren Genossen können allesamt keine Benutzerdefinierten Felder (Custom Fields). Zumindestenst nicht die Free Editions, die kostenpflichtigen Pro-Ausgaben sollens dann schon können. Aber die, wie ich schonmal gesagt hatte, kommen bei mir nicht zum Einsatz – mir fehlt das nötige Kleingeld, und mir gehts auch ums Prinzip. Open Source, sie wissen schon.

Warum mir die Custom Fields so wichtig sind

Da muss ich ein bißchen ausholen. Ich (und einige Legionen anderer WordPress-Entwickler da draussen) stehe immer wieder vor der Herausforderung, bestehende Unternehmensdaten in WordPress integrieren zu müssen. Darüber habe ich mich in diesem Artikel kürzlich ausführlicher ausgelassen, das will ich jetzt nicht alles wiederholen. Bleiben wir bei einem einfachen Beispiel:

Der Turnverein Weiß-Blau mit dem Mitgliederverzeichnis

Gehen wir davon aus, daß beim Kickoff unseres WordPress-Projekts bereits Mitgliederdaten vorhanden sind, das ist schließlich der Normalfall. Gehen wir weiter davon aus, daß diese Daten als Excel-Liste geführt werden. Auch das ist eher der Normalfall, und da kommen wir relativ simpel an unser CSV ran. Wir klemmen uns ein Import-Plugin, erzeugen uns für jeden Mitgliederdatensatz einen Beitrag in WordPress, schubsen unsere Mitgliedsnummer, den Vornamen und den Nachnamen in die Titelzeile und den Rest (Adresse, Email, Telefonnummer und sportliche Präferenzen) in den Post Content, und fertig.

Fertig? Nein, jetzt gehts erst los!

Der Kunde ist erfreut, man kann sich die Liste der Mitglieder sowohl auf der Blogseite als auch im Dashboard anschauen, man kann suchen, z.B. nach Namen oder nach Ort, man kann (im Beitragseditor) die kompletten Mitgliederdaten anschauen und auch ändern, und – halt, Stopp. Da haben wir jetzt einen ganz wichtigen Knackpunkt erwischt. Was ist zu tun, wenn sich Mitgliederdaten ändern? Jemand hat eine neue Telefonnummer oder ist umgezogen und die ganze Adresse ändert sich, jemand interessiert sich jetzt auch noch für Aerobic und möchte das eingetragen haben, oder -Gott bewahre! – es kommen nach dem CSV-Import noch neue Mitglieder dazu… was ist dann zu tun?

Die schwierige Entscheidung: was ist das führende System?

Diese Frage stellt sich bei nahezu jedem IT-Projekt, und wenn man das nicht frühzeitig entscheidet, kommt man in Teufels Küche. Ich habe da selbst in Großprojekten, an denen ganze Mannschaften von Programmierern monatelang schufteten, schon die tollsten Pleiten erlebt, nur weil nicht von Anfang an entschieden wurde, was denn nun de Facto das führende System ist. Dabei ist es im Prinzip ganz einfach. Man muß festlegen, wo die Datenpflege passiert. In der Praxis heißt das meistens, wo die Inserts von neuen Datensätzen und die Updates von bereits existierenden Bestandsdaten erfolgen. Im Regelfall wird das eine Tabelle sein, oder bei komplexeren Systemen auch mehrere verknüpfte Tabellen. Wenn man es richtig macht, implementiert man eine Logik die festlegt was zu tun ist wenn z.B. ein neues Mitglied im Turnverein hinzukommt, und sorgt programmtechnisch dafür, daß der neue Mitgliederdatensatz ordentlich angelegt wird, mit eindeutiger Mitgliedsnummer (ID) und allem Pipapo. Ebenso bei der Änderung von Daten eines bereits vorhandenen Mitglieds, da wird man im Regelfall den zu ändernden Datensatz anhand der Mitgliedsnummer identifizieren und updaten. Alles klar soweit? Und dann?

Jetzt kommts: alle anderen Systeme referenzieren auf das führende System

Sinn und Zweck der ganzen Übung ist natürlich der: man möchte Datenänderungen nur zentral an einer Stelle im System vornehmen und es nicht an -zig verschiedenen Stellen (Huhu SAP!) eintragen müssen, wenn sich irgendwo zum Beispiel eine Telefonnummer oder eine Bankverbindung ändert. Wenn die zentralen Daten an anderer Stelle in der IT-Architektur des Unternehmens gebraucht werden (Beispiele kommen gleich) greift man auf die zentrale Datenhaltung zu und saugt sich die entsprechenden Daten aktuell ab. Im Idealfall sorgt der Entwickler sogar für eine dynamische Verknüpfung, so daß bei einer Änderung in den Stammdaten die abhängigen Systeme in Echtzeit mitkriegen, daß was passiert ist.

Ganz einfache Beispiele

Der Vorstand unseres Turnvereins möchte gerne wissen, wie viele unserer Turnvereinsmitglieder sich für Aerobic interessieren. Früher ist man da in die Excel-Liste gegangen, hat einen Filter auf die Spalte „Aerobic“ gesetzt und abgezählt bei wie vielen Mitgliedern da ein „ja“ drinstand. Ein bißchen EDV zu Fuß, aber es hat funktioniert.

Oder die Pressereferentin möchte alle weiblichen Mitglieder anschreiben und nachfragen, ob Interesse an einem Mutter-Kind-Training besteht – ja echt, sowas ist der Renner in unserem Stadtteilzentrum! Wieder kommt unsere Excel-Liste zum Einsatz, wir filtern nach Geschlecht und holen uns nur die Spalten mit den Namen und Adressdaten heraus, und die Mailing-Aktion kann starten.

Sie sehen, auf was ich hinauswill? Nennt sich zentrale Datenhaltung, oder neudeutsch „Data Warehousing“. In unserem Fall, dem ganz konkreten Mitgliederverzeichnis des Turnvereins, stellt sich die zentrale Frage:

Was ist unser führendes System: WordPress oder Excel?

Wenn wir unsere Mitgliederdaten per CSV-Import schon so schön in Wordpess reinjongliert haben, möchte unser Kunde mit an Sicherheit grenzender Wahrscheinlichkeit jetzt auch weiterhin mit WordPress arbeiten. Neue Mitglieder hinzufügen, Bestandsdaten ändern, kleine Datenauswertungen (siehe oben) für den Vorstand, die Buchhaltung und sonst noch etliche Anwender fahren, das hatten wir ja gerade. Gehts, oder gehts nicht? Das kommt ganz schwer darauf an, und jetzt kommen wir endlich zu den Custom Fields. Es geht nämlich erstmal nicht.

Text ist Text, da beißt die Maus keinen Faden ab

So wie die meisten CSV-Importer (zumindest die Free Editions) funktionieren, landen unsere Mitgliederdaten erstmal gesammelt im Post Content. Das ist ein Longtext. Da kann man die Daten zwar anschauen oder editieren, aber wenn man sich jetzt z.B. alle Münchner Adressen rausfischen will, steht man schon am Ende der Fahnenstange. Ja nee, man könnte mit einem „post_content like %München%“ vielleicht die meisten Datensätze erwischen, aber sauber ist das nicht. Und wenn man jetzt alle Datensätze herausholen will, die bei Aerobic ein „ja“ drinstehen haben, ist endgültig Schluß, das geht so nicht.

Jetzt endlich: Custom Fields, ihr Einsatz!

Um bei dem Beispiel mit den Münchnern zu bleiben: wenn man den Ort aus der Exceltabelle in ein Custom Field namens „ort“ importieren könnte, könnte man später einen sauberen Select über „ort = ‚München'“ fahren. Wir erinnern uns nochmal kurz an die Logik der Custom Fields:

Ich habe z.B. ein neues Benutzerdefiniertes Feld „Preis“ mit dem Wert 12,80 angelegt. In der Tabelle wp_postmeta landet ein neuer Eintrag mit einer laufenden meta_id:

post_meta_custom_field

Hier wird über die post_id der Name (meta_key) und der Wert (meta_value) des benutzerdefinierten Feldes festgehalten.

Ich hätte also für unseren Ort den meta_key „ort“ und bei jedem Datensatz (erkenntlich an der post_id) entsprechend den meta_value „München“ oder eben einen anderen Ort. Da geht im Schnellschuss mal ein Join der wp_posts auf die wp_postmeta, das könnte etwa so aussehen:

Select * fom wp_posts left join wp_postmeta on wp_posts.ID = wp_postmeta.post_id 
where  wp_postmeta.meta_key = "ort" and wp_postmeta.meta_value = "München"

Damit hätte man zumindest mal sauber alle Münchner herausgefiltert. Auch wenn ich die WordPress-Puristen hier schon maulen höre: dafür gibts doch vordefinierte Funktionen, get_post_meta() zum Beispiel! Ja, ich weiß. Aber Hier gehts ums Prinzip, nämlich der programmtechnischen Auswertbarkeit von in WordPress enthaltenen Daten.

Die schlechte Nachricht: wie sieht der Select bei mehreren Custom Fields aus?

Da wirds ein bißchen unübersichtlich. Mit der eben beschriebenen Merthode müßte man tatsächlich für jedes weitere Custom Field einen weiteren Join hinzufügen, ich hab mir da mal ein Beispiel mit vier Feldern bei stackoverflow ausgeliehen:

SELECT wp_posts.ID, wp_posts.post_title, wp_posts.whatever,
            color.meta_value        AS color,
            transmission.meta_value AS transmission,
            model.meta_value        AS model,
            brand.meta_value        AS brand
       FROM wp_posts

  LEFT JOIN wp_postmeta  AS color 
         ON wp_posts.ID = color.post_id        AND color.meta_key='color'

  LEFT JOIN wp_postmeta  AS transmission
         ON wp_posts.ID = transmission.post_id AND transmission.meta_key='transmission'

  LEFT JOIN wp_postmeta  AS model
         ON wp_posts.ID = model.post_id        AND model.meta_key='model'

  LEFT JOIN wp_postmeta  AS  brand
         ON wp_posts.ID = brand.post_id        AND brand.meta_key='brand'

      WHERE wp_posts.post_status = 'publish'
        AND wp_posts.post_type = 'car'
   ORDER BY wp_posts.post_title

Beeindruckend, nicht wahr? Aber nicht wirklich schön. Der ganze Heckmeck ist nötig, weil die Tabelle wp_postmeta eine sogenannte Pivot-Struktur (Excel-Fexe kennen das) für die Custom Fields einsetzt, und dafür gibts in MySQL keine einfachere Auswertelogik. Hier ebenfalls bei Stackoverflow ist ein interessanter Beitrag mit einem anderen Lösungsansatz, aber das führt mir jetzt wirklich zu weit, und ausserdem ist dieser Beitrag schon lang genug. Ich hoffe, dass ich einigermassen klarmachen konnte, warum ich den Datenimport in Custom Fields für unbedingt notwendig halte, und werde mich im nächsten Beitrag darum kümmern, die Custom Fields auch angezeigt zu bekommen. Wollen doch mal sehen, wie sich WordPress als führendes System so anlässt.

Der erste Kandidat: WP All Import

Die Ausgangsbasis

Mal sehen, was wir alles brauchen. Namen, Adressen, Telefonnummern, E-Mail, da ist nichts weiter ungewöhnliches dabei. Wichtig ist die Mitgliedsnummer (die ID aus der Datenbank), schließlich können wir ja auch zwei Peter Huber haben oder Susi Müller und müssen die unterscheiden können, und die Buchführung braucht die Mitgliedsnummer auch. Die sportlichen Präferenzen lassen wir im ersten Schritt erstmal weg, hier geht es ums Prinzip, und bei zu vielen Feldern geht schnell der Überblick verloren. Wir nehmen also nur die Adressdaten und die Mitgliedsnummer, das reicht für den Anfang.

Die Anforderung

Es soll für jedes Mitglied ein eigener Beitrag erstellt werden, in dem die vollständigen persönlichen Daten aufgelistet werden. Die Mitgliedsnummer soll aus dem Beitragstitel ersichtlich sein. Das wars eigentlich schon – mal sehen, was die Import-Plugins draus machen.

Der erste Kandidat: WP All Import

Nach eigener Aussage:

The most powerful solution for importing XML and CSV files to WordPress

Na, da können wir ja mal gespannt sein. Nach der Installation und Aktivierung präsentiert sich All Import mit einem eigenen Menüpunkt im Admin Panel, hier wählen wir „New Import“, und unter „Datei hochladen“ suchen wir uns unsere CSV-Datei. Die Default-Einstellungen können wir lassen wie sie sind, es sollen neue Beiträge erstellt werden, einer für jeden Datensatz in der CSV-Datei. Kleiner Meckerpunkt am Rande: die Benutzerführung ist gemischt deutsch/englisch und sehr uneinheitlich übersetzt.

Wir machen mit den Default-Einstellungen weiter zu Schritt 3, und da wirds interessant: das sieht jetzt dem WordPress-Beitragseditor sehr ähnlich. Man hat eine Titelzeile und ein Editorfenster mit allen gewohnten Formatierungsoptionen. Zusätzlich gibt es auf der rechten Seite ein Vorschaufenster mit den importierten Datensätzen aus der CSV-Datei, aus dem man die Felder per Drag&Drop in den Editor ziehen kann. Ich schiebe mal gleich die Mitgliedsnummer und den Vornamen in die Titelzeile, so hatten wir das in unserem „alten“ Mitgliederverzeichnis auch angelegt. Das sieht dann so aus:

allimport-drag-and-drop

Wissen sie, an was mich das ganz stark erinnert? Das sieht aus wie ein Serienbrief, und genau genommen ist es das wohl auch, aber dazu gleich mehr.

Wir schubsen noch die restlichen Felder mit den Adressdaten ins Editorfenster, machen ein paar Zeilenumbrüche dazwischen und gehen mal kurz auf den Button „Vorschau“ – ah, sehr schick, man kann hier durch alle Datensätze durchblättern, das gefällt mir gut – da scheint alles zu passen.

allimport-vorschau

Na dann wollen wir mal. Vorschau schließen, Continue to step 4 (Benutzerführung wieder sehr gemischtsprachig). All Import möchte jetzt einen Unique Identifier haben, da geben wir ihm doch unsere Mitgliedsnummer. Die restlichen Optionen schauen wir uns später an. Ein Klick auf „weiter“, und jetzt kann man den Import starten. Wer möchte kann noch das Kleingedruckte lesen, die Default-Einstellungen passen aber soweit.

Das Ergebnis

Die neue Beiträgen wurden angelegt, 10 Stück sind das in meinem Testfall.

allimport-ergebnis

Die Beiträge sehen auch aus wie erwartet, Mitgliedsnummer und Vorname bilden die Titelzeile, der Rest der Adressdaten den Beitragsinhalt:

allimport-beitrag-einzel

So weit so gut. Aber was, so fragen die alten Hasen natürlich gleich, ist dahinter auf der Datenbank passiert? Nichts weiter Aufregendes. Es wurden 10 neue Posts angelegt, mit der Mitgliedsnummer und dem Vornamen als Post Title, und den restlichen Daten der Adresse im Post Content.

allimport_wp_posts

Was gibts da zu meckern?

Auf den ersten Blick nicht viel, die Adressdaten sind ja sauber in die Beiträge eingefügt worden. Aber ich denke mal einen Schritt weiter. Erinnern sie sich noch an unseren schicken Adresseneditor mit den Edit-Buttons?

adresseneditor

Das, liebe Gemeinde, ist mit dem All-Edit-Plugin leider nicht machbar. Weil unsere Datensätze aus der CSV-Datei nicht jeweils als einzelne Datensätze mit den entsprechenden Feldern abgelegt werden, sondern zu einem String zusammengebappt und als reiner Text in den Post Title und in den Post Content gesteckt werden. Einbahnstrasse, genau genommen sogar ein Medienbruch. Der Vergleich mit dem Serienbrief war schon ganz richtig, da werden aus einer Steuerdatei im CSV- (oder sonst einem elektronisch verarbeitbaren) Format rein textuelle Ausgabedateien erzeugt, die sich zwar prima ausdrucken lassen, aber keinerlei Möglichkeiten zur weiteren Verarbeitung bieten. Man kann nichts mehr filtern, gruppieren oder sortieren, die Verbindung zur Ausgangstabelle ist komplett abgehängt. Bei einem Word-Serienbrief ist das akzeptabel, das ist einfach Funktionalität. Aber von einem CMS erwarte ich da ein bißchen mehr.

Wer ganz genau aufgepaßt hat: was war das mit den individuellen Felder?

WP All Import bietet auch die Oprion, „Individuelle Felder“ zu importieren – das müßten eigentlich die Benutzerdefinierten Felder oder Custom Fields von WordPress sein. Wenn wir unsere Datenfelder aus der CSV-Datei da drin unterbringen würden, hätten wir zumindest eine Datenbasis, mit der man weiterarbeiten kann. Ich bin nicht der größte Fan von benutzerdefinierten Feldern, aber besser als nix. Jedoch, nicht zu früh freuen, meine lieben alten Datenschubser. Diese Option gibts nur für die Pro Edition.

allimport_pro_edition

Und die langen da ordentlich hin mit den Preisen:

allimport-preise

Das sprengt das Budget unseres Turnvereins aber komplett – mal ganz davon abgesehen, daß ich hier aus Prinzip keine kostenpflichtigen Plugins testen werde. Ich hab erstens das nötige Kleingeld nicht. Zweitens bin ich der Überzeugung, dass es für eine Software, die sich den Open-Source-Gedanken so groß auf die Fahne geschrieben hat wie unser WordPress, für jedes Programmierproblem auch eine kostenfreie Lösung geben sollte. Sei es daß man sich in den Supportforen auf wpde.org Hilfe holt, sei es daß man sich durch eine Reihe alternativer Plugins testet, sei es eine selbst programmierte Lösung, da gibt es viele Möglichkeiten. Aber Kaufsoftware kommt mir hier nicht in die Tüte. Wir schauen mal weiter, was es sonst noch so an Import-Plugins gibt, aber dazu gibt es auch einen neuen Artikel.

Datenschubserei für Fortgeschrittene: wir nehmen CSV

Ausgangsbasis: Fehlanzeige

Vielleicht hat man ja schon mal ganz hoffnungsvoll reingeguckt, was sich im Dashboard unter Werkzeuge/Daten importieren oder exportieren verbirgt, aber da kommen wir leider nicht weiter. Hier kann man nur WordPress-eigene XML-Dateien erzeugen oder hochladen, mit denen sich Beiträge und Seiten aus einem Blog herausexportieren und in einen anderen Blog wieder reinladen lassen. Wir brauchen ganz was anderes, und da wollen wir uns mal umsehen, was der Plugin-Markt so hergibt. Aber zuerst einmal ein paar Sätze zum Datenformat.

Unser Format der Wahl: CSV

CSV oder „Comma separated values“ ist das wohl verbreitetste Transportmittel für tabellarische Daten jeder Art. Es enthält normalerweise eine Kopfzeile, in der die Feldnamen stehen, und dann in jeder weiteren Zeile jeweils einen Datensatz. Die meisten Anwender kennen die Möglichkeit, Excel-Tabellen als CSV zu speichern, und solche Listen werden wir in den meisten Fällen verwenden. Ich zeig hier mal nur ein ganz einfaches Beispiel:

id;vorname;nachname
1;Fridolin;Hackmann
2; Marius ;Bishop
3;Yvonne;Green
4; Lina ;Ward
5; Tara; Sell
6; Antonia ; David 
7; Lorena ; Peter 
8; Franz ;Pfaff
9; Maja ; Bartels 
10; Laurin ; Selle

Das sind einfach zehn Datensätze, die Feldnamen kann man in der ersten Zeile lesen: id, vorname, nachname. Diese erste Zeile wird auch „Header“ genannt und wird uns bei unseren Importbemühungen noch öfter begegnen. Sie legt fest, in welcher Reihenfolge und mit welcher Benennung die einzelnen Datensätze zu lesen sind. Ob dahinter nun eine Liste mit 10 oder 10.000 Datensätze steht kann uns völlig wurst sein, Hauptsache die Struktur stimmt.

CSV geht (fast) immer

Ich habe schon viele Stunden meiner IT-Laufbahn damit verbracht, den unterschiedlichsten Systemen CSV-Dateien zu entlocken, und die gute Nachricht ist: meistens gehts schon irgendwie. Ob das nun DATEV, SAP, Lexware oder WISO meinBüro ist, oder eine MySQL- oder Oracle- oder sonst eine Datenbank, in den meisten Fällen verbirgt sich irgendwo eine Exportfunktion für CSV, man muß oft nur ein bißchen suchen. Manchmal muß man noch ein bißchen mit den Optionen experimentieren, ein beliebtes Spiel ist dass Umlaute und Sonderzeichen (ÄÖÜ%$§…) erstmal nicht so codiert sind wie man sie braucht, aber für die alten Datenbankfexe da draussen erzähle ich hier nichts Neues. Im schlimmsten Fall muss man da mit dem Notepad++ und etlichen Suchen&Ersetzen-Läufen nachkorrigieren, aber meistens hält sich der Aufwand in Grenzen. Es ist im Normalfall gar nicht so schwierig, eine funktionale CSV-Datei aus dem vorhandenen Datenbestand zu erhalten.

Was ist mit XML?

Das lassen wir mal aussen vor. Im Otto-Normal-Büro wird man in den seltensten Fällen Bestandsdaten als XML antreffen, auch wenn heutzutage nahezu jede Datenbank auch XML-Export und Import beherrscht. Wir halten uns an die schlichten CSV-Listen, das ist für unsere Anwendungen völlig ausreichend.

Wie gehts jetzt weiter mit dem CSV?

Da läßt sich leider keine allgemeingültige Anleitung formulieren, hier muß man schon sehr spezifisch einsteigen, was denn nun mit den Daten passieren soll. Ich werde ab jetzt mit konkreten Beispielen arbeiten, damit die Kuh vom Eis kommt. Erinnern sie sich noch an den Turnverein Weiß-Blau? Da hatten wir mithilfe einer eigenen Tabellen ein Mitgliederverzeichnis erstellt. Dafür haben wir für jedes Mitglied einen eigenen Beitrag erstellt und mit der Mitglieds-ID auf die eigene Tabelle mit allen relevanten Daten verknüpft. Jetzt gehen wir mal davon aus, daß eine umfangreiche Mitgliederliste mit Adressen und allem drum und dran schon existiert. Wollen mal sehen, ob wir die in unser WordPress importiert kriegen, aber dazu gibt es einen neuen Beitrag.

Da staunste Bauklötze: vielleicht serialized, vielleicht nicht

Wenns klemmt im Datenkorsett

Ich habe mich schon an anderer Stelle darüber ausgelassen, daß das Datenmodell von WordPress alles andere als relational wohlstrukturiert und insgesamt renovierungsbedürftig ist. Wenn man sich ein bißchen mit multifunktionalen Plugins wie z.B. woocommerce beschäftigt, stellt man immer wieder fest, daß Entitäten in die vorhandenen WordPress-Tabellen gequetscht werden, die eigentlich nicht wirklich hineinpassen. Um beim Beispiel woocommerce zu bleiben, weil das ja doch sehr verbreitet und gut dokumentiert ist: da werden die zu verkaufenden Produkte in der Tabelle wp_posts wie Beiträge angelegt, und was man hier an Produkteigenschaften und benutzerdefinierten Feldern nicht mehr untergebracht hat, landet in der wp_options, der wp_postmeta oder in der wp_terms und ihren Verwandten. Damit man hier auch alles unterbringt, obs jetzt logisch paßt oder nicht, kommt ein tolles Konstrukt zum Einsatz (übrigens nicht nur in WordPress, das gibts auch anderswo):

Serialized Data

Was ist das? Wenn sie einen Datenbankeintrag finden , der so aussieht:

a:1:{s:14:“pa_code“;a:6:{s:4:“name“;s:14:“pa_code“;s:5:“value“;s:0:““;s:8:“position“;i:0;s:10:“is_visible“;i:1;s:12:“is_variation“;i:0;s:11:“is_taxonomy“;i:1;}}

Das sind serialisierte Daten. Es handelt sich hier um ein Produktattribut namens „code“, das in dieser besonders verklausulierten Form abgelegt wurde. Wer genauer wissen möchte, was serialisierte Daten sind, kann hier im PHP-Manual mal nachlesen, und mir ganz ehrlich sagen wenn er auch nur die Hälfte verstanden hat. Soweit ich es kapiert habe, erlaubt es die Serialisierung, in einem einzigen Datenbankfeld mehrere Variable unterschiedlicher Datentypen zu speichern. In einem Array, mit Hilfe eines Objekts. Aber, ich gebe wie gesagt ehrlich zu ich hab nicht genau verstanden, wie das wirklich funktioniert. Da schwirrt es in den Manuals nur so von Objekten und Klassen und Methoden, und mir fehlt echt die Geduld (und der Hang zur Verkomplizierung) mich da weiter einzulesen. Ich habs versucht, und bin dabei unter anderem auf einen besonderen Leckerbissen gestossen:

Eine Funktion namens maybe_serialize()

Allen Ernstes. Laut Codex macht die Folgendes: sie serialisiert Daten, falls nötig. Ich muß da unbedingt mal wörtlich zitieren:

Confusingly, strings that contain already serialized values are serialized again, resulting in a nested serialization. Other strings are unmodified.

Ach nee, „confusingly“, also verwirrenderweise? Da brat mir doch einer einen Storch! Und wie kriegt man die Daten da wieder raus? Gute Frage. Es gibt tatsächlich auch eine Funktion namens maybe_unserialize(), ist das nicht schön? Irgendwas muß man damit doch anfangen können… meine Recherchen haben aber noch nicht ergeben, was man sinnvollerweise damit macht.

Wofür soll das alles gut sein?

Der Knackpunkt ist: hier werden buntgemischte Daten in ein einziges Tabellenfeld geklemmt, statt sie sauber nach Datentypen getrennt in einer passenden Tabelle zu speichern. Damit bringt man mehr Informationen als vorgesehen in einer bereits vorhandenen Tabelle unter, aber das Auslesen und Weiterverarbeiten wird beliebig kompliziert und erstmal sehr verwirrend und umständlich. Und mal ganz im Ernst: eine Funktion, die „maybe“ irgendwas macht, die kann ich nicht gebrauchen. Das sind Stilblüten der objektorientierten Programmierung, die allem widersprechen, was ich über Datenmodellierung und Tabellenstrukturierung je gelernt habe.

Um beim Beispiel woocommerce zu bleiben: das Plugin gönnt sich ja ohnehin ein gutes Dutzend eigener Tabellen. Warum legt man dann für die Produktattribute nicht auch eine eigene Tabelle an, in der die nötigen Daten in lesbarer und vor allem auch per SQL auswertbarer Form gespeichert werden? Kostet auch nicht mehr, und wäre unendlich benutzerfreundlicher. Den Mumpitz mit den vielleicht oder auch nicht serialisierten Daten könnte man sich dann echt sparen.

Wahrscheinlich guckt wieder kein Schwein: Scheduled events

Was ist ein Scheduled Event?

Das ist im Prinzip so etwas wie ein Cron-Job, und hier höre ich alle alten Programmierer „Aha!“ rufen. Jeder kennt die Möglichkeit, in Unix/Linux zeitlich wiederkehrende Aufgaben per Cron-Job zu steuern. WordPress bietet mit den Scheduled events eine ähnliche zeitabhängige Funktionssteuerung, und das ist prinzipiell eine schicke Sache, aber es gilt ein paar Eigenheiten zu beachten. Man kann schon festlegen, zu welcher Uhrzeit eine Funktion ausgeführt werden soll, ob sie täglich oder zweimal am Tag oder wöchentlich ausgeführt werden soll und all sowas, aaaber…

Wahrscheinlich guckt wieder kein Schwein

Ein WordPress Scheduled event wird erst ausgeführt, wenn die Blogseite auch aufgerufen wird. Dann guckt WordPress nach, ob es Events gibt, deren festgelegte Uhrzeit bereits abgelaufen ist, und erst jetzt wird die geplante Aktion gegebenfalls ausgeführt. Heißt im Klartext: wenn kein Besucher auf die Webseite kommt, wird auch kein Event ausgeführt. Nein, ich veräppel euch nicht, das ist so. Schlimmstenfalls wird der Event erst genau dann ausgeführt, wenn man selber mal auf seine Webseite geht um zu gucken ob schon was passiert ist. Das ist natürlich datenverarbeitungstechnisch Bockmist, weil es dem reinen Zufall überlassen ist, wann die gewünschte Funktion nun tatsächlich ausgeführt wird.

Und, ist das so schlimm?

Das kommt darauf an. Wenn ich über einen Scheduled Event einen größeren Datenbankabgleich mit richtig vielen Datensätzen fahren will, hätte ich schon gern dass der wie geplant Nachts um 2:00 über die Bühne geht und nicht erst Morgens wenn der erste Besucher auf meiner Webseite hereinschneit. Wenn ich zu bestimmten Zeiten E-Mails mit Informationen über „Neues zum Tage“ an meine Abonennten verschicken möchte, sollen die schon zu einer bestimmten Tageszeit abgesetzt werden und nicht erst Stunden später. Das mal nur so als Beispiele.

Wir wollen mal nicht so kleinlich sein, in den meisten Fällen wird es nicht so gravierend sein, wenn eine geplante Funktion statt um 0:00 erst um 6:27 beim ersten Besucher der Webseite getriggert wird. Man muss es halt wissen, und sich genau überlegen ob es im Einzelfall etwas ausmacht, daß ein geplanter Event erst „irgendwann“ stattfinden wird, und nicht genau zur geplanten Zeit.

Wie plane ich einen Scheduled Event?

Dafür verweise ich auf diesen ausgezeichneten Artikel bei sitepoint, da steht alles in komprimierter, bestens verständlicher Form drin. Ich renne hier nur mal im Schnellgang durch.

Zuerst definieren wir die Funktion, die ausgeführt werden soll,

function mein_event(){  // Mach irgendwas.}

Wir verknüpfen die Funktion mit einem neuen Action hook:

add_action('mein_action_hook','mein_event');

Schließlich setzen wir die Parameter für den Event, dabei nutzen wir die PHP-Funktion time(), die den UNIX-Timestamp für „jetzt“ zurückgibt:

wp_schedule_event(time(), 'hourly', 'mein_action_hook');

Das alles kommt in die functions.php unseres Child-Themes, und sollte dafür sorgen, dass unsere Funktion ab sofort stündlich ausgeführt wird… jedenfalls so ungefähr, wann halt der nächste Besucher hereinschneit. Also ehrlich, mir sträuben sich da sämtliche Nackenhaare, aber anders kann es WordPress halt nicht. Da dürfen sich die Entwickler aber schon nochmal was einfallen lassen!

Workaround und Helferlein

Ja, ich habs gehört, die alten Programmierer habens alle schon eingeworfen: dann basteln wir uns halt einen Cron-Job, der unsere WordPress-Seite automatisch aufruft, sagen wir mal eine Minute nachdem der Scheduled Event fällig war. Wie das geht steht z.B. hier bei Sebastian Widmann , aber das führt mir jetzt endgültig zu weit, das kann sich jeder der möchte selber zusammenpfriemeln.

Wenn man unbedingt mit Wordpess Scheduled events arbeiten will, kommt man an einem sehr ausgefeilten und nützlichen Plugin kaum vorbei:
WP Crontrol bietet eine komfortable Benutzeroberfläche zur Steuerung von Events und Schedules und macht einem das Leben hier deutlich leichter. Ändert zwar nix an der grundlegenden Problematik von „wahrscheinlich guckt wieder kein Schwein“, aber ist zumindest sehr einleuchtend zu bedienen und hilft einem bei mehreren Scheduled Events wirklich, den Überblick zu bewahren.

Hooks – jetzt kommt Action ins Spiel

Was sind WordPress Hooks?

Das kann man googlen, und z.B. die netzialisten haben einen sehr informativen Beitrag zu dem Thema geschrieben. Sehr kurz und knapp gesagt, Hooks sind definierte Ankerpunkte im WordPress-Code, an denen man eigene Funktionen einhängen kann. Dabei unterscheidet man zwischen Action Hooks und Filter Hooks, dazu gleich mehr. Eine umfassende Liste aller WordPress Hooks hat Adam R. Brown in seiner Hook Database zusammengetragen. Auch der Codex zur Plugin API bietet umfangreiche Information zum Thema.

Unterschied zwischen Action und Filter

Ich zitiere hier mal schlicht und unbefangen den Codex:

You can sometimes accomplish the same goal with either an action or a filter. For example, if you want your plugin to change the text of a post, you might add an action function to publish_post (so the post is modified as it is saved to the database), or a filter function to the_content (so the post is modified as it is displayed in the browser screen)

Also: wenn man Beiträge gezielt verändern möchte, z.B. eine Copyright-Zeile an jeden veröffentlichten Beitrag anhängen, gibt es (mindestens) zwei Wege zum Ziel. Hier wird empfohlen: entweder man verwendet einen action-Hook auf den Event publish_post, der beim Speichern eines Beitrags in der Datenbank die Copyright-Zeile anhängt. Oder man hakt sich mit einem Filter auf the_content an den Inhalt des Beitrags ran, und hängt die Copyright-Zeile beim Anzeigen des Beitrags in der Einzelansicht an. So weit so gut – ich hab mir allerdings einen Wolf gegooglet, um ein funktionierendes Beispiel für den action hook zu finden, leider bis jetzt ohne brauchbares Ergebnis. Das mit dem Filter dagegen geht relativ easy:

Der Filter

könnte zum Beispiel so aussehen:

function copyright_nach_post_content($content){
if (is_single()) {	
	$content .= '<p>Hier kommt dein Copyright (C) EL 2017 hin </p>';
}
	return $content;
}
add_filter( "the_content", "copyright_nach_post_content" );

Dieser Code kommt in die functions.php unseres Child-Themes und zieht jedesmal, wenn ein Beitrag aufgerufen wird. Die Abfrage auf if(is_single()) stellt sicher, dass auch wirklich nur Beiträge in der Einzelansicht betroffen sind.

Der entsprechende Action-Hook

war wie oben bereits gesagt nicht aufzufinden. Dann machen wir halt was anderes, wo richtig Action drin ist:

Wir versenden eine Email, wenn ein neuer Beitrag veröffentlicht wurde

Dabei stelle ich euch die simple, aber sehr effektive Funktion wp_mail vor. Der Code sieht so aus:

add_action('publish_post', 'send_emails_on_new_post');

function send_emails_on_new_post($post)
{
    $emails = "evi.s.leu@gmx.de"; 
    $title = get_the_title($post->ID);
    $url = get_permalink($post->ID);
    $message = "Link zum Beitrag: \n{$url}";
 
    wp_mail($emails, "Neuer Beitrag! {$title}", $message); 
}

Zuerst wird der action-hook auf das Ereignis publish_post gesetzt und mit unserer Funktion verknüpft. Diese bekommt als Parameter den $post mit, darüber können wir auf die Attribute des aktuellen Beitrags zugreifen, das tun wir mit der $post->ID. Wir holen uns den Titel und den Permalink und basteln uns daraus eine kleine E-Mail-Nachricht an den oben eingesetzten Empfänger.Die Funktion wp_mail braucht ganz minimalistisch wirklich nur 3 Parameter, den Empfänger, den Betreff und den Inhalt, und schon fluppts! Der Empfänger wird jedesmal benachrichtigt, wenn ein neuer Beitrag veröffentlicht wurde.

Ein übersichtlicher Beitrag zur wp_mail-Funktion ist hier bei OSTraining zu finden, die kompletten Informationen findet ihr natürlich im Codex.

Erstellen wir jetzt endlich mal ein eigenes Theme?

Nein.

Und das ist mein letztes Wort, ehrlich. Themes gibt es wie Sand am Meer, da ist echt für jeden Geschmack, Zweck und Funktionsumfang was dabei. Themes sind ein Konzept, das auch vom Enduser (im Zweifelsfall meinem Kunden) leicht begriffen wird, nach Themes kann jeder selber suchen und sich aus den vielen bunten Bildchen das heraussuchen, was ihm am besten gefällt. Und glauben sie mir: es wird ihm erst das eine Theme gefallen, und dann das Nächste und dann noch das Übernächste. Was bei einem Themewechsel auf sie zukommt, da haben sich andere Leute schon schlaue Gedanken gemacht, siehe z.B. dieser Artikel vom elbnetz. Bestenfalls passen nur ein paar Bildformate nicht mehr, schlimmstenfalls zerhackt es ihnen die ganzen Seitenlayouts und die ganzen schönen kundenspezifischen Funktionen.

Bedenken sie immer: als Entwickler kommen sie bei einem Themewechsel in Teufels Küche, wenn sie abhängig von einem bestimmten Theme programmiert haben, und der Kunde möchte jetzt aber unbedingt ein anderes.

Ich editiere Page Templates nur im äußersten Notfall

Weil ich aus langjähriger leidgeprüfter Praxis genau weiß, dass sich der Kunde früher oder später für ein anderes Theme entscheiden wird, greife ich wenn möglich gar nicht in die Page Templates ein. Die Arbeit ist bei einem Themewechsel grad für die Katz‘, und es ist auch nicht gesagt daß ihre Anpassungen in einem anderem Theme auch genauso funktionieren werden, dazu sind die Templates einfach zu uneinheitlich konstruiert.

Aber was ist, wenn man ein Child Theme verwendet?

Das selbe in Grün, ich setze hier keine modifizierten Page Templates ein, wenn es nicht unbedingt sein muss. Ich verwende (ausser bei ganz, ganz einfachen Blogs) immer ein Child Theme. In den seltenen Fällen, wo ich es nicht von Anfang an eingerichtet habe, kam immer früher oder später der Zeitpunkt wo ich doch eins gebraucht habe.

Die einzigen Dateien, an denen ich Änderungen vornehme, sind üblicherweise die functions.php (ganz wichtig für unsere Shortcodes) und seltener noch die style.css des Child Themes. Und das wird dann (verdammtnochmal!) ordentlich und ausführlich dokumentiert, damit man die Funktionalität im Falle des Falles ohne Beinbruch in ein neues Theme übertragen kann.

Ausnahmen bestätigen die Regel

Und falls doch mal eine Änderung an einem Template fällig ist: immer im Child Theme, und immer gut dokumentieren. Ich habe zum Beispiel auf der Seite des Turnvereins Weiß-Blau die Beitragsseiten als Mitgliederverzeichnis umgestaltet, da war ein Eingriff in die single.php notwendig, um die Daten aus der eigenen Tabelle mit den Mitglieder-Stammdaten anzeigen zu lassen. Aber ich wette mit mir selber, dass ich das auch mit einem Shortcode lösen könnte – da mach ich mir bei Gelegenheit mal mehr Gedanken drüber.

Auch wenn man bestimmte Teile des Themes loswerden möchte (keine Sidebar, kein Footer etc…) kommt man um eine Änderung der entsprechenden Templates kaum herum, aber auch hier gilt: immer im Child Theme, und immer gut aufpassen was man da wirklich macht. Die Themes sind ja, wie bereits gesagt, so uneinheitlich konstruiert (und so lausig dokumentiert, das muss auch mal gesagt werden!), dass sich hier kaum allgemeingültige Regeln aufstellen lassen, welche Änderung welchen Effekt bewirkt. Da ist immer viel Trial and Error dabei.

Änderungen in der style.css nur mikrochirurgisch

Natürlich kann man sich hier spielen und die Layouts für nahezu alle WordPress-Elemente nach eigenem Gusto verändern. Aber ich bin Fachinformatikerin, keine Webdesignerin, und überlasse das passende Styling denen, die’s gelernt haben, und das sind im Zweifelsfall nun mal die Theme-Designer. Ich greife mal ein, wenn z.B. die Umrandungen von Formularfeldern unsichtbar sind (beliebtes Manko), oder die Beschriftung von Buttons unleserlich ist. Aber das wars dann schon. Alles andere lasse ich wie es ist, die Leute vom Design haben ja schließlich grosse Mühe darauf verwendet, dass alles zusammen ein stimmiges Bild ergibt, und ich als Design-Laie kann hier bestenfalls verschlimmbessern.

Theme-unabhängig programmieren, das geht!

Sogar sehr schmerzlos. Mit Shortcodes und Plugins, Filtern und Action Hooks läßt sich fast alles erreichen, was der Kunde anfordert, und hier kann man wirklich Theme-unabhängig arbeiten, wenn man ein bisschen aufpasst.

Grosse Styling-Änderungen reden wir unserem Kunden einfach aus, da suchen wir ihm lieber ein anderes Theme. Wir sind schließlich (ich sags nochmal) alte Programmierer und keine Designer.

WordPress möchte doch so gern ein CMS sein

Da fehlts zwar noch ein paar Meter, aber das gute alte WordPress nimmt ja für sich in Anspruch, ein vollwertiges CMS werden zu wollen. Und da ist die Trennung von Funktion und Design unverzichtbar! Will heissen, eigentlich sollte man die Themes wechseln können wie die frischen Socken, ohne dass an den Inhalten überhaupt Nacharbeiten anfallen.

Davon sind wir zwar im Moment noch einiges entfernt, aber mit der Multisite-Technologie gehts schon in die richtige Richtung, besonders wenn man geeignete Plugins zum Beispiel zum Clonen von ganzen Blogseiten einsetzt. Damit kommen zwar auch wieder neue Herausforderungen – wie schreibe ich ein Multisite-fähiges Plugin? – aber die Richtung stimmt wie gesagt schon. Ich beobachte diese Entwicklung mit grossem Interesse, und werde hier sicher noch den einen oder anderen Beitrag zum Thema CMS reinstellen. Aber ein eigenes Theme – no way Josè, das wirds hier bei mir nie geben.

Tabelleneditor revisited: und jetzt das Ganze nochmal als Shortcode

Ja, ich weiß, ich habs unterschlagen. Wir haben uns einen hübschen kleinen Tabelleneditor im Admin Panel gebastelt, mit Unterseite und allem Pipapo. Aber da kamen schon die ersten Rückfragen. Was, wenn ich meinen Besuchern die Möglichkeit anbieten möchte, Tabellendaten auf meiner Webseite zu editieren? Wie sieht das dann die Verzweigung auf die Unterseite aus? Ein Anwendungsfall wäre es zum Beispiel, wenn ich meinen Nutzern das Editieren der eigenen Adressdaten ermöglichen möchte. Da wird man zwar im Zweifelsfall ein Login vorschalten, denkbar ist z.B. daß sich der Benutzer mit seiner Mitgliedsnummer anmeldet und diese beim Aufruf des Unterformulars abgefragt wird. Das führt mir aber jetzt entschieden zu weit, ich lasse es mal bei dem Formular mit den Edit-Buttons, sonst blickt hier keiner mehr durch. Die Funktionalität wird also die selbe sein wie beim Plugin Adressen Tabelle, nur diesmal auf der Blog-Oberfläche.

Wir basteln uns einen Shortcode

Der erste Teil ist simpel. Wir schnappen uns die Funktion pluginAdressenTabelle() und schieben sie in einen Shortcode. Für den legen wir uns eine neue Seite an und fügen ihn dort ein, ich hab ihn mal [adr_tabelle] genannt. Das müsste eigentlich ohne Änderungen klappen, das Ergebnis sollte etwa so aussehen:

shortcode_adresseneditor

Wenn man jetzt auf einen „Edit“-Button klickt, landet man (logischerweise) noch im Admin Panel, und das soll natürlich nicht sein, da brauchen wir was anderes. Nämlich eine Blogseite, die nicht im Menü erscheinen soll, sondern nur durch Klick auf den Edit-Button aus der aufrufenden Seite auftauchen darf.

Seite ohne Menüeintrag? Mit Menü!

Man legt eine neue Seite an, benennt sie entsprechend, z.B. Adresseneditor Unterseite. Dann legt man unter Design/Menüs ein neues Menü an, in das man alle Seiten ausser der eben erstellten einträgt (alle markieren und dann bei der Einzelseite das Häkchen entfernen). Ist ein bißchen von hinten durch die Brust ins Auge, aber so funktionierts.

Aufzurufende Seite bei Formular-Action hinterlegen

Wir klemmen uns einfach den Permalink der soeben erstellten Unterseite und legen sie auf die Variable für den Action-Tag, das sieht dann z.B. so aus:

$meinplugin_URL = „http://localhost/turnverein/adresseneditor/adresseneditor-unterseite/“;

Das wars schon.

Wie kommt jetzt unsere Editor-Funktionalität in die Unterseite?

Per Shortcode! Mein Freund und Lieblingshelfer, ich sags immer wieder. Wir erstellen einen neuen Shortcode, mit aussagekräftigen Namen, z.B.:

add_shortcode (‚mein_adr_editor‘, ‚meinAdressenEditor‘);

Dann brauchen wir natürlich noch die Funktion zum Shortcode, die heißt jetzt meinAdressenEditor(). In diese kopieren wir uns den ganzen Inhalt der Funktion AdresseEditAusgabe() aus dem Plugin, das wir vorher erstellt haben. Nicht vergessen unten den Link zurück auf die aufrufende Seite zu aktualisieren, der sollte jetzt etwa so ausehen:

echo „<a href = ‚http://localhost/turnverein/adresseneditor/’/><h1>Zurück zur Adressenliste</h1></a>“;

Den soeben erstellten Shortcode [mein_adr_editor] in die Unterseite einfügen, speichern und feddisch, das wars! Die Bildschirmausgabe sollte etwa so aussehen:

adresseneditor_unterseite

Übrigens nicht wundern: wenn man sich die Unterseite „allein“ anschaut, also aus dem Edit-Modus mit „Seite ansehen“, sieht man – nichts. Da fehlt der Parameter mit der ID, also ergibt unser Select eine leere Ausgabe, und dann sieht mal halt nichts, punktum.

So, jetzt hab ich aber alle Aspekte des Tabelleneditors erschöpfend behandelt – hoffe ich zumindest. Wenn jetzt noch Rückfragen kommen – ich bin unbekannt verreist 😉