Archiv der Kategorie: Plugins

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 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>“;
}
?>

Privatsphäre für personenbezogene Daten: das Plugin Secret Content

Adressdaten und Datenschutz

Jetzt haben wir also unser schönes Mitgliederverzeichnis mit allen Adressdaten und freuen uns darüber – aber mal langsam, so geht das „in echt“ natürlich nicht. Man kann nicht einfach Fotos und persönliche Daten von echten Personen ins Internet stellen und blind darauf vertrauen, daß schon nieman Schindluder damit treiben wird. Also muß ein Schutzmechanismus her, und genaugenommen müssen wir auch die Datenschutzerklärung (die auf dem Anmeldeformular) erweitern. Wie gehen wir das an?

Wir nutzen das WordPress-Login

Eine einfache Lösung ist es, unser Mitgliederverzeichnis nur für eingeloggte WordPress-Benutzer sichtbar zu machen. In unserem Fall ist das erstmal nur ich, der Admin, weitere Benutzer gibt es noch nicht (Werden wir aber noch brauchen, später, für die versprochene Suche nach Sportpartnern). Wie stellen wir es also an, daß unser Mitgliederverzeichnis nur für eingeloggte User sichtbar ist?

Das PluginSecret Content

Plugin-Seite: https://de.wordpress.org/plugins/secret-content/

Ich liebe Werkzeuge, die genau einen speziellen Zweck erfüllen und keinen Schnickschnack mitschleppen. Das Plugin Secret Content macht genau ein Ding: es ermöglicht einem, auf jeder Seite und auf jedem Beitrag anzugeben, daß sie nur für eingeloggte Benutzer sichtbar sein sollen. Nach Installation und Aktivierung des Plugins gibt es ein zusätzliches Fensterchen rechts oben im Editor, wo man anwählen kann, ob die Seite oder der Beitrag nur für eingeloggte Benutzer sichtbar sein soll.

secretcontent

Häkchen reinsetzen, speichern, fertig. Seite ist unsichtbar, wenn man nicht eingeloggt ist. Das wars! Das Plugin ist zwar seit über zwei Jahren nicht aktualisiert worden, aber es funktioniert einwandfrei, wieso sollte man daran was verbessern wollen?

Datenschutzerklärung anpassen nicht vergessen

Man muß das schon genau nehmen mit dem Schutz der personenbezogenen Daten, und deshalb müßten wir auch unsere Datenschutzerklärung auf dem Anmeldeformular anpassen, sobald wir echte Personendaten verwalten. Da gehört noch ein Passus hinein, daß Fotos und Adressdaten für andere Vereinsmitglieder sichtbar sind, wenn sie auf der Vereinsseite eingeloggt sind. Wie man das am Besten formuliert – ich würde im Echtfall einen Anwalt fragen, ganz ehrlich.

So, aber jetzt gehts weiter mit ein bißchen Spiel und Spaß mit PHP, wir machen uns an das Sportpartner-Suchformular, und dafür gibt es einen neuen Beitrag.

Warum einfach, wenn’s auch umständlich geht? Zwei DB-Plugins für Contact Form 7

Über Contact Form 7 und die Limits

Contact Form 7 ist mit Recht eines der beliebtesten Formular-Plugins fürWordpress. Es ist einfach zu konfigurieren, in der Funktionalität für den Anwender leicht verständlich, und macht genau das was es soll, nämlich abgeschickte Kontaktformulare als E-Mails versenden und, wenn man es möchte, auch eine automatisierte Antwort hinausschicken.

Wenn man jetzt aber feststellt, daß einem die E-Mail-Flut zuviel wird und man mit dem Verwalten der vielen Kontaktanfragen gar nicht mehr nachkommt, muß eine geschicktere Lösung her. Für viele Anwender ist es auch ein Thema, daß E-Mail-Kontaktanfragen im Spam-Ordner landen oder sonstwie verlorengehen. Abhilfe schaffen da Plugins, die die eingehenden Kontaktformulare in Datenbanktabellen speichern. Da geht nix verloren, da hat man gleich einen schönen Überblick, das läßt sich auch automatisiert weiterverarbeiten. Feine Sache, und auch aus DV-technischer Sicht eine saubere Lösung. Ich habe mal zwei Plugins unter die Lupe genommen, die diesen Job auf höchst unterschiedliche Art und Weise erledigen.

Contact Form to DB von BestWebSoft

Mit 3000+ Installationen das etwas verbreitetere Plugin, deswegen schauen wir es uns zuerst an. Es kommt mit einem recht übersichtlichen Admin Panel daher, in dem man anwählt, welches Formular man anschauen möchte, das wird dann tabellarisch dargestellt, ist nach allen Feldern sortierbar, und man kann verschiedenste Export-Optionen wählen:

cf7db_exportformate

