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 😉

Statt Dirty Trick: die saubere Lösung mit Submenu Page

Na bitte, ich wußte doch dass es da eine sauberere Lösung geben muss. Ich lasse die beiden vorigen Artikel mal so stehen (wir lernen daraus) und zeige hier einen anderen Ansatz für das Unterformular, das bislang ja so nackt und weiss als reine PHP-Datei dasteht.

Der erste Vorteil: durchgängige Benutzeroberfläche

Das ist zwar eigentlich nur eine kosmetische Korrektur, funktioniert hats auch vorher, aber schöner ist es ja schon wenn man im AdminScreen-Kontext bleibt.

Der zweite Vorteil: wir sparen uns den require(wp-load.php)

Das ist schon knackiger. Es ist ja nicht „considered best practice“, wenn man den ganzen WordPress-Funktionsapparat in einem Plugin nochmal lädt. Man kanns machen, aber es ist und bleibt eine Krücke. Das können wir uns jetzt schenken, weil unsere Submenu Page alle Funktionalitäten schon mitbringt.

Submenu – wie wirds gemacht?

Wir arbeiten ab jetzt nur noch mit einer PHP-Datei für unser Plugin, da nehmen wir genau die adressen-tabelle.php aus den vorigen Beiträgen. Die ergänzen wir um einen Eintrag, der eine „elternlose“ Submenu-Seite definiert:

add_action(‚admin_menu‘, ‚Edit‘);

function Edit(){
add_submenu_page( ‚null‚, ‚Adresse Edit‘, ‚Adresse Edit‘, ‚administrator‘, ‚adresse-edit‘, ‚AdresseEditAusgabe‚ );
}

Das ‚null‚ im ersten Tag (das ist der für den Parent) ist hier der Knackpunkt. Das bewirkt, dass die Seite zwar aufrufbar ist, aber nicht im Admin Screen Menü auftaucht.

Der letzte Tag AdresseEditAusgabe definiert die Funktion, die bei Aufruf unseres Submenüs ausgeführt wird. Die müssen wir natürlich noch schreiben, aber das wird easy. Da kopieren wir uns einfach den gesamten Inhalt unserer Unterseite edit-adresse.php rein und schmeissen den jetzt überflüssigen WordPress-Load raus. Das wars schon… fast.

Der Aufruf unserer funkelnagelneuen Submenu Page

Der muss natürlich noch ins Action-Tag unserer aufrufenden Seite. Da tauschen wir einfach die Belegung für die Variable aus:

/*Submenu-URL zusammenbauen*/
       $meinplugin_URL = admin_url();
       $meinplugin_URL = $meinplugin_URL.“admin.php?page=adresse-edit„;

Das admin_url() holt uns die Adresse des Admin Screens, die fett gekennzeichnete Ergänzung enthält den Slug unserer Submenu Seite.

Klappts? Wenn sie jetzt aus der Adressentabelle heraus auf einen „Edit“-Button klicken, sollte sowas ähnliches angezeigt werden:

submenu_adminscreen

Schon besser, oder?

Und man spart sich wie gesagt den nicht ganz sauberen Trick mit dem wp-load, da werden auch die Puristen zufrieden sein. Man spart sich auch die zweite PHP-Datei, weil jetzt die ganze Funktionalität in unserer einen Plugin-Datei adressen-tabelle.php steckt. Ich finde die Lösung mit der „elternlosen“ Submenu Page sauber, und sowas wird man immer wieder mal gebrauchen können, wenn man in einem Plugin auf eine Unterseite verzweigen möchte. Hier noch die Plugin-Datei adressen-tabelle.php als ZIP, der Vollständigkeit halber. Und jetzt viel Spaß beim Nachbauen!

Ein Dirty Trick: wir holen uns die wp-load.php

Wo ist unser wpdb-Objekt geblieben?

In unserer „nackten“ PHP-Datei steht es nämlich erstmal nicht zur Verfügung. Um jetzt aber trotzdem ranzukommen – wir wollen ja schließlich wieder mit $wpdb->get_results und all den praktischen Helferlein arbeiten – gibt es eine einfache, wenn auch unter WordPress-Puristen umstrittene Methode. Man holt sich mithilfe einer require()-Anweisung die Datei wp-load.php ins Boot, und schon kann man die WordPress-Funktionalitäten wieder nutzen. Wo diese Datei liegt, ist abhängig von der jeweiligen WordPress-Installation, normalerweise steckt sie im Stammverzeichnis, da wo auch wp-config.php und Konsorten zu finden sind. Falls sie also da zu finden ist, kann man sich so behelfen:

