Archiv der Kategorie: WordPress

Gut gemeint, bedingt brauchbar: Benutzerdefinierte Felder

Einleitung

Als vor ein paar Jahren die benutzerdefinierten Felder (Custom Fields) in WordPress eingeführt wurden, wurde das als großer Schritt in Richtung CMS hochgelobt und gleich mit -zig Anwendungsbeispielen unterfüttert. Benutzerdefinierte Felder sind dafür gedacht, die Beiträge mit weiteren Daten anzureichern, das kann ganz unterschiedliche Anwendungen haben. Man könnte z.B. in einem Bücherblog die ISBN-Nummer des jeweils besprochenen Buches in ein benutzerdefiniertes Feld eintragen, man könnte in einem kleinen Online-Shop zu einzelnen Artikeln die Preise hinterlegen, man könnte in einem Mitgliederverzeichnis für einen Verein verschiedene Daten zu den einzelnen Mitgliedern abspeichern (Geburtsdatum, Telefonnummer, Adresse).

OK, Feld ist gespeichert. Und jetzt?

Wenn man seine benutzerdefinierten Felder in den Beiträgen auch sehen möchte, muß man sie in den Code der entsprechenden PHP-Datei (z.B. single.php) eintragen, das sieht dann etwa so aus:

<?php get_post_meta($post_id, '$key', $single); ?>

Dabei ist die $post_id natürlich die ID des aktuellen Beitrags, das $key ist der Platzhalter für den Namen des benutzerdefinierten Feldes, und $single weist WordPress an, einen einzelnen String auszugeben (alternativ ginge auch ein Array, wenn ein Custom Field mehrere Werte enthält, aber das lassen wir jetzt mal weg).

Ein Beispiel wäre jetzt hier mal der Preis zu einem Beitrag, der $key wäre hier schlicht „Preis“:

benutzerdefiniert_preis

Was passiert hinter den Kulissen auf der Datenbank?

In der Tabelle wp_postmeta landet ein neuer Eintrag mit einer laufenden meta_id:

post_meta_custom_field

Hier wird über die post_id der Name und der Wert des benutzerdefinierten Feldes festgehalten. Der meta_value ist übrigens ein Longtext, also hier können sie jede Menge Text (max. 4.294.967.295 Byte) eingeben!

Sie können allerdings auch jede Menge Unsinn eingeben, statt dem Preis in € das Tagesdatum zum Beispiel, oder auch unsinnige Werte wie „Zwofuffzig“, WordPress ist das egal. Die Nachteile hiervon liegen auf der Hand, und deswegen gibt es auch Plugins, die die Verwaltung von Custom Fields erheblich verbessen.

Das Plugin Custom Field Template

Diese Plugin ermöglicht es, die Eingabebereiche von benutzerdefinierten Feldern einzugrenzen. Mit Hilfe von definierbaren Eingabefeldern, Radio-Buttons, Checkboxes usw. wird es dem Benutzer sehr vereinfacht, sinnvolle Eingaben zu machen. Das ist alles gut und schön und auch sehr professionell gemacht, aber mir gefällt das alles nicht so recht, und ich sage auch gleich, warum.

Wer tippt den ganzen Datenhaufen ein?

Um mal bei dem Anwendungsbeispiel mit dem kleinen Onlineshop zu bleiben: angenommen, man legt für jeden Artikel einen Beitrag an, hübsch mit Bild und kleinem Text. Dann könnte man ein benutzerdefiniertes Feld für den Preis anlegen, vielleicht noch eins für die Artikelnummer, und interessant wäre vielleicht auch der noch Lagerbestand, wieviele Stück noch verfügbar sind. In einem normalen kleinen Laden hat man hierfür zumindest eine Excel-Liste, in der man die ganzen Artikel verwaltet. So, und jetzt kommen die Custom Fields: das soll man alles per Hand einhacken? Nicht in echt, oder?

Oder sehen wir uns mal das Mitgliederverzeichnis eines Vereins an: Miitgliedsnummer, Name, vollständige Adresse, Geburtsdatum, Funktion… da gibt es jede Menge Daten, die hineingehören. Und die soll man alle per Hand erfassen? Ja mir wannsd net gangst, wie man auf bairisch sagt, zu Hochdeutsch: „Das geht ja wohl gar nicht!“