Soweit, so gut, aber was passiert darunter in der Datenbank?

Man findet die Daten der abgeschickten Formulare alle in einer Tabelle wieder – ja, alle in eine einzige Tabelle gepfercht, und zwar nach dieser interessanten Logik:

cf7db_submits_tabelle

Für jedes Feld aus einem abgeschickten Formular wird augenscheinlich ein eigener Datensatz angelegt. Die haben logo alle die selbe submit_time, daran erkennt das Plugin anscheinend, welche Daten zu einem einzelnen abgeschickten Formular zusammengehören. Dann wird in jedem Datensatz festgehalten, zu welchem Formular er gehört, hier ist es mein „Modelformular“. Die Felder field_name und field_value sind eigentlich selbsterklärend, Feldname und Wert eben. Die field_order scheint einfach die Reihenfolge der Felder im Formular zu sein. Interessant ist dann noch das Feld file, das ist ein Longblob und kann Attachments speichern.

Das ist keine relationale Logik

Also, mit relationaler Datenbanklogik hat das aber schon rein gar nichts mehr zu tun! Wie soll man denn bitte so eine Tabelle in MySQL weiterverarbeiten? Der ganze Rattenschwanz steht ja zu jedem abgeschickten Formular wieder in ganzer Pracht in der Tabelle, für jedes Formularfeld ein eigener Datensatz – wie, bittesehr, soll man da zum Beispiel einen Select drauf absetzen? Erstmal nach form_name selektieren, dann nach dem Timestamp gruppieren, dann noch die Feldreihenfolge (field_order) berücksichtigen, und dann.. ja was denn nicht noch alles? Mal ganz davom abgesehen, daß die Tabelle vor Redundanzen geradezu trieft, der Formularname und die Feldnamen werden x-mal gespeichert.

Daumen nach unten

Wenn Contact Form to DB wenigstens einen Export nach MySQL anbieten würde, wäre das deutlich einfacher, aber der fehlt kurioserweise. Also erstmal nach Excel exportieren, dann mit dem phpmyadmin wieder in MySQL reinimportieren, und dann erst weiterverarbeiten, oder wie? Das finde ich doch schwer umständlich, deswegen: Daumen nach unten für dieses Plugin, weil es völlig ignoriert, daß man die Formulardaten bitteschön gern mal in MySQL weiterverarbeiten möchte.

Save Contact Form 7 von Nimblechapps Ltd.

Auch dieses Plugin kommt mit einem recht aufgeräumten Admin-Panel. Die Export-Optionen beschränken sich zwar auf CSV, PDF und Print, aber das macht nichts, denn drunter auf der Datenbank sieht es hübsch übersichtlich aus. Für jedes Formular wird eine eigene Tabelle angelegt, diese werden durchnummeriert (z. B. Savecontactform7_1). Man erkennt aber sofort die Feldnamen aus den Formularen in den Datenbanktabellen wieder, die werden nämlich 1:1 übernommen

Tabellenstruktur Beispiel

savecf7_tabelle

Vorne kommt zuerst eine AutoIncrement-ID, das ist schon mal sehr praktisch. Es folgt der Timestamp, dann die Formularfelder mit den entsprechenden Inhalten. Jedes abgeschickte Formular ein Datensatz, Jedes Kontaktformular eine eigene Tabelle und basta.. Na, da kann man doch sauber damit arbeiten!

Einziger Wermutstropfen: es können keine Attachments gespeichert werden. Aber mal ehrlich, wie oft brauchen sie Dateianhänge in Kontaktformularen? (In der von Contact Form 7 generierten E-Mail sind die Attachments natürlich drin)

Daumen hoch

… für dieses blitzsauber arbeitende Plugin. Ich würde mir höchstens noch wünschen, daß aus dem Tabellennamen der Formularname ersichtlich ist, also die Tabelle statt savecontactform7_xy vielleicht scf7_bestellformular heißen würde, aber das ist Kleinkram. Ich verwende das Plugin gerne, und empfehle es auch meinen Kunden als schön saubere Lösung.

Volkskrankheit Medienbruch: Daten in der Sackgasse

Was haben ein PDF, eine E-Mail und eine SMS oder What’s App gemeinsam?

Nun, sie transportieren Daten zum Empfänger. Das PDF-Kochrezept wird im Ordner „Rezepte“ bei den eigenen Dokumenten abgelegt. Bei den E-Mails und Nachrichten auf’s Handy kommts ein bißchen drauf an. Da gibts welche, die kann man lesen und gleich wieder löschen, weil man die enthaltene Info gelesen hat und keine weitere Aktion nötig ist. Das ist zum Beispiel der Fall bei einer SMS, die sie sich für die mobile TAN fürs Online-Banking schicken lassen können. Wenn die aktuelle Transaktion, z.B. eine Überweisung, abgeschlossen ist, hat die mobile TAN ihren Zweck erfüllt und kann getrost gelöscht werden.