require(‚../../../wp-load.php‘);

Das ist natürlich nicht besonders Foolproof und fällt auf die Nase, wenn die Datei woanders liegen sollte.

Sauberere Methode – wenn auch etwas kryptisch

Eigentlich hasse ich es ja, Code zu verwenden, den ich nicht ganz verstehe. Aber hier mache ich mal eine Ausnahme, es funktioniert nämlich einwandfrei. Das Code Snippet stammt von Frankie Jarrets Seite, und dort kann man auch nachlesen warum man es so NICHT machen sollte…

Statt dem wie oben codierten absoluten Pfad kann man nach Frankie folgende Lösung verwenden:

$parse_uri = explode( ‚wp-content‘, $_SERVER[‚SCRIPT_FILENAME‘] );
require_once( $parse_uri[0] . ‚wp-load.php‚ );

Wie dem auch sei, wir holen uns halt unsere wp-load.php, auch wenn die Puristen Zetermordio schreien. Für unser kleines Adresseneditor-Plugin tuts diese Lösung wirklich, da werden wir keine Probleme mit Serverlast Verdopplung etc. zu erwarten haben.

Hurra, das wpdb-Objekt ist wieder da!

Und deshalb können wir den Code aus unserem ersten Adresseneditor-Plugin (fast) unverändert übernehmen. Die ID für den aktuellen Datensatz haben wir ja schon, die steckt in:

$akt_id = $_POST[„id“];

ganz am Anfang der Datei edit-adresse.php und kommt aus unserem aufrufenden Formular.

Der Select

… ist jetzt wie gehabt:

global $wpdb;
$alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.“ where ID = „.$akt_id.““);

Kleiner Negertrick in der Foreach-Schleife

Wenn wir den Foreach auch ungeändert übernehmen, kommt es nach dem Editieren des Datensatzes und Drücken des „Änderungen speichern“-Buttons zu einem unerwünschten Effekt: die Formularfelder werden auf die ursprünglichen Werte zurückgesetzt. Das führt natürlich zu heftiger Verwirrung beim Anwender, weil seine Änderungen plötzlich verschwunden sind. Dabei sind sie doch schon in der Datenbank gespeichert! Ich mach da mal kurzen Prozess und unterbinde die Anzeige des Formulars, wenn auf den „Änderungen speichern“-Button gedrückt wurde, dann siehts sauberer und für den Anwender besser logisch verständlich aus. Dazu binde ich eine IF-Abfrage mit ein, hier unten fett hervorgehoben:

foreach ( $alleposts as $einpost ) {

//Begin Formular
echo ‚<form method=“post“>‘;

       if (!isset($_POST[’speichern‘])){
           echo „<div style = ‚border: 3px solid blue; padding: 10px; display: inline-block‘>“;
       echo ‚ID: &nbsp‘.$einpost->id.'<input type=“text“ name=“id“ value = „‚.$einpost->id.'“ hidden/></br>‘;
       echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“/></br>‘;
       echo ‚Nachname: <input type=“text“ name=“nachname“ value = „‚.$einpost->nachname.'“></br>‘;

       echo ‚<input type=“submit“ name = „speichern“ value=“Änderungen speichern“/>‘.“<br>“;
       } //end von nicht isset
       echo „</div>“;

echo ‚</form>‘;
// End Formular

} //end foreach

Damit verschwindet das Formular, sobald auf den „Änderungen speichern“-Button geklickt wurde.

Der Update wie gehabt

An der Update-Logik ändert sich auch nicht das Geringste, die übernehmen wie 1:1.

Zurück zur Adressenliste

Jetzt fehlt noch ein Link zurück zur Adressenliste, und auch das mach ich kurz und schmerzlos mit der URL der ersten Seite des Plugins:

echo „<a href = ‚http://localhost/turnverein/wp-admin/admin.php?page=adressen-tabelle’/><h1>Zurück zur Adressenliste</h1></a>“;

Sie müssen hier natürlich ihre eigene URL einsetzen, aber das sollte ja nun wirklich kein Problem sein. Funktionierts? Nach dem Klick auf „Zurück zur Adressenliste“ sollte jetzt natürlich wieder unsere Adressentabelle auftauchen, mit den eben gemachten Änderungen.

Funktioniert – aber wie sieht denn das aus? Nacktes PHP!

