Archiv der Kategorie: WordPress

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

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

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

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:

  1. 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.
  2. 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))
  3. Wir legen 1 benutzerdefiniertes Feld an, das heißt „mitglied_id“ und erhält als Inhalt (na was wohl?) unsere eindeutige id.
mitglied_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

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

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!

Turnverein die erste Liste: Mitglieder-Adressen

Ausgabe Adressenliste

Alle alten Programmierer lieben Listen, und wir können uns aus unseren schönen Stammdaten schon eine erste Ausgabe bauen: Namen, Adressen und Telefonnummern nämlich, da brauchen wir gar nichts weiter dazu als unser gutes altes Arbeitspferd PHP Code for Posts. Unsere eigene Tabelle mitglieder_stamm kann nämlich vom $wpdb-Objekt genau so angesprochen werden wie die WordPress-eigenen Tabellen, liegt ja in der selben Datenbank.

Tabelle als Konstante definieren

Da wir ja ganz am Ende wieder auf unsere Originaltabelle savecontactform7_1 switchen wollen, lege ich den Namen der aktuellen Tabelle auf eine Konstante und gebe den Tabellennamen im Kopf mit aus, damit wir wissen wo wir arbeiten.

/*****Haupttabelle Name als Konstante definieren*******/
 define("MAINTABLE","mitglieder_stamm");

echo "<h2>Mitglieder Adressenliste</h2>";

echo "Aktuelle Tabelle =&nbsp".MAINTABLE."<br>";

Der Select ist dann ganz simpel:

global $wpdb;
        $alleposts = $wpdb->get_results( "SELECT * from ".MAINTABLE."");

Ausgabe als Tabelle

Wie gewohnt mit einer Foreach-Schleife, das haben wir schon oft genug gemacht, da spare ich mir jetzt nähere Kommentare:

foreach_adressen

foreach_adressen

Das reicht schon, wir bekommen jetzt alle eingegebenen Testdaten tabellarisch angezeigt.

adressenliste

adressenliste

Das war jetzt zu einfach, nicht wahr? Bitte sehr, wir erweitern unsere Möglichkeiten jetzt gleich kräftig, aber dazu gibts einen neuen Beitrag.

Turnverein: die Mitglieder-Stammdaten

Woher kommen die Daten?

Wie im vorigen Artikel bereits angesprochen, gibt es ein in Contact Form 7 erstelltes Anmeldeformular, das wird für die Erfassung aller Mitgliederdaten genutzt. Hacken sie einfach ein paar Testmitglieder mit unterschiedlichen Sportarten und Freizeitoptionen ein, so fünf bis zehn Stück reichen für den Anfang. Contact Form 7 schickt ihnen zu jedem erfaßten Formular ein E-Mail mit den zugehörigen Daten. Wir brauchen hier aber nur das Paßfoto, das als Attachment mitgeschickt wird, die anderen Daten werden in einer MySQL-Tabelle automatisch gespeichert.

Speichern der Formulardaten in einer Tabelle

Das zusätzliche Plugin Save Contact Form 7 sorgt dafür, daß die Formulardaten in einer Tabelle landen, mit der wir später weiterarbeiten können. Diese Tabelle heißt default-mässig savecontactform7_X, wobei X eine laufende Nummer ist. Da wir nur ein Kontaktformular haben, ist das die Nummer 1, folglich heißt unsere Tabelle savecontactform7_1. Von der machen wir uns zunächst einmal eine Kopie: das geht im phpmyadmin unter „Operationen“, wir kopieren Struktur und Daten und geben der Tabelle einen aussagekräftigen Namen, die heißt jetzt mitglieder_stamm. Das wird unsere Arbeitstabelle. Warum eine Kopie? Weil wir noch am Testen sind. Im Real-Betrieb arbeitet man mit der „echten“ Tabelle, damit man neu angemeldete Mitglieder auch in Echtzeit mitkriegt. Wir nutzen jetzt erstmal die Kopie unserer Mitglieder-Stammdaten und haben ein bißchen Spaß auf der Datenbank!

Struktur der Tabelle mitglieder_stamm

In der Tabellenstruktur spiegelt sich 1:1 unser Formular wieder:

mitglieder_stamm_struktur

mitglieder_stamm_struktur

Ich geh mal von oben nach unten:

  1. id wird von contact form 7 automatisch fortlaufend vergeben, das wird unser Schlüssel, die Mitglieds-Nummer
  2. created_on Timestamp, wird von CF7 automatisch vergeben, brauchen wir eigentlich nicht
  3. status das hab ich glatt unterschlagen: ich nutze das Plugin CF7 Dynamic Text Extension um ein „hidden“-Feld mitzugeben, das erhält defaultmäßig den Wert „neuzugang“. Wir werden später noch sehen, wozu wir das brauchen.
  4. die restlichen Felder: sind 1:1 die selben wie in unserem Formular, das ist keine Hexerei.
  5. Das Feld zustimmung brauchen wir nur für die Datenschutzerklärung, das sieht in CF7 so aus:
datenschutzerklaerung

datenschutzerklaerung

Die muß mit rein, schließlich erheben wir personenbezogene Daten!

So, das wars schon. Ready to go, Testdaten drin? Dann gehts zur ersten Ausgabe im nächsten Beitrag.

Der Turnverein Weiß-Blau: jede Menge Spaß mit eigenen Tabellen

Über den TV Weiß-Blau

Der kleine fiktive  Vorort-Turnverein im Münchner Norden möchte WordPress für seinen Webauftritt verwenden. Die informativen Seiten (Über den TV-Weiß-Blau, Vereinsangebot) sind schnell angelegt. Dann kommt noch ein Registrierungsformular für neue Mitglieder dazu, das machen wir mit Contact Form 7 und nutzen gleich noch Save Contact Form 7 um die Daten den prospektiven Mitglieder direkt in der MySQL-Datenbank zu speichern. Save Contact Form 7 erzeugt zu jedem neuen abgeschickten Formular eine fortlaufende ID, die wird unsere Mitgliedsnummer.

Unser besonderer Service: finden sie ihren individuellen Freizeitsport-Partner!

Und weil wir mit dem Registrierungsformular so schöne Daten abfragen (Beispiel kommt noch) möchten wir als besonders „Zuckerl“ für unsere Mitglieder einen super Service anbieten: man kann nach geeigneten Sportpartnern suchen! Wer hat am Abend oder am Wochenende Zeit, wer ist in meiner Leistungsgruppe oder Größenklasse, wer hat Interesse an Basketball oder Tennis – das wird der ganz besondere Service für den Verein und hebt unser Angebot von der Konkurrenz ab.

Das Datenmodell in WordPress und Contact Form 7

… ist denkbar einfach. Wir legen für jedes Vereinsmitglied einen Beitrag an, da kommt noch ein Paßfoto mit dazu, und das wars auch schon. Alle anderen relevanten Daten bekommen wir aus unserem Registrierungsformular. Das haben wir mit Contact Form 7 schnell erstellt. Im ersten Teil werden die persönlichen Daten und die Adresse abgefragt:

anmeldeformular_adressdaten

Nichts weiter ungewöhnliches, interessanter wirds da schon im zweiten Teil, da werden Infos zu den sportlichen Aktivitäten abgefragt:

fitness_sportarten

fitness_sportarten

Der Größenbereich erlaubt die Auswahl „unter 170“, „170-180“ und „über 180“. Bei „Fitneß“ kann man Anfänger, Freizeitsportler oder Profi auswählen, die anderen Formularfelder sind eigentlich selbsterklärend. Warum habe ich bei „Verfügbarkeit“ und „Sportarten“ Radiobuttons mit ja/nein gewählt, und keine Optionsgruppen? Weil die Daten so schöner auszuwerten sind, das wird man später noch sehen.

Woher kommen nun die Daten?

Alle diese wertvollen Daten erhalten wir einfach dadurch, daß Anmeldeformulare ausgefüllt und abgeschickt werden. Wenn sich jemand persönlich vor Ort oder auf traditionell schriftlichem Weg im Verein anmeldet, werden die persönlichen Daten halt auch einfach über das Kontaktformular erfaßt, ist ja egal wer die eingibt. Jedenfalls haben wir so schnell einen kleinen Stammdaten-Pool beieinander, mit dem wir arbeiten können.

Kleine Anmerkung zur tabellarischen Darstellung in CF7

Wie bringt man CF7 dazu, eine Gruppe mit Radiobuttons vernünftig formatiert darzustellen? Bin ich gefragt worden, gebe ich gern Auskunft. Man packt sie in eine Tabelle, das sieht dann im Entwurf so aus:

cf7_tabellen

cf7_tabellen

Das aber nur als kleiner Layout-Tipp am Rande. Im nächsten Artikel geht es weiter mit unseren Mitgliederdaten.

 

Eigene Tabellen – schließlich heißt es „MeinSQL“

MySQL läßt sich so schön übersetzen

Mir gefällt auch die Semantik: das ist „Mein SQL“, hier kann ich schalten und walten wie ich will, kann Tabellen und Abfragen anlegen und verknüpfen, kann sortieren und inserten und updaten nach Lust und Laune, und Open Source und kostenlos ist es obendrein. MySQL bietet wirklich unbegrenzte Möglichkeiten und ist flexibel ohne Ende. Über den genialen phpMyAdmin steht auch eine professionelle Verwaltungsoberfläche zur Verfügung, die keine Wünsche offenläßt. Also, warum nutzen wir dann dieses Potential nicht zur Erweiterung von WordPress?