Letztes Beispiel: Bei meiner Modeldatenbank hätte ich zu jedem Model (1 Model=1 Beitrag) sage und schreibe 34 benutzerdefinierte Felder auszufüllen: Körpergröße, Kleidergröße, Schuhgröße, Haarfarbe, Augenfarbe, Oberweite… usw. usf, was halt so alles zu einer Modelsedcard gehört, und das ist eine Menge Holz! Also nee echt nicht, das hacke ich da nicht per Hand rein. Schon gar nicht, weil ich die ganzen Modeldaten eh über ein Contact Form 7-Formular erfasse und sowieso in der Datenbank gespeichert habe.

Und bevor wir jetzt darüber nachdenken, wie man die passenden Einträge zu den benutzerdefinierten Feldern in der wp_postmeta aus unseren Excel-Listen oder MySQL-Tabellen automatisiert erzeiugen könnten – nicht wahr, liebe alte Programmierer, daran habt ihr sofort gedacht! Also, das machen wir NICHT. Wir machen uns das Leben deutlich einfacher.

Wir verwenden eigene Tabellen

Aber dazu gibt es definitiv einen neuen Beitrag, dieser hier ist lang genug geworden.

WordPress und die Kategorien: kleine Gruseltour auf der Datenbank

Die Kategorien von WordPress sind ein sehr praktisches und flexibles Werkzeug. Im Prinzip handelt es sich hier um eine 1:n-Beziehung (ein Beitrag kann zu mehreren Kategorien gehören), dazu kommt allerdings noch eine nahezu unbegrenzte Schachtelungstiefe in Unterkategorien, Unter-Unterkategorien und so weiter. Das ist wie gesagt sehr flexibel gelöst, auch wenn ich bezweifle, daß im Normalfall eine Schachtelungstiefe von mehr als drei Kategorie-Ebenen notwendig ist. Die Möglichkeit ist jedenfalls da.

Und wie sieht das auf der Datenbank aus?

WordPress gönnt sich für die Verwaltung der Kategorien drei Tabellen, die alle an einem „term“ im Namen erkennbar sind (warum terms und nicht categories?). Es gibt die wp_terms, in der findet sich recht übersichtlich eine Auslistung aller Kategorien mit term_id und name.

wp_terms

Dann gibt es noch die wp_term_taxonomy, die ist schon weniger durchsichtig. Hier werden über das Feld „parent“ die Zuordnungen zu Unterkategorien verwaltet, und ein Zähler(count) mitgeführt.

wp_term_taxonomy

Und schließlich ist da noch die wp_term_relationships, in der erfolgt letztendlich die Zuordnung der Kategorien (anhand der term_taxonomy_id) zu den Beiträgen (object_id). Um also herauszufinden, welche Kategorien zu einem Beitrag gehören, müßte man einen Join über alle drei Tabellen machen, aber das ersparen wir uns.

wp_term_relationships

Warum so kompliziert? Wegen der unbegrenzten (ich habs nicht ausprobiert) Schachtelungstiefe, und weil WordPress hier noch die Möglichkeit der sogenannten „Custom Taxonomies“ offenläßt. Das sind eigene Gruppierungen, die man erstellen und dann ganz genau so wie Kategorien zur Sortierung und Anzeige der Beiträge verwenden kann. Ich hab das mal für eine Taxonomie „Jahreszeiten“ gemacht, die bestand halt dann nur aus „Frühjahr, Sommer,Herbst,Winter“, war aber für ihren Zweck ganz praktisch.

Stattdessen: get_the_category()

Weil uns aber vor lauter unterschiedlichen ids und terms und taxonomies und was weiß ich noch alles schon der Kopf schwirrt, nehmen wir eine einfachere Lösung. Praktischerweise hat WordPress eine eingebaute Funktion, die uns ein Array aller zu einem Beitrag gehörenden Kategorien liefert. Man holt sich das Array über die ID des aktuellen Beitrags. In unserer foreach-Schleife sieht das dann so aus:

$category = get_the_category($einpost->ID);

Jetzt brauchen wir noch eine kleine foreach-Schleife für die Ausgabe des Ergebnis-Arrays, und wir nehmen mal als Trennzeichen noch ein Komma und ein Leerzeichen:

foreach ($category as $eincat){
                    echo $eincat->cat_name.", ";
                }

Damit können wir eine Ausflistung der Kategorien in unsere Beitragsausgabe mit einbauen, bei mir sieht das dann so aus:

alleposts_mit_kategorien

Kniefiesler werden bemerken, daß das letzte Komma in der Kategorienauflistung überflüssig ist, aber da seh ich mal großzügig darüber hinweg. Ich finde die Beitragsausgabe jetzt eine runde Sache und recht übersichtlich. So man hat, kann man natürlich auch noch das Beitragsbild mit ausgeben, die Anzahl der ausgegeben Beiträge beschränken, ein Order by rand() mit einbauen etc. pp, da kann sich jeder selber spielen wie er mag. Viel Spaß dabei!

Beitragsausgabe: Text vernünftig kürzen

Noch läuft uns ja der ganze Text der Beiträge in die Div, und der Überschuss wird einfach durch das overflow:hidden in der style.css versteckt. Schöner wärs natürlich, man würde den Text irgendwie vernünftig kürzen.

Erster Ansatz: nur die ersten X Zeichen ausgeben

Das ist natürlich am einfachsten und läßt sich mit einem substr() ganz einfach realisieren. Ich füge noch eine „weiterlesen“-Marke mit ein ([..]) und lege auch auf die nochmal den Link zum Beitrag. Unser post_content steckt nach wie vor in der Variable $akt_text, und ich kürze ab Position 0 (Null) auf 100 Zeichen, das schreibt sich dann so:

$rest_anfang = substr($akt_text, 0,100);
                echo $rest_anfang."<a href = '".$akt_link."'> [...]</a>";

Das kürzt dann natürlich den Text auch gnadenlos mitten im Wort, läßt sich leider nicht verhindern.

text_kuerzen_substr

Schöner wärs, wenn die Wörter nicht abgeschnitten werden. Dazu fallen mir zwei Ansätze ein.

Kürzen auf den ersten Satz

Es ist halbwegs realistisch anzunehmen daß in meinen Kochrezepten jeder erste Satz eines Rezeptes mit einem Punkt endet. Deswegen kann man hier z.B. mit explode() arbeiten (s. PHP-Manual) und nur den ersten Wert des Arrays ausgeben, dann hat man im Normalfall einen ganzen Satz.

$erster_satz = explode(".",$akt_text);
echo $erster_satz[0]."<a href = '".$akt_link."'> [...]</a>";

Ergebnis:

text_kuerzen_erster_satz

Das gefällt mir jetzt schon viel besser!

Auf die ersten X Wörter kürzen

Ginge auch, muß man dem explode() halt ein Leerzeichen mitgeben und das zurückgegebene Array mit dem Index von 0 bis X ausgeben. Mir gefällt aber die Lösung mit dem „Ausgeben bis zum ersten Punkt“ schon sehr gut, ich laß das jetzt mal so.

Was man jetzt noch machen könnte

Schick wäre es natürlich, wenn man jetzt noch sehen könnte unter welcher Kategorie die Beiträge abgelegt wurden. Dafür wirds wieder Zeit für ein bißchen Fun auf der Datenbank und einen neuen Beitrag.

Was wir mit Bildern können, können wir mit Posts schon lange!

Alle veröffentlichten Beiträge

Es wird wieder Zeit für ein bißchen Spaß auf der Datenbank! Wir gehen wieder zurück zu unserer zentralen Tabelle wp_posts und picken uns diesmal alle veröffentlichten Beiträge heraus. Das haben wir schonmal gemacht, bei der Ausgabe der Beitragsbilder ganz am Anfang, wissen sie noch? Der Select ist supersimpel:

SELECT * from wp_posts where post_status = ‚publish‘ and post_type = ‚post‘