Gemach, gemach, hier ging es um die Funktionalität. Zugegeben, besonders schön ist das nicht mit dem „weissen“ Unterformular ohne die gewohnte WordPress-Umgebung, aber das zu ändern ist nicht wirklich einfach, da bin ich noch am Forschen. Die Lösung könnte evtl. in diesem Artikel stecken oder auch hier, aber da bin ich noch nicht ganz durch. Ich halte euch auf dem Laufenden, wenn da mal eine Lösung in Sicht kommt.

Tabelleneditor Nachschlag: Adressenliste als Ausgangspunkt

Ihr Wunsch ist mir Befehl: Tabellarische Adressenliste

Ich bin gebeten worden, einmal exemplarisch darzustellen, wie man den Tabelleneditor ausgehend von einer Liste aller Mitglieder aufruft. Das ist jetzt zwar echt wieder reines PHP, aber wenns gewünscht wird, na bitte, dann machen wir das auch noch. Wie soll das ganze aussehen? Also, zuerst zeigen wir mal eine Liste ausgewählter Mitgliederdaten an. In jeder Tabellenzeile soll es einen „Edit“-Button geben, und der soll das Tabelleneditorfenster zum aktuellen Datensatz aufmachen, hier die Funktionalität wie gehabt mit editieren und speichern der einzelnen Felder. Von hier aus solls auch wieder zurückgehen in die tabellarische Übersicht. Soweit OK?

Damit das nicht langweilig wird, arbeiten wir mit einer zweiten PHP-Datei für das Editor-Fenster, da kommen dann noch ein paar kleine Tricks mit dazu, wie man die WordPress-Funktionalität in eigenen PHP-Skripten nutzen kann, aber dazu später mehr, jetzt fangen wir mal ganz langsam an.

Die Ausgangsbasis: Tabellarische Mitgliederliste

Das ist auch nichts Neues, wir lassen einen Select* auf unsere Adressentabelle los und bauen uns erstmal eine tabellarische Ausgabe ausgewählter Felder. Das haben wir schon oft genug gemacht, das stell ich mal kommentarlos hier hin.

/*****Haupttabelle Name als Konstante definieren*******/
       define(„MAINTABLE“,“mitglieder_stamm“);
       echo „<h2>Mitglieder Adressenliste</h2>“;
       echo „Aktuelle Tabelle =&nbsp“.MAINTABLE.“<br>“;

       //Originalcode alle Datensätze holen
       global $wpdb;
       $alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.““);

echo „<table‘>“;

   // Titelzeile ausgeben
   echo „<thead>“;
   echo „<th>ID</th><th>Vorname</th><th>Nachname</th><th>PLZ</th><th>Ort</th><th>StrasseHausnr</th>“;
   echo „</thead>“;

   echo „<tbody>“;
   //Eine Zeile pro Datensatz ausgeben
   foreach ( $alleposts as $einpost ) {

       echo „<tr><td>“.$einpost->id.“</td>“;
       echo „<td>“.$einpost->vorname.“</td>“;
       echo „<td>“.$einpost->nachname.“</td>“;
       echo „<td>“.$einpost->plz.“</td>“;
       echo „<td>“.$einpost->ort.“</td>“;
       echo „<td>“.$einpost->strassehausnummer.“</td>“;
       echo „</tr>“;
   }
   echo „</tbody>“;
echo „</table>“;
//Ende Originalcode Datensätze holen

Wo kommt jetzt unser „Edit“-Button hin?

In ein Formular natürlich. Das wickeln wir wieder in unsere Foreach-Schleife mit ein, mit einer entscheidenden Änderung: das Formular kriegt einen Action-Tag, in dem wird definiert, welche Datei beim Klicken auf den Submit-Button aufgerufen werden soll. Das sieht so aus:

foreach ( $alleposts as $einpost ) {

       echo ‚<form method=“post“ action = „‚.$meinplugin_URL.'“>‘;
       echo „<tr><td>ID: &nbsp“.$einpost->id.“<input type=’text‘ name=’id‘ value = „.$einpost->id.“ hidden/></td>“;
       echo „<td>“.$einpost->vorname.“</td>“;
       echo „<td>“.$einpost->nachname.“</td>“;
       echo „<td>“.$einpost->plz.“</td>“;
       echo „<td>“.$einpost->ort.“</td>“;
       echo „<td>“.$einpost->strassehausnummer.“</td>“;
       echo ‚<td><input type=“submit“ name = „edit“ value=“Edit“/>‘;
       echo ‚</form></td>‘;
       echo „</tr>“;

   } // end foreach