Es ist heute sehr modern, sich wegen jedem Pfiffkaas eine elektronische Nachricht schicken zu lassen, weil man ja „Immediate Information“ haben will und immer am Ball bleiben will bzw. muß. Aber aus datenverarbeitungstechnischer Sicht ist das nicht so dolle.

Was ist ein Medienbruch?

Es gibt eben auch Nachrichten, die muß man aufheben, weil man die darin enthaltenen Informationen irgendwie verarbeiten und darauf reagieren muß. Das ist sehr typisch für Nachrichten, die sie per Kontaktformular von ihrer WordPress-Seite bekommen. Sie erhalten hier pro abgeschicktem Formular eine E-Mail mit den relevanten Daten.

Ob es sich nun um eine allgemeine Anfrage, eine Bestellung oder Buchung oder so etwas handelt, sie müssen auf diese Information hin etwas unternehmen. Sich eine Erinnerung schreiben, wenn sie sie nicht sofort erledigen können, oder handschriftliche Notizen in ihrem Organizer machen, oder die Bestellung mit Copy&Paste in ihre Buchhaltungssoftware übertragen.

Das nennt man einen Medienbruch, und es bezeichnet die Stelle im Datenfluß, an der ohne menschliches Eingreifen keine elektronische Weiterverarbeitung mehr möglich ist. Copy&Paste gilt übrigens deswegen nicht, weil es manuell gemacht werden muß und hier sehr leicht Fehler bei der Übertragung ins nächste Medium passieren können.

Der Medienbruch tritt natürlich genauso bei SMS oder What’s App-Nachrichten auf, und auch ein zugesandtes PDF ist nicht ohne Bauchaufzüge elektronisch weiterverarbeitbar.

Was ist so schlimm an einem Medienbruch?

Zuerst einmal die Fehleranfälligkeit bei der Weiterverarbeitung. Und wenn größere Datenmengen auftreten, auch die Machbarkeit: in einem Online-Shop mit mehreren Dutzend oder Hundert Bestellungen pro Tag wollen sie die nicht mehr per E-Mail und per Copy&Paste abwickeln, no Sir, nein Danke. Hier ist eine elektronische Schnittstelle vonnöten. Professionelle Shopsystem bieten so etwas natürlich, aber unser kleines WordPress kann das nicht von alleine, es gibt nämlich keine definierten Schnittstellen für die Weiterverarbeitung in externen elektronischen Systemen. Da muß man auf mehr oder weniger ausgeklügelte Plugins zurückgreifen und bei der Konfiguration ein bißchen Grips einsetzen, damit das auch klappt.

Es ist Linderung in Sicht: Plugins zum Speichern von Kontaktdaten

Das wohl bekannteste Plugin zum Erstellen von Kontaktformularen für WordPress dürfte Contact Form 7 mit über 1 Million Installationen sein. Dagegen sind die besten und bekanntesten Plugins zum Speichern von Kontaktformular-Informationen, Contact Form to DB und Save Contact Form 7, mit jeweils nur wenigen Tausend Installationen noch richtig unterrepräsentiert. Das wundert mich sehr. Wickeln wirklich all diese Contact-Form-7 User ihre Kontakt-E-Mails händisch ab? Kann eigentlich auch nicht sein, da muß ich was übersehen haben…

Soll mich aber nicht daran hindern, in einem der nächsten Artikel die beiden Plugins zum Speichern von Kontaktdaten näher vorzustellen, da geht nämlich der Weg in Richtung professionelle Business-Software, und da will die internationale WordPress-Gemeinde ja schließlich mit aller Macht hin 😉

Plugins – auf Teufel komm raus?

Das Open Source Prinzip

Also, normal bin ich ja schon eine grosse Freundin von Open-Source-Software. Die Idee, Programmcode offenzulegen und für jeden Interessenten zugänglich zu machen, hat unbestreitbar viele Vorteile für den Otto-Normalanwender. Auf diesem Weg kommt man kostenlos an echt professionelle Software für fast alle Zwecke, vom alternativen Betriebssystem Linux über Open Office als echte Konkurrenz für Microsoft Office und noch vieles mehr bis eben hin zu unserem WordPress, dem Fex unter den Webdesignern für das kleine Budget. Durch die Offenlegung der Sourcen kann auch jeder Programmierer, der sich dazu berufen fühlt, eigene Erweiterungen schreiben und ebenfalls als Open Source zur Verfügung stellen. Es gibt heute 48,995 Plugins im wordpress.org Plugin Directory, und das sind nur die kostenlos erhältlichen. Von den gegen Honorar programmierten oder fertig käuflichen muß es noch viel mehr geben, jede kleine Softwareschmiede programmiert heutzutage Plugins für alle Zwecke für ihre Kunden.

