Archiv der Kategorie: WordPress

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.

Unser erstes Plugin: SetzeCode 1, die Plugin-Definition

Was ist eigentlich ein Plugin?

Ganz vereinfacht gesagt: ein Plugin ist eine Funktionserweiterung des Admin Panels. Es bekommt einen eigenen Menüeintrag (kann man nach Belieben definieren, später mehr dazu), und man kann eine Funktion hinterlegen, die bei Aufruf des Menüeintrags ausgeführt wird.

Was soll unser Plugin können?

Wir wollen den Wert einer Option in der Tabelle wp_options setzen bzw. ändern. Dafür brauchen wir ein Eingabefeld, in das der Benutzer seinen Optionswert eintragen kann, und einen „Abschicken“-Button, der den Neueintrag setzt. Das wars eigentlich schon, und wir lösen das natürlich mit einem kleinen Formular, aber dazu später mehr. Jetzt gehts erstmal darum:

Wie definiere ich ein Plugin?

Dafür legt man sich eine PHP-Datei an, die bestimmten Anforderungen entsprechen muss (gleich mehr). Dieser Datei gibt man einen aussagekräftigen Namen, in unserem Fall z.B. setze_code.php. Dann legt man sich unterhalb des WordPress-Verzeichnisses …wp-content/plugins ein eigenes neues Verzeichnis für das Plugin an und benennt es entsprechend, also z. B. …wp-content/plugins/setze-code. In dieses Verzeichnis schieben wir später unsere PHP-Datei rein, aber jetzt füllen wir sie erstmal mit Funktionalität.

Der Header des Plugin-Skripts

WordPress liest aus dem Header die relevanten Plugin-Informationen zur Darstellung im Plugins-Menü, der muss also bestimmten Anforderungen genügen. Das sieht beispielsweise so aus:

/*
Plugin Name: SetzeCode
Plugin URI: http://localhost/wordpress/wp-content/plugins/SetzeCode
Description: Setzt eine Option für einen benutzerdefinierten Code
Version: 1.0
Author: Evi Leu
Author URI: http://www.evileu.de
*/