Definition der aufzurufenden PHP-Datei

Hoppala! Was hat das $meinplugin_URL zu bedeuten? Das ist eine Variable, auf die ich vorher die aufzurufende Datei mit dem kompletten Pfad gelegt habe. Die Variablendefinition sieht so aus:

/*Pfad zum plugin-Verzeichnis*/
$meinplugin_URL = plugins_url();
/*Verzeichnis des aktuellen Plugins dranhängen*/
$meinplugin_URL=$meinplugin_URL.‘/adresse-tabelle/edit-adresse.php‚;

Ich hole mir erst mit der Funktion plugins_url() den Pfad zum Plugins-Verzeichnis meiner WordPress-Instanz. Dann hänge ich noch das Verzeichnis meines Plugins und den Namen der aufzurufenden Datei dran. Die Datei muss natürlich existieren, deswegen legen wir sie uns zum Testen jetzt einfach an. Sie muss erstmal gar nix machen ausser:

<?php
echo „Ich bin die Datei edit-adresse.php“;
?>

Soweit alles Roger? Wenn das Plugin aktiviert ist, sollte es jetzt etwa so aussehen:

adressenliste_edit

Und was kommt bei Klick auf einen Edit-Button?

Nicht viel, wir haben ja nicht viel gemacht. Ein grosses weisses Browserfenster, auf dem nur steht:

Ich bin die Datei edit-adresse.php

Wo ist unsere WordPress-Umgebung hinverschwunden? Header und Sidebars und das Titelbild und alles – nix da, aber auch gar nix. Tscha, so einfach ist das nicht mit unserer „nackerten“ PHP-Datei, aber darum kümmern wir uns später, jetzt geht es erstmal um die Funktionalität.

Wir brauchen die ID des aktuellen Datensatzes!

Und die kriegen wir auch, nämlich aus unserem abgeschickten Formular. Wir ergänzen die Datei edit-adresse.php so:

<?php
$akt_id = $_POST[„id“];
echo „Ich bin die Datei edit-adresse.php und die aktuelle ID ist: &nbsp“.$akt_id;
?>

Für das $_POST[„id“] muss natürlich der Feldname aus dem Formular stimmen, sonst klappt das nicht. Aber wenn das alles hinhaut, sollte die Ausgabe jetzt so aussehen:

Ich bin die Datei edit-adresse.php und die aktuelle ID ist: 7

Vorausgesetzt, sie haben den Datensatz mit der ID 7 angeklickt. Also, damit kann man jetzt arbeiten. Wir zeigen den Datensatz zur aktuellen ID an und machens mit dem editieren und speichern ganz genauso wie im vorigen Plugin. Oder doch nicht?

Uns fehlt noch das wpdb-Objekt!

Das steht nämlich in unserer Datei edit-adresse.php so wie sie ist erstmal nicht zur Verfügung. Noch nicht, wir holen uns die Funktionalität schon noch, aber dazu gibts einen neuen Beitrag.

Datenbankeditor die Letzte: Source als ZIP und Ausblick

Der Datenbankeditor kann jetzt marschieren

Das war jetzt (fast) reines HTML/PHP, und man kann das Prinzip des Datenbankeditors ja auch auf MySQL-Tabellen ausserhalb von WordPress anwenden, dann gehts halt nicht mit der $wpdb->update Methode, sondern mit einem pdo und einem Prepared Statement. Das hat jetzt aber wirklich gar nichts mehr mit WordPress zu tun, da schenke ich mir jetzt eine längere Erklärung und verweise für den Update in PHP auf diesen Artikel . Lieber gebe ich hier noch einen kleinen Ausblick.

Editor für alle Fälle, für jede eigene Tabelle

Jedenfalls habe ich hoffentlich verständlich dargestellt, wie man in WordPress Datensätze aus beliebigen MYSQL-Tabellen anzeigen, editieren und wieder wegschreiben kann. Diese Funktionalität ist immer wieder mal gefragt, besonders wenn man mit eigenen Tabellen arbeitet, für die hat man ja in WordPress erstmal kein Benutzerinterface. Ich habs jetzt mal als Plugin gezeigt, das nur der Admin bedienen darf. Wenn sie einen Tabelleneditor für die Benutzerseite anlegen wollen, packen sie die Funktionalität in einen Shortdode, geht genauso.