Die könnten wir jetzt einfach mal alle ausgeben so wie sie daherkommen, nämlich einfach nacheinander aufsteigend Datum. Das sähe dann aber der Beitragsseite (nur mit umgekehrter Sortierung) verdammt ähnlich und hätte weiter keinen Närwert, deshalb geben wir die Beiträge jetzt erst mal gekürzt und in Divs gepackt als Übersicht aus. Unser foreach für diesen Zweck ist auch denkbar einfach, ich gebe fürs erste nur den Titel und den Inhalt aus:

foreach ( $alleposts as $einpost ) 
            { 
            echo "<div class = 'post_ausgabe'>";
                echo "<h1>".$einpost->post_title."</h1>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            }

Ich habe mir eine neue Klasse von Div, die post_ausgabe definiert, weil ich die Formatierung etwas anders als bei der Bilderausgabe gestalten möchte. Der CSS-Eintrag sieht so aus:

.post_ausgabe{
    
    float:left;
    height: 300px;
    width: 30%;
    overflow: hidden;
    border: 1px solid blue;
    margin: 2px;
    padding:2px;    
    
}

Wichtig ist der overflow: hidden; damit die Sache leserlich bleibt. Und die Ausgabe? Ich nehme mal wieder das Inselfisch-Kochbuch, da sind richtig schön viele Beiträge drin, und das sieht jetzt erstmal so aus:

post_ausgabe

Zugegeben, das könnte hübscher sein, aber darum kümmern wir uns später. Falls sie sich wundern, daß hier überrall „Einleitung“ als Untertitel steht: das ist völlig korrekt so, weil bei mir (fast) jedes Rezept mit einer Einleitung beginnt. Erinnern sie sich? Da war was mit der Textstrukturierung wegen der Barrierefreiheit. Deswegen kommt als erster Text im post_content das Wörtchen „Einleitung“, als h2-Überschrift formatiert. Die Ausgabe ist also völlig richtig.

Link auf den Beitrag

Jetzt fehlt natürlich der Link auf den Beitrag, den holen wir uns wieder mal mit get_permalink(ID) und machen einen a href auf die Überschrift daraus. Der foreach folgt sogleich:

foreach ( $alleposts as $einpost ) 
            { 
            $akt_link = get_permalink($einpost->ID);
            
            echo "<div class = 'post_ausgabe'>";
                echo "<a href = '".$akt_link."'><h1>".$einpost->post_title."</h1></a>";
                echo $einpost->post_content."</br>";
            echo "</div>";    
            
            }

Jetzt sitzen die Links auf den Überschriften, wo sie hingehören.

alle_posts_mit_links

Wieder das Spiel mit dem Limit und der Zufallszahl

Man kann natürlich auch hier die Anzahl der auszugebenden Beiträge limitieren, und mit Rand() eine zufällige Auswahl der Beiträge erzeugen, und man kann den ganzen Shortcode natürlich auch wieder ins Text-Widget packen und z.B. in die Seitenleiste verschieben, da kann jeder selber damit spielen.

Was noch nicht schön ist

Der abgeschnittene Text stört mich, und der -zigfache Text Einleitung. Da letzteres aber sozusagen mein Privatvergnügen ist, gibts dafür einen neuen Beitrag.

Mit ’nem kleinen Dreh: Shortcodes mit Parameter

Shortcodes sind eine praktische Sache, wie wir gesehen haben, es lassen sich alle möglichen PHP-Funktionen sauber hineinpacken und an nahezu beliebiger Stelle ausgeben. Jetzt wärs aber doch auch schick, wenn man der Funktion auch noch bestimmte Werte mitgeben könnte, und der alte Programmierer nickt sofort und sagt: au ja, Parameter!

Parameterübergabe an Shortcodes

Ich nehm mir nochmal meinen Hallo-Evi-Shortcode her, und möchte jetzt den Namen als Parameter übergeben, so daß die Funktion dann „Hallo liebe xyz“ ausgibt. Im Shortcode-Aufruf sieht das so aus:

[mhs name = „Evi Silvia“]

Die eckigen Klammern weisen WordPress an, nach einer passenden Funktion zu suchen, das mhs ist der Shortcode der Funktion, die wir in der functions.php definiert haben. name ist der Bezeichner unseres Parameters, und der Wert des Parameters wird mit = zugewiesen. Parameter sind in WordPress-Shortcodes immer Strings, deswegen in Gäsefüßchen „Evi Silvia“.

Damit unsere Funktion jetzt den Parameter auch entgegennimmt, müssen wir den Funktionskopf ändern, das sieht jetzt so aus:

function mein_hallo_shortcode($param)

Dabei ist $param ein beliebiger PHP-Variablenname. Wer hat hier gesagt: echo „Hallo liebe $param“?
Nicht ganz, wenn man es so macht, kommt nämlich Folgendes heraus:

Hallo liebe Array

Parameter als Array

Die Parameter des Shortcodes werden nämlich als Array übergeben. Dabei bildet jede Zeile ein Wertepaar aus Bezeichner und Wert ab. In unserem Fall ist das nur eine Zeile, weil wir ja nur einen Parameter ausgeben. Um jetzt an den Wert des Parameters heranzukommen, muß man das Array auslesen, und das geht so:

function mein_hallo_shortcode($param) {

$aktName = $param[’name‘];
echo „<h1>Hallo liebe „.$aktName.“</h1>“;
}

Das $param[’name‘] liest den Wert („Evi Silvia“) zum Bezeichner name aus. Auch nicht so schlimm, man muß es nur wissen. Der Vorteil bei dieser Methode ist, daß man beim Aufruf eines Shortcodes eine ganze Latte von Parametern mitgeben kann und über die Bezeichner freien Zugriff darauf hat, die Reihenfolge der Parameter ist dabei prinzipiell egal.

Mehrere Parameter übergeben

Der Funktionsaufruf sähe dann z.B. so aus:

[mhs vorname = „Evi“ nachname = „Leu“]

Ensprechend wird die Funktion angepaßt:

$aktVorname =  $param['vorname'];
$aktNachname =  $param['nachname'];


echo "Hallo liebe".$aktVorname." ".$aktNachname;

Ausgabe: Hallo liebe Evi Leu

Alles klar? Wenn man weiß wie, ist die Parameterübergabe eine nützliche und flexible Angelegenheit.

Spiel&Spaß mit Shortcodes

Haben sie sich die Bilderausgabe auch schon in einen Shortcode gepackt? Ja fein, dann wirds Zeit für ein bißchen Spielerei am Sonntag Nachmittag

Anzahl der Bilder limitieren und Zufallszahl einbauen

Man will ja vielleicht nicht immer gleich alle Bilder ausgeben, sondern nur eine kleine Auswahl. Das ist ganz simpel, wir ergänzen das SQL-Statement einfach um eine LIMIT-Anweisung. Und damit nicht immer die selben Bilder herauskommen, ergänzen wir die Sache um die Zufallsfunktion RAND(). Das kommt ans Ende des SQL, vor den letzten schließenden Gänsefüßchen:

…ORDER BY RAND() LIMIT 6″ );