Für jeden Zweck ein Helferlein

Ob sie jetzt einen Onlineshop oder ein Hobbyforum betreiben wollen oder nur ein paar Kontaktformulare erstellen, ob sie einen Spamschutz brauchen oder ein komplettes SEO-Paket, ob es um Designanpassungen geht oder um Multimediaspielereien, es gibt für Tausend unterschiedliche Zwecke Plugins. Die Installation ist einfach, jeder Hobby-Wordpress-Admin hat schon -zig Plugins installiert, da sind ganz schnell mal so zwanzig, dreißig Installationen zusammen, und man hat eigentlich noch gar nicht viel gemacht.

Ein schwarzes Schaf dabei?

Ja, bis es dann passiert: ein Plugin zuviel installiert, und WordPress ist plötzlich beleidigt. Das muß nicht gleich der berüchtigte White Screen of Death sein, da können auch ganz andere Fehlfunktionen auftreten, die man vielleicht nicht gleich bemerkt. Da funktioniert plötzlich der Customizer nicht mehr, oder es verhaut das Seitenlayout, oder was auch immer da alles schiefgehen kann. Da wird dann immer wohlmeinend geraten, erst einmal alle Plugins zu deaktivieren und dann eins nach dem anderen wieder zu aktivieren, damit man herausfindet welches Helferlein denn nun den Ärger verursacht hat. Na prima. Und wenn man an sein WordPress gar nicht mehr rankommt? Kann man ihm immer noch das ganze Plugin-Verzeichnis unter dem Hintern wegziehen und schauen obs dann wieder normal läuft. Auch ’ne Lösung.

Denn sie wissen nicht, wer was tut

Jedem altgedienten Softwareentwickler da draussen sträuben sich hier natürlich alle Haare, das hat ja mit Datensicherheit überhaupt nichts mehr zu tun, aber bitte bürsten sie sich wieder flach, meine lieben Anwendungsprogrammierer und gelernten Informatiker, es kommt noch besser. WordPress lädt den Endanwender ja auch noch ein, den Plugin-Code zu verändern, man muß nur Im Plugin-Verzeichnis auf das Knöpferl „Bearbeiten“ klicken und landet mittenmang im Source-Editor und kann hier nach belieben Code verändern, löschen, herumkopieren und was weiß ich noch. Da muß noch nicht mal Absicht dahinterstecken, wie schnell hat man sich mal mit der Maus verklickt – und wenn man dann (vielleicht sogar nur aus Unwissenheit) die Änderungen speichert, ist das Malheur passiert.

Der Pferdefuß bei Open Source

Ja, echt wahr, sie können jetzt lang den Kopf schütteln, meine Damen und Herren gelernten ITler, aber so ist es nunmal. Jeder Endanwender kann nach Belieben den Sourcecode von Plugins bearbeiten, nix mit kompiliert, nix mit Kapselung, und schon gar nix mit Schutz von Gewährleistungsvoraussetzungen. Gewährleistung gibts nämlich bei Open Source nicht, weil die Grundlage dafür fehlt, nämlich der Schutz des Programmcodes vor unbefugten Änderungen. Das haben sie und ich noch als strengste Auflage bei allen ernsthaften Programmierprojekten gelernt, aber vor lauter Open Source-Begeisterung ist dieser so wichtige Aspekt der Datensicherheit komplett ins Hintertreffen geraten. Da kann jetzt jeder selber seine Schlüsse ziehen, ob eine derart leicht zerhackbare Software für den professionellen Einsatz wirklich geeignet ist, oder nicht. Das mal so als Gedanke zum Feierabend.

HTML Tabelle mit Tablesorter reloaded

Ich gelobte Besserung. Ich schieb hier nochmal nach, wie unsere HTML-Tabelle aussehen muß, nämlich mit thead und tbody Tags, damit sie vom Table Sorter Plugin auch sortiert wird.

alle_posts_mit_perm_und_tablesorter

Das ist jetzt mal ein Screenshot aus dem Notepad++, meinem Lieblings-Editor für alle Zwecke. Ich denke, man kanns lesen… und da seh ich prompt schon einen Fehler, bei dem schließenden thead Tag fehlt der / (Schrägstrich). Tablesorter hats trotzdem gesorted, ich lass das jetzt mal so stehen.

Der Knackpunkt ist hier wie gesagt die Zuweisung:

echo „<table id=’meineTabelle‘ class=’tablesorter‘>“;

Damit weiß der Tablesorter, daß jetzt Action angesagt ist, und er auf diese Tabelle losgehen soll. Mehr ist nicht dabei. Wie schon gesagt, der Tablesorter bietet noch wesentlich mehr Möglichkeiten, aber da darf sich jeder selber einlesen, Doku gibts bei Tante Google.