Man könnte jetzt noch ehrgeizig werden und zum Beispiel statt der manuellen Eingabe der ID (in unserem Fall der Mitgliedsnummer) auch die Auswahl aus einer Liste anbieten wollen, oder man könnte eine Liste aller Mitglieder ausgeben und nach jedem Datensatz einen „Ändern“-Button anzeigen, der dann in den Datenbankeditor springt, oder oder oder… aber da gehts echt verschärft nach PHP, das darf sich jeder selber austüfteln.

Jetzt gibts noch wie versprochen hier das Plugin adressen-editor als ZIP-Datei, und damit lassen wir es gut sein. Viel Spaß beim Anpassen an ihre eigenen Tabellen!

Datenbankeditor die Vierte: Änderungen speichern

Jetzt haben wir unsere Adressdaten editiert, und nu?

Speichern wollen wir sie natürlich noch, und dafür darf wieder unser wpdb-Objekt herhalten. Welche Daten wir speichern wollen, lesen wir aus dem Unterformular, das sind unsere Werte aus $_POST[‚feldname‘], wobei „feldname“ im Formular festgelegt ist. Ich hab hier einfach die selben Bezeichnungen wie die der Datenbankfelder genommen, das ist am leichtesten zu lesen. Nochmal kurz zur Erinnerung, das Formularfeld für den Vornamen haben wir so definiert:

echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“/></br>‘;

Den aktuellen Wert (den der Benutzer evtl. editiert hat) legen wir nach dem Klick auf den „Änderungen speichern“- Button der besseren Übersicht halber auf eine Variable:

if (isset($_POST[’speichern‘])){

$neu_vorname = $_POST[‚vorname‘];

}

Wichtig ist hier die richtige Positionierung der If-Isset-Abfrage, die muß nach der schließenden Klammer der ersten If-Isset-Abfrage aus dem Hauptformular hin. Wir legen uns alle Feldinhalte des Unterformulars auf Variable, und die verarbeiten wir dann in einem Update auf die Datenbank weiter.

Ein bißchen unhandlich: die wpdb-Update Methode

Ein kurzer Blick in den Codex, und es könnte einem etwas das Gruseln kommen. Da wird mit Arrays hantiert und mit Formaten und was weiß ich noch alles, und dabei wollen wir doch nur einen stinknormalen Update auf einen einzelnen Datensatz fahren. Na ja, ich versuchs mal aufzudröseln. In diesem Artikel (runterscrollen bis UPDATING DATA in Sicht kommt) ist es recht einleuchtend beschrieben, wie man mit der Update-Methode umgeht. Das sieht dann so aus:

global $wpdb;

   $wpdb->update(
    “.MAINTABLE.“,
    array(
        ‚vorname‘ => $neu_vorname // string

    ),
    array( ‚id‘ => $ID ),
    array(
        ‚%s‘   // value1

    ),
    array( ‚%d‘ )
);

Ich gebe den Tabellennamen wieder mit der Konstanten MAINTABLE mit. Dann gehts los.

Wir benutzen die Methode $wpdb->update().
Im ersten Array wird definiert, welches Feld (hier ‚vorname‚) mit welchem Wert (hier $neu_vorname) aktualisiert werden soll.
Das zweite Array legt die WHERE-Klausel fest, in unserem Fall wird das Feld id mit dem Wert der Variablen $ID verglichen, die habe ich vorher in der Isset-Auswertung mit dem Wert der id aus dem Formular belegt..
Das dritte Array legt fest, welches Format das zu updatende Feld hat. Da wir es nur mit Textfeldern zu tun haben, ist das immer ein %s (für String).
Im vierten Array wird definiert, welches Format das Feld in der WHERE-Klausel hat. Ich habe hier ein %d (für Dezimal) angegeben, da wir es mit einem ganzzahligen Wert zu tun haben.

Wie ich schon sagte, ein bißchen unhandlich und gewöhnungsbedürftig, aber letztendlich funktionierts, und das ist die Hauptsache. Einige der genannten Parameter sind optional, aber ich habe noch nicht genau herausgetüftelt welche, wir verwenden das jetzt mal so wie es ist.

Wichtig: wir updaten immer alle Felder

Man könnte auf die Idee kommen und erstmal abfragen, in welchen Feldern Änderungen vorgenommen wurden, aber die Update-Methode macht das von selber, also kann man sich den Aufwand schenken. Also packen wir uns bei Klick auf den „Änderungen speichern“ – Button einfach immer alle Felder aus dem Formular und schreiben sie mit dem Update in die Datenbank.

Boing, reingefallen: disabled ist komplett disabled, ätsch!