Ergebnis:

6_bilder_screenshot

Ab in die Seitenleiste

Und damit man die Bilderausgabe auch mal an anderer Stelle unterbringt, setzen wir den Shortcode ins Text-Widget und ziehen dieses in die rechte Seitenleiste. Sieht auch sauber aus:

6_bilder_seitenleiste

Ich hab auch mal das Inhaltsverzeichnis in die Seitenleiset gepackt, das sieht dann so aus:

ivz_in_der_seitenleiste

Wie und wo die Platzierung des Shortcodes Sinn macht, hängt natürlich vom verwendeten Theme und von der Art der Ausgabe ab, aber ich denke sie haben jetzt die Möglichkeiten ein bißchen gesehen. Nur zu, viel Spaß beim rumprobieren! Es darf naturlich auch noch ein wenig am CSS geschraubt werden, ich rücke hier mal die Bilder näher zusammen (den Margin einfach rausnehmen):

6_bilder _ohne_margin

Also, viel Vergnügen beim Ausprobieren!

Nützlicher Helfer: der Shortcode

Verlieren sie auch allmählich den Überblick bei den ganzen PHP-Code-Snippets? Mir gehts immer so, wenn sich mehr als ein Dutzend Snippets in PHP Code for Posts angesammelt habe, muß ich aufräumen. Dann überlege ich mir, welche echt nur zum Testen da waren, und welche Funktionalitäten ich wirklich weiterverwenden möchte. Aus letzteren baue ich mir dann Shortcodes mit aussagekräftigen Namen, und bunkere sie in meiner Archiv-Bibliothek.