Die fett markierten Schlüsselwörter müssen ganz genau so geschrieben werden wie sie hier zu sehen sind, inklusive der Kommentar-Tags (/*). Die hinter den Schlüsselwörtern hinterlegten Informationen kann man frei formulieren, aber es sollten schon sinnvolle Informationen sein, die man hier einträgt, die tauchen dann nämlich im Plugins Menü auf:

pluginscreen

Alles klar soweit mit dem Header? Dann gehts weiter mit dem:

Eintrag im Admin-Panel

Mit der Funktion add_action() wird WordPress angewiesen, eine neue Funktionalität hinzuzufügen. Wir wollen das im Admin Panel tun, also kriegt der erste Parameter den Wert „admin_menu“ mit. Der zweite Parameter benennt die Funktion, die bei Aufruf des Menüeintrags ausgeführt werden soll.

add_action(‚admin_menu‘, ‚basicPluginMenu‘);

Die Funktion ‚basicPluginMenu‘ sieht für unser Plugin folgendermassen aus:

function basicPluginMenu() {
$appName = ‚SetzeCode‘;
$appID = ’setze-code‘;
add_menu_page($appName, $appName, ‚administrator‘, $appID, ‚pluginAdminScreen‘);
}

Mehr zur Funktion add_menu_page() im Codex, ich machs hier mal kurz, als Parameter werden hier als absolutes Minimum mitgegeben:

Seitentitel (wird im Browsertab angezeigt)
Menütitel (Wird im Adminmenü angezeigt
Rolle (administrator ist hier völlig OK, sind ja nur wir)
Slug (taucht im Permalink wieder auf)
Auszuführende Funktion

Das erstellt uns einen neuen Menüeintrag unten am Ende des Admin Panels, und der heißt – oh was wohl?

SetzeCode

Man könnte den Menüeintrag auch anders positionieren und z.B. ins Untermenü Werkzeuge verschieben, und ein anderes Icon auswählen und und und, aber das sparen wir uns jetzt mal, es geht rein um die Funktionalität.

Die Funktion, die das Plugin ausführen soll

Haben wir oben mit pluginAdminScreen benamst, und die definieren wir uns gleich im nächsten Beitrag. Jetzt machen wir erstmal was ganz banales, wir geben mal nur eine Titelzeile für unser Plugin aus:

function pluginAdminScreen() {
echo „<h1>Setze Meinen Code</h1>“;
}

Funzt alles? Menüeintrag vorhanden, Überschrift wird ausgegeben? Na fein, dann basteln wir uns die Options-setzen-Funktion im nächsten Beitrag. Hier folgt mal noch zur Kontrolle der komplette Code der setze_code.php:

<?php
/*
Plugin Name: SetzeCode
Plugin URI: http://localhost/wordpress/wp-content/plugins/SetzeCode
Description: Setzt eine Option für einen benutzerdefinierten Code
Version: 1.0
Author: Evi Leu
Author URI: http://www.evileu.de
*/
add_action(‚admin_menu‘, ‚basicPluginMenu‘);

function basicPluginMenu() {
$appName = ‚SetzeCode‘;
$appID = ’setze-code‘;
add_menu_page($appName, $appName, ‚administrator‘, $appID, ‚pluginAdminScreen‘);
}

function pluginAdminScreen() {
echo „<h1>Setze Meinen Code</h1>“;
}
?>

Options: benutzerdefinierte globale Variable

Wozu globale Variable?

Manchmal braucht man Werte, die global in WordPress zur Verfügung stehen sollen. Man kann natürlich Shortcodes definieren, die nur einen bestimmten Wert zurückgeben (return „ABCD“;), aber mit dem Shortcode ist man logischerweise abhängig vom Theme, wenn man das Theme wechselt ist auch der Shortcode und der Wert futsch. WordPress bietet da alternativ eine hübsch simple Möglichkeit, eigene Werte in der Datenbank abzulegen und auch wieder herauszuholen.

Die WordPress Options

Kurzer Blick in den Codex: add_option() legt ein Wertepaar (Option Name und Wert) in der WordPress-Tabelle wp_options ab. Mit get_option(‚optionsname‘) holt man sich den Wert bei Bedarf wieder heraus. Ich zitiere nochmal kurz den Codex:

If you are trying to ensure that a given option is created, use update_option() instead, which bypasses the option name check and updates the option with the desired value whether or not it exists.

Wir nehmen also lieber die Funktion update_option(), die uns auf jeden Fall den Datenbankeintrag anlegt, falls er noch nicht existiert. Das sieht dann etwa so aus:

update_option (‚mein_code‘, ‚Evis neuer Code‘);

Das ‚mein_code‚ ist der Name der Option, diese wird durch das update_option() neu angelegt, falls sie noch nicht existiert. Der zweite Parameter setzt den Wert (value) der neuen Option, hier habe ich einfach einen String eingesetzt. Das Feld option_value ist übrigens ein longtext, da können sie bis zu 2^32 Bytes speichern, also nur keine Hemmungen!

Wie sieht das in der Datenbank aus?

Braucht uns eigentlich nicht zu kümmern, da wir ja den Wert der Option nachher mit get_option() herausholen, aber ich zeigs mal der Vollständigkeit halber:

options

Die neue Option kriegt eine AutoIncrement-ID, in option_name landet der angegebene Name, in option_value der gewünschte Wert der Option, und das autoload wird defaultmäßig auf yes gesetzt und braucht uns nicht weiter zu kümmern.

Wie man den Wert der Option wieder herauskriegt

Ganz simpel. Mit get_option($option_name). Der Code für die Ausgabe sieht zum Beispiel so aus:

$akt_option = get_option (‚mein_code‘);
echo „Wert von akt_option :&nbsp“.$akt_option;

Das erzeugt die Ausgabe:

Wert von akt_option : Evis neuer Code

Eigentlich selbsterklärend.

Und wohin jetzt mit den update- und get- Anweisungen? Dafür (täterätää!) schreiben wir unser erstes Plugin, und dazu gibts natürlich einen neuen Beitrag.

Nachschlag: Kategorien schöner ausgeben leicht gemacht

Kategorienliste

Erinnern sie sich, bei der Rezeptausgabe hatte ich das Problem, daß ich hinter jeder Kategorie in der Liste ein Komma hatte, auch hinter der letzten, und das war nicht so schön.

alleposts_mit_kategorien

Jetzt bin ich gerdae über eine WordPress-Funktion gestolpert, die das wesentlich hübscher macht, und einen gleich mit den Links zu den Kategorien mit versorgt. Kurzer Blick in den Codex: get_the_category_list

Die Funktion gibt die Kategorienliste zu einer beliebigen Beitrags-ID aus, das sieht z.B. so aus:

$ausgabe = get_the_category_list( ‚,‘,“,1270);
echo „Kategorien: &nbsp“.$ausgabe;

Ergebnis (mit funktionalen Links):

Kategorien: Echt Bairisch,Plauderei,Single-Küche

Man kann als Seperator übrigens beliebige Strings setzen, ich nehm mal ein “ + „:

Kategorien: Echt Bairisch + Plauderei + Single-Küche

Das sieht doch gleich viel besser aus!

Schlagwortliste

Eine ähnliche Funktion gibt es auch für die Schlagworte, die nennt sich get_the_tag_list, hier lohnt ebenfalls ein Blick in den Codex:

https://codex.wordpress.org/Function_Reference/get_the_tag_list

Diese kleinen Nützlinge kann man immer wieder mal brauchen.

Schmankerl für alte Datenbanker: Zugriff auf externe Daten mit dem wpdb-Objekt

Was viele nicht wissen: Zugriff auf beliebige MySQL-Datenbanken in WordPress ganz einfach

Mit dem wpdb-Objekt sind wir ja inzwischen schon per Du, da hab ich schon genug Anwendungsbeispiele geliefert. Jetzt setz ich noch eins obendrauf: wir holen uns mal Daten aus einer externen MySQL-Datenbank. Das kann die DB einer anderen WordPress-Instanz sein, muß aber nicht, irgendeine gehostete MySQL-DB tuts auch. Wir brauchen dazu nur den Connect, also ganz das Übliche:

Datenbankserver
Datenbankname
Datenbankuser
Datenbankpasswort

Und schon kann es losgehen. Ich leg mir die Connect-Daten gern auf Variable, das sieht dann z.B. so aus:

$user = ‚U12345678‘;
$password = ‚meinPasswort‘;
$database = ‚DB12345678‘;
$server = ‚rdbms.strato.de‘;

Der externe Connect mit dem wpdb-Objekt

Voraussetzung ist natürlich, daß vorneweg global $wpdb deklariert wurde. Dann gehts ganz einfach:

$wpdb = new wpdb($user, $password, $database, $server);

Damit legen wir ein neues wpdb-Objekt an, das auf die externe Datenbank zugreift. Jetzt können wir nach Belieben auf die Tabellen in der externen Datenbank zugreifen, zum Beispiel so:

Der SELECT geht wie gehabt

$rows = $wpdb->get_results(„SELECT * FROM beispieltabelle“);

Das dürfte ihnen jetzt aber doch schwer bekannt vorkommen! Mit dem $wpdb->get_results haben wir ja schon die ganze Zeit gearbeitet, der gibt wie üblich ein Array zurück, das das Ergebnis des Select enthält.

Der FOREACH – auch wie gehabt

Auch hier ändert sich gar nichts, man greift über die Feldnamen der externen Tabelle zu und formatiert sich seine Ausgabe nach Wunsch, zum Beispiel so:

foreach ($rows as $obj) :

   echo „<h1>“.$obj->feldname_1.“</h1>“;
   echo „<h2>“.$obj->feldname_2.“</h2>“;
   echo „<p>“.$obj->feldname_3.“</p>“;

endforeach;

Das wars schon! Wenn sie den Connect String haben, können sie aus WordPress heraus auf jede beliebige Datenbank im Web zugreifen und die gewohnten wpdb-Methoden dafür verwenden. Ist immer wieder mal nützlich!

Mitgliederverzeichnis mit Adressdaten

Wir basteln uns ein Mitgliederverzeichnis

Damit wir von unserer tabellarischen Ausgabe zu einem vernünftigen Mitgliederverzeichnis komplett mit Fotos kommen, ist ein wenig Handarbeit angesagt, wie immer, wenn man es in WordPress mit einzelnen Beiträgen zu tun hat. Aber keine Bange, wir machen nur das absolute Minimum. Jetzt knüpfen wir uns die neuen Mitglieder der Reihe nach vor und legen uns zu jedem Mitglieds-Datensatz einen eigenen Beitrag an.

Dazu folgende Vorüberlegungen:

Wenn wir den Beitrag einfach mit Vorname und Name des Mitglieds betiteln, kann es zu Konflikten kommen, schließlich können wir mehr als einen „Peter Müller“ oder „Stefan Huber“ in unserer Mitgliederliste haben. Also stellen wir dem Namen einfach die automatisch vergebene id aus der Tabelle mitglieder_stamm voran, dann haben wir Eindeutigkeit. Und weil unsere Mitglieder untereinander per Du sind, verzichten wir auf den Nachnamen und sparen uns Tipparbeit. Unser erster Beitrag erhält also den Titel „1 Ferdinand“, der zweite wird „2 Marius“ heißen, der dritte „3 Ivonne“ usw., einfach der Reihe nach durch.
Das Paßfoto laden wir als Beitragsbild hoch (rechts unten im Beitragseditor bei „Beitragsbild festlegen“), dann haben wir für spätere Ausgaben Zugriff über darauf. Auch das haben wir schon mal gemacht, mit wp_get_attachment_url(get_post_thumbnail_id(post_ID))
Wir legen 1 benutzerdefiniertes Feld an, das heißt „mitglied_id“ und erhält als Inhalt (na was wohl?) unsere eindeutige id.

mitglied_id

4. Wenn wir den Beitrag für ein neues Mitglied vollständig angelegt haben, könnten wir das Feld „status“ in der Tabelle mitglieder_stamm von „neuzugang“ auf „aktiv“ stellen – jaja ich hörs schon, das sollte man programmgesteuert mit einem Update machen, aber wir operieren hier gerade mal auf einer Handvoll Testdaten, da reicht der manuelle Eintrag. Soll ja auch nur beispielhaft zeigen, daß der Bearbeitungsstand eines Mitgliederdatensatzes durch den Status mitprotokolliert werden kann.

Das wars schon! Den Rest holen wir uns aus der Datenbank, aber ich hol mir mal einen frischen Kaffee während sie die Beiträge anlegen 🙂

Vorüberlegung: was wollen wir im Mitgliederverzeichnis alles ausgeben?

Na, alles! Die kompletten Adressdaten, die sportlichen Präferenzen, das Paßfoto, den ganzen Summs möchten wir im Mitgliederverzeichnis sehen, ohne auch nur ein einziges weiteres Datenfeld manuell eingeben zu müssen. Uns reicht das benutzerdefinierte Feld mitglied_id, darüber verknüpfen wir uns die ganze Tabelle mitglieder_stamm und basteln uns die gewünschte Ausgabe.

Wie sieht es jetzt aus?

Das ist leider sehr abhängig vom Theme und läßt sich nicht so global sagen. Aber wenn sie jetzt auf ihre Beitragsseite gehen, müßten eigentlich die Beitragsbilder(Paßfotos) und die eingegebenen Beitragstitel (1 Ferdinand, 2 Marius…) aufgelistet werden. Manche Themes geben allerdings die Thumbnails (Beitragsbilder) in der Übersicht gar nicht mit aus. Wenn wir jetzt auf einen Beitragstitel klicken, sehen wir – nichts. Völlig korrekt, wir haben ja auch keinerlei Beitragstext eingegeben. Und unser benutzerdefiniertes Feld mitglied_id sehen wir auch nicht, weil es noch nicht in das Template mit eingebunden ist. Also, an die Arbeit. Wenn sie genau nachvollziehen wollen, an welcher Stelle welche Anpassungen wie greifen, wäre es sinnvoll, wenn sie das selbe Theme wie ich verwenden, es ist ein Child-Theme von Twentyfourteen.

Unsere Anpassungen an der single.php

Für die Darstellung der einzelnen Beiträge wird die single.php verwendet, und die nehmen wir uns jetzt vor. Machen sie eine Kopie der Originaldatei, legen sie sie in ihrem Child-Theme-Ordner ab und öffnen sie sie in einem Editor. Unsere Anpassungen erfolgen innerhalb des Loops, unmittelbar vor der Previous/next post navigation, hier im Screenshot wirds deutlich:

innerhalb_des_loops

Geben sie hier mal zum Testen nur die einzige Echo-Zeile ein und schauen sie sich einen Beitrag an, da darf nichts stehen ausser dem Text des echo.

Wie kriegen wir jetzt unsere Stammdaten hier rein?

Über eine Verknüpfung mit der Tabelle mitglieder_stamm über das benutzerdefinierte Feld mitglied_id. Wir geben als allererstes mal nur die mitglied_id aus, das machen wir so:

echo "<h2>Mitgliederdaten</h2>";
                    $akt_mitglied_id = get_post_meta($post->ID, 'mitglied_id', true);
                    echo "Aktuelle Mitglied ID:&nbsp".$akt_mitglied_id."<br>";

Der Witz steckt natürlich in der Funktion get_post_meta, die holt uns zur aktuellen WordPress-ID des Beitrags den Wert des benutzerdefinierten Feldes mit dem Namen „mitglied_id“. Das „true“ bewirkt, daß ein einzelner String ausgegeben wird, mehr brauchen wir nicht.

Jetzt müssen wir noch angeben, aus welcher Tabelle wir die Daten holen wollen, dazu lege ich den Tabellennamen wieder auf eine Konstante, damit man ihn später leicht auswechseln kann, und gönne mir noch eine Debug-Ausgabe.

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

Und jetzt haben wir schon alles, was wir für unseren Select brauchen! Der sieht so aus:

$alleposts = $wpdb->get_results( "SELECT * from ".MAINTABLE."
 WHERE id = '".$akt_mitglied_id."'");

Und schon haben wir den richtigen Datensatz anhand der Mitglieds-id herausgefischt! Die Ausgabe der einzelnen Felder erfolgt dann wie gehabt wieder mit einer Foreach-Schleife, ich gebe hier mal beispielhaft nur ein paar Felder aus:

foreach ( $alleposts as $einpost ) {             
                            
                            echo $einpost->vorname."<br>";
                            echo $einpost->nachname."<br>";
                            echo $einpost->ort."<br>";
                            echo $einpost->strassehausnummer."<br>";
                    }

Das Ergebnis

…ist noch nicht besonders hübsch formatiert, aber es zeigt das Prinzip:

maja_daten

Am schönsten sähe es natürlich aus, wenn man die Stammdaten tabellarisch ausgibt, aber das kann sich jeder selber einrichten wie er es möchte. Jedenfalls haben wir übere unsere Verknüpfung mit der mitglied_id Zugriff auf alle Datenfelder der Tabelle mitglieder_stamm, und das war ja genau das, um was es ging. So simpel ist die Lösung mit einer eigenen Tabelle für die Mitgliederdaten!

Klarer Vorteil gegenüber den benutzerdefinierten Feldern

Ausser der mitglied_id muß im Beitrag nichts per Hand eingegeben werden, das erspart einem einen Haufen (fehlerträchtiger) Handarbeit. Stellen sie sich nur mal vor, sie müßten jetzt zu allen Mitgliedern die vollständigen Adressdaten händisch in Custom Fields erfassen – also nee, echt nicht. Das haben wir eleganter gelöst. Und wenn es mal Änderungen an den Benutzerdaten geben sollte, auch die können wir in unser eigenen Tabelle mitglieder_stamm einpflegen, wir müssen dazu nicht den entsprechenden Beitrag bearbeiten. Auch das ist ein weiterer Vorteil, der nicht zu unterschätzen ist. Man kann sich auch mit PHP einen kleinen Mitgliederdaten-Editor basteln, vielleicht mach ich das später mal, das führt jetzt wirklich zu weit. Und jetzt viel Vergnügen beim individuellen Einbinden und Formatieren ihrer Felder!