Und wenn der Update jetzt nicht klappt, liegt es daran, daß ich im Formular das Feld für die ID auf „disabled“ gestellt habe, damit man die ID nicht versehentlich ändern kann. Damit kann ich aber den Wert des Formularfeldes nicht mehr abfragen! Beliebter Fehler, mir wars bloß entfallen. Das müssen wir noch ändern. Ich stelle das Feld auf „hidden“ und gebe die ID nur zur Kontrolle mit aus. Die Zeile im Formular sieht jetzt so aus:

echo ‚ID: &nbsp‘.$einpost->id.'<input type=“text“ name=“id“ value = „‚.$einpost->id.'“ hidden/></br>‘;

Es wäre ohnehin nichts passiert, weil wir in unserem Update das Feld id gar nicht mit drin haben, aber so ist es logischer und für den Benutzer besser verständlich.

Der Update für den kompletten Datensatz

… wird genau nach obigem Muster zusammengebaut. Ich lege mir die Formularinhalte auf Variable, und setze diese in das Array im Update ein. Dabei auf die richtigen Kommas hinter den Argumenten achten!

Ich mach mal nur noch zwei weitere Felder beispielhaft, den Nachnamen und die E-Mail-Adresse, denn Rest können sie nach Belieben selber noch einbauen. Wir geben dann noch eine Meldung aus, daß die Änderungen gespeichert sind, und das wars. Wenn unser Benutzer jetzt auf „Änderungen speichern“ klickt, passiert Folgendes:

if (isset($_POST[’speichern‘])){

   $ID = $_POST[‚id‘];
   $neu_vorname = $_POST[‚vorname‘];
   $neu_nachname = $_POST[’nachname‘];
   $neu_your_email = $_POST[‚your_email‘];

   global $wpdb;

   $wpdb->update(
    “.MAINTABLE.“,
    array(
        ‚vorname‘ => $neu_vorname, // string
        ’nachname‘ => $neu_nachname, //string
       ‚your_email‘ => $neu_your_email //string
    ),
    array( ‚id‘ => $ID ),
    array(
        ‚%s‘,     // value1
        ‚%s‘,   // value2
       ‚%s‘   // value3
    ),
    array( ‚%d‘ )
);

   echo „<h1>Änderungen gespeichert</h1>“;

} //ende von if isset post speichern

Das wars! Wenn man jetzt die Änderungen sehen will, ruft man einfach nochmal die selbe ID auf, und da sind sie auch schon – wenn alles geklappt hat. Ich geb nachher das ganze Plugin noch als ZIP-Datei mit, dann können sie’s genau nachvollziehen.

Für Perfektionisten: Abfragen, ob der Update geklappt hat

Die Update-Methode des wpdb-Objekts hat auch Rückgabewerte, ich zitiere mal kurz den Codex:

UPDATE rows

Update a row in the table. Returns false if errors, or the number of rows affected if successful.

Man kann sich jetzt den Update auch auf eine Variable legen, das sieht dann zum Besipiel so aus:

$speichern=$wpdb->update(…Parameterarrays…)

Dann kann man die Variable $speichern entsprechend nach dem Rückgabewert auswerten und ausgeben. Falls sie „false“ zurückgeben sollte, hat man übrigens ein echtes Problem, dann haut die Verbindung zur Datenbank aus irgendeinem Grund nicht hin… ist mir aber noch nie passiert. Ich machs ganz einfach und gebe nur aus, wieviele Zeilen von dem Update betroffen waren:

echo $speichern.“&nbsp Datensätze geändert“;

Hier kommt übrigens 0 (Null) zurück, wenn der Benutzer zwar keine Änderungen gemacht, aber trotzdem auf „Änderungen speichern“ geklickt hat. Das liegt daran, daß der Update nichts tut, wenn die zu speichernden Werte mit den bereits vorhandenen Werten in der Tabelle identisch sind. Aber das sind jetzt echt Feinheiten, da können sich Perfektionisten selber durchrecherchieren, ich mach hier mal nen Punkt, und einen neuen Beitrag.

Datenbankeditor die Dritte: Formular im Formular

Editierbare Felder – bloß wie?

Wir waren dabei stehengeblieben, daß wir die Adressdaten zu einer vom Benutzer eingegebenen Mitgliedsnummer angezeigt haben. Jetzt gehts zum nächsten Schritt, wir wollen die Daten ja nicht nur anzeigen, sondern auch ändern. Dafür nehmen wir – ein Formular! Und zwar innerhalb unserer Foreach-Schleife, wir wollen ja genau den Inhalt des einen von unserem Select zurückgegebenen Datensatzes ausgeben.

