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.

Unser erstes Plugin: SetzeCode 2, die Funktionalität

Was wollten wir also tun? Den Wert einer Option per Plugin setzen. Dafür brauchen wir zuerstmal:

Ein kleines Formular für die Eingabe

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

Keine Hexerei, nur ein ganz normales PHP-Formulärchen mit einem Texteingabefeld und einem submit-Button.

Was soll passieren, wenn auf „Abschicken“ gedrückt wurde?

Auch nicht weiter schwer, die Option soll mit dem Inhalt der Benutzereingabe gesetzt werden.

if (isset($_POST[’senden‘]))
{
$akt_code = $_POST[‚code‘];
update_option (‚mein_code‘, $akt_code);
}

Und schon landet der vom Benutzer eingegebene Code als Options-Wertepaar (Name und Wert) in der Tabelle wp_options!

Man kann noch eine kleine Debug-Ausgabe mit dranhängen, dann sieht man auch gleich mal wie das mit dem get_option() funktioniert:

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

Alles klar? Bitteschön, unser erstes Plugin kann marschieren! Nochmal zur Kontrolle die gesamte Funktion:

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

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

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

   $akt_code = $_POST[‚code‘];
   update_option (‚mein_code‘, $akt_code);

}
$akt_option = get_option (‚mein_code‘);
       echo „Wert aus der Datenbank &nbsp:“.$akt_option;
}

Hochladen und Aktivieren unseres Plugins

Man verschiebt jetzt die fertige setze_code.php in unser vorher angelegtes Plugin-Unterverzeichnis. Wenn alles geklappt hat, taucht unser neues Plugin jetzt im Plugins-Menü auf und kann dort aktiviert werden. Dann erscheint am Ende des Admin-Menüs der neue Eintrag „SetzeCode“, und den rufen wir jetzt auf und probierens mal aus. Aussehen sollte das Ganze etwa so:

screenshot_setze_code

Der Wert aus der Datenbank wird beim ersten Aufruf leer sein, weil die Option noch nicht gesetzt wurde, aber nach dem ersten Abschicken sollte er treu und brav den zuletzt eingegebenen Code wiedergeben. Das wars!

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.

Noch’n Nachschlag: Formular mit Gedächtnis (reines PHP)

Formular soll sich Eingaben merken

Kennen sie das auch: man hat ein Online-Formular ausgefüllt und auf den „Abschicken“-Button geklickt, und alle Benutzereingaben verschwinden, man hat wieder ein leeres Formular vor sich. Passiert heutzutage gottseidank nicht mehr so oft, aber wenn dann ist es oft verdammt ärgerlich, wenn man nicht das gewünschte Ergebnis erzielt hat und das Formular nochmal von vorn ausfüllen muß. Unser Freizeitsportpartner-Suchformular vom Turnverein Weiß-Blau leidet noch unter dieser Kinderkrankheit, und die wollen wir ihm abgewöhnen. Kurz zur Erinnerung, das Formular sieht so aus:

suchformular

Selektive Vorbelegung

Jetzt möchte ich gerne, daß nach dem Klick auf „Abschicken“ die vom Benutzer gesetzten Häkchen in den Checkboxen erhalten bleiben. Bislang sah der Code für eine Checkbox so aus:

echo „<input type=’checkbox‘ name=’turnen‘ value=’ja‘>Turnen<br>“;

Den brechen wir jetzt ein bißchen auf, und wir fragen ab ob denn der Wert für die Checkbox nicht schon mal gesetzt wurde, das sieht dann so aus:

echo „<input type=’checkbox‘ name=’turnen‘ value=’ja'“;
           if ($_POST[‚turnen‘] == ‚ja‘){
           echo „checked=’checked'“;
           }
       echo „>Turnen<br>“;

Das $_POST[‚turnen‘] enthält den aktuellen Wert des Feldes, der ist leer, wenn die Checkbox vor dem Drücken des Abschicken-Buttons leer war, und er enthält ein „ja“, wenn die Checkbox angekreuzt war. Das checken wir mit dem IF ab, und mit dem „checked=’checked'“ setzen wir im ja-Fall das Häckchen.

That’s it! Das machen wir für alle anderen Checkboxen analog, und schon haben wir ein Formular mit Gedächtnis.

Dropdownfeld mit Gedächtnis

Für die, die’s ganz perfekt haben wollen, hier noch die Vorbelegung für das Dropdown-Feld:

/*Begin select*/
echo „Auswahl Fitneß: &nbsp“;
echo „<select name=’meine_auswahl‘>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚egal‘){
echo “ selected“;
}
echo „>egal</option>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚Anfänger‘){
echo “ selected“;
}
echo „>Anfänger</option>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚Freizeitsportler‘){
echo “ selected“;
}
echo „>Freizeitsportler</option>“;

echo „<option“;
if ($_POST[‚meine_auswahl‘] == ‚Profi‘){
echo “ selected“;
}
echo „>Profi</option></select><br>“;
/*End Select*/

Das können sie sich jetzt aber selber zusammenreimen, der Mechanismus ist genau so wie bei der Checkbox, nur halt für jede Option extra. Zugegeben, es ist ein bißchen Aufwand, aber in Sachen Benutzerfreundlichkeit der Mühe wert.

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!