Was ist ein Shortcode?

Kennen wir doch schon!

shortcode

Das ist das Kürzel, das an dieser Stelle den PHP-Code von Snippet Nr. 7 ausführt. Kann an beliebiger Stelle in einen Beitrag oder auf einer Seite eingesetzt werden. Sogar in das Text-Widget kann der Shortcode eingesetzt werden (wo es Sinn macht), und führt auch hier z.B. in der Sidebar seine Funktion aus.

Wie baue ich einen Shortcode?

Das ist keine schwierige Sache. Zu einem Shortcode gehören essentiell zwei Dinge:

ein Kürzel
eine PHP-Funktion

Das wars schon. Es gibt auch Shortcodes mit Parameter und umschließende Shortcodes, aber wir wollen es mal bei der minimalistischen Version belassen. Kürzel und zugehörige Funktion kommen in die functions.php ihres Child-Themes, das sieht im einfachsten Fall so aus:

hallo_evi_shortcode

Zuerst kommt die Funktion, die tut hier im Beispiel nichts weiter als einen Text mit echo ausgeben. Dann definiert man das Kürzel mit add_shortcode und gibt ihm den Funktionsnamen mit. Das wars schon. Jetzt an beliebiger Stelle einsetzen, z.B. in einen neuen Beitrag, einfach das Kürzel in eckigen Klammern, und voilá die Ausgabe (hier im Inselfisch-Kochbuch), brav als h1 formatiert:

mhs_ausgabe

Nahezu unbegrenzte Möglichkeiten

So eine Shortcode-Funktion kann aber noch viel mehr als nur echo-Ausgaben! Sie können zum Beispiel den gesamten Code für die Bilderausgabe in die Funktion packen, oder das Inhaltsverzeichnis, oder was immer sie wollen. Jeder valide PHP-Code ist möglich!

Wichtig ist nur, daß sie wirklich auf der functions.php ihres Child-Themes arbeiten, sonst sind beim nächsten Theme-Update unter Umständen ihre gesammelten Shortcodes futsch! Dabei sind die doch so vielseitig verwendbar – mehr dazu im nächsten Beitrag.

Bilder Ausgabe: Link zum Parent

Wir waren dabei stehengeblieben, alle Bilder aus der Mediathek auszugeben, und hatten diese Ausgabe auch hübsch formatiert. Wissen sie noch:

inner_join_ergebnis_style

Zu welchem Beitrag gehört das Bild? Zum Parent!

Jetzt wäre es natürlich noch sehr schick, wenn man von den Bildern direkt zu den zugehörigen Beiträgen und/oder Seiten gelangen könnte, nicht wahr? Auch das ist keine Hexerei, dafür verwenden wir das Feld parent_id aus der Tabelle wp_posts. Das kann 0 (Null) sein, für den Fall daß das Bild nicht zugeordnet ist, aber im Normalfall steht hier bei einem Bild einfach die ID des Datensatzes (Beitrag oder Seite), zu dem das Bild hochgeladen wurde.

Dazu holen wir uns mit get_permalink(parent_id) den Permalink zum entsprechenden Elter, basteln einen Link mit a href daraus, und fertig! Das war jetzt aber echt einfach, oder?

Feinarbeit

Wenn man ganz sauber arbeiten will, erledigt man die „elternlosen“ Bilder mit einer Erweiterung der WHERE-Klausel um ein parent_id > 0. Man könnte auch nur alle Bilder zu Beiträgen ausgeben, nicht die zu den Seiten, das läuft dann wieder mit post type like ‚post‘ und post_status like ‚publish‘ , aber das sei jedem selber überlassen.

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 😉