Das Unterformular in der Foreach-Schleife

Das ist keine Hexerei, sondern ein stinknormales Formular mit einem Submit-Button. Die Konstruktion beginnt so:

foreach ( $alleposts as $einpost ) {

//Begin Formular
echo „<form method=“post“>“;

//Hier kommen die Formularfelder hin

echo ‚<input type=“submit“ name = „speichern“ value=“Änderungen speichern“/>‘.“<br>“;

echo „</form>“;
// End Formular

} //end foreach

Werte (values) der Input-Felder vorbelegen

Wir nehmen ganz normale Text-Inputfelder, und jetzt kommt der Witz an der ganzen Sache: sie werden mit unseren Feldinhalten aus der Datenbank gefüllt. Das geht ganz einfach, wir sind ja innerhalb der Foreach-Schleife und kommen z.B. mit $einpost->vorname an den Wert des Vornamen-Feldes ran. Das editierbare Formularfeld für den Vornamen mit Vorbelegung sieht dann so aus:

echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“></br>‘;

Hier muss man mit den doppelten und den einfachen Anführungszeichen ein bißchen aufpassen, aber ich pack euch nachher den Code noch in ein ZIP-File, dann habt ihrs ganz genau. Falls die Ausgabe eines Values beim ersten Leerzeichen abgeschnitten wird, stimmt was mit den Anführungszeichen nicht, darüber fällt man am Anfang gerne.

Das Feld für die ID (Mitgliedsnummer) kriegt eine Sonderbehandlung, das soll ja um Himmels Willen nicht geändert werden, auch nicht versehentlich, deswegen setzen wir es gleich auf disabled:

echo ‚ID: <input type=“text“ name=“id“ value = „‚.$einpost->id.'“ disabled></br>‘;

Die anderen Felder (Nachname, Telefon, Ort usw.) werden ganz genau so wie oben beim Vornamen konstruiert, so sieht das fertige Produkt dann aus:

unterformular_screenshot

Ich hab noch einen <div> mit einem Rahmen um die ganze Sache gelegt und die Felder für E-Mail und Strasse mit size=“50″ grösser gemacht, aber das wars dann schon. Eure Bildschirmanzeige nach Abschicken der Mitgliedsnummer sollte jetzt etwa so aussehen:

unterformular_anzeige

Sieht doch schon mal ganz gut aus, oder? Jetzt müßte nur noch etwas passieren, wenn man auf „Änderungen speichern“ klickt, aber dazu gibts einen neuen Beitrag.

Datenbankeditor die Zweite: ID abfragen und Adressdaten anzeigen

Mitgliedsnummer abfragen

Dafür – wie könnte es anders sein – brauchen wir ein kleines Formular. Das können wir eigentlich schon, so sieht das aus:

//Begin Formular
echo ‚<form method=“post“>‘;
echo ‚Mitgliedsnummer: <input type=“text“ name=“m_nr“ /></br>‘;
echo ‚<input type=“submit“ name = „senden“ value=“Abschicken“/>‘.“<br>“;
echo „</form>“;
// End Formular

Die eingegebene Mitgliedsnummer holen wir uns wie gehabt nach drücken des „Abschicken“-Buttons in eine Variable, dazu braucht es nicht mehr als das:

if (isset($_POST[’senden‘]))
{

$akt_m_nr = $_POST[‚m_nr‘];

}

Ausgabe der Adressdaten zur eingegebenen Mitgliedsnummer

Jetzt gehts auf die Datenbank. Wir arbeiten wie gewohnt mit einem wpdb-Objekt, und setzen in den Select einfach unsere Variable $akt_m_nr ein, die enthält ja die Mitglieds-ID. (Ich habe weiter oben wieder den Namen der aktuellen Tabelle auf die Konstante MAINTABLE gelegt)

global $wpdb;
$alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.“ where ID = „.$akt_m_nr.““);

Ergebnis: genau ein Datensatz, nämlich der mit der eingegebenen ID. Ausgabe mit Foreach, auch das wie gehabt. Ich formatiere die ganze Sache als Tabelle, damit es übersichtlicher wird.

adresstabelle

Die Ausgabe der Titelzeile der Tabelle ist hier im Screenshot leider abgeschnitten, aber die entsprechenden <th>-Tags kann man sich ja leicht dazudenken. Das Ergebnis nach Eingabe einer existierenden Mitgliedsnummer und drücken des „Abschicken“-Buttons sollte jetzt ungefähr so aussehen:

adresstabelle_screenshot

Ist doch schon mal ganz brauchbar. Jetzt müßte man die Adressdaten nur noch editieren können, aber dazu gibts einen neuen Beitrag – morgen.

Das zweite Plugin: wir basteln uns einen Datenbank-Editor

Zur Erinnerung: wir arbeiten mit eigenen Tabellen

Im Turnverein Weiß-Blau gibt es ja unser tolles Anmeldeformular, mit dem die Mitgliederdaten Online erfaßt werden. Das Formular haben wir mit Contact Form 7 schnell gebaut, und mit Save Contact Form 7 schreiben wir uns die Daten gleich in eine Tabelle weg. So weit so gut, aber was machen wir jetzt, wenn sich Daten ändern? Neue Telefonnummer, andere Adresse nach Umzug, andere E-Mail-Adresse? Mit phpMyadmin direkt auf der Datenbank ändern? Natürlich nicht. Das geht komfortabler, aber ich warne sie gleich: das wird ein Ausflug ins reine PHP und hat mit WordPress nur am Rande was zu tun. Aber man braucht diese Funktionalität immer wieder, deshalb werden wir uns etwas ausführlicher damit befassen.

Plugin oder Shortcode?

Ist prinzipiell Geschmackssache, aber da ja nicht jeder Hinz und Kunz die Mitgliederdaten ändern können soll, ist der Datenbankeditor auf dem Admin Screen gut aufgehoben, also nehmen wir ein Plugin, das nur vom Administrator bedient wird.

Was soll das Plugin können?

Ich gehe mal davon aus, daß der Admin die Mitgliedsnummer (die ID aus der Datenbank natürlich!) des Vereinsmitgliedes kennt, dessen Daten er ändern will. Also fragen wir zuerst mal die Mitgliedsnummer ab. Dann soll der Datensatz zu dieser Mitgliedsnummer angezeigt werden. Jetzt wollen wir noch die angezeigten Daten ändern können, und ganz am Ende brauchen wir noch eine Funktionalität für das Speichern der Änderungen.

Das ist ein ganzer Haufen Holz, aber Schritt für Schritt mit PHP geht das schon. Wenn sie schon ein Fex mit der Formularprogrammierung auf der Datenbank sind, entlockt ihnen das alles wahrscheinlich nur ein müdes Lächeln, aber ich bekomme zur Formularprogrammierung immer so viele Rückfragen, da scheint doch einiger Erklärungsbedarf zu bestehen.

Wo fangen wir an? Bei der Plugin-Definition.

Wir legen das Plugin-Unterverzeichnis an, erstellen unsere erste PHP-Datei und versehen sie mit dem passenden Header. Mein Unterverzeichnis heißt adressen-editor, und die PHP-Datei dann logo adressen-editor.php. Der Header des PHP-Scripts sieht so aus:

/*
Plugin Name: Adressen Editor
Plugin URI: http://localhost/wordpress/wp-content/plugins/adressen-editor
Description: Ändern von Mitglieder-Adressdaten auf der Datenbank
Version: 1.0
Author: Evi Leu
Author URI: http://www.evileu.de
*/

Sie erinnern sich, das sind die Parameter die WordPress für das Plugin-Verzeichnis ausliest.

Der Eintrag für das Admin-Menü

Damit es nicht zu Kollisionen mit unserem ersten Plugin kommt, muss man hier auf eindeutige Funktionsbenennungen achten. Zum Beispiel so (die angepassten Namen fett):

add_action(‚admin_menu‘, ‚AdressenEditorMenu‚);

function AdressenEditorMenu() {
$appName = ‚Adressen Editor‘;
$appID = ‚adressen-editor‘;
add_menu_page($appName, $appName, ‚administrator‘, $appID, ‚pluginAdressenEditor‚);
}

Die Plugin-Funktion

Und so heißt jetzt unsere Plugin-Hauptfunktion, die tut erstmal noch nichts als eine Überschrift ausgeben:

function pluginAdressenEditor() {
echo „<h1>Adressen Editor</h1>“;
}

PHP-Datei ins Plugin-Verzeichnis schieben, im Plugin-Menü aktivieren, und unser neuer Menüpunkt Adressen Editor sollte schon mal da und funktional sein. Wie wir jetzt zu unserer ID und auf die Datenbank kommen, dazu gibts einen neuen Beitrag.