Archiv der Kategorie: Allgemein

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 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.

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?

Beitragsausgabe: Wie werd ich bloß den Text „Einleitung“ los?

Also, das ist jetzt quasi mein Privatvergnügen, ich möchte aus der Beitragsausgabe die wiederholte Zwischenüberschrift „Einleitung“ heraus haben. Nochmal zur Erinnerung wie das aussieht:

alle_posts_mit_links

alle_posts_mit_links

Sie sehen hier, daß nicht alle Posts mit „Einleitung“ anfangen, ich darf also nicht alle „behandeln“.

Wie ist hier die Logik?

Also, mal sehen ob ich das irgendwie logisch gebacken kriege. Vor fast jedem Rezept steht der Text „Einleitung“, als h2-Überschrift formatiert. Das Dumme daran ist, daß es bei einigen wenigen Rezepten keine Einleitung gibt, sonst könnte ich einfach die Anzahl der Zeichen abzählen und den post_content um soundsoviele Zeichen abschnippeln.Geht nicht, ich muß eine Fallunterscheidung machen.

Ich muß auch genaugenommen nicht nur den Text „Einleitung“ loswerden, sondern auch die <h2>-Tags. Das macht abgezählt die ersten 19 Zeichen, die abzuschneiden sind. Mal sehen, ob ich das in PHP gebacken kriege.

Kurzer Blick ins PHP-Manual

Mit einem strcmp müßte es eigentlich gehen.

$akt_text = $einpost->post_content;
                $such_text = "<h2>Einleitung</h2>%";
                $vergleich = strcmp ($such_text, $akt_text);

strcmp Gibt 1 zurück, wenn die Strings gleich sind, und kleiner Null (-1) wenn nicht gleich. Na bitte, geht doch! Jetzt noch eine IF-Abfrage, und mit substr() die ersten 19 Zeichen abschneiden, dann hab ichs.

if ($vergleich == 1){
                            
                            $akt_text = substr($akt_text, 19);
                        
                    }

Jetzt gebe ich noch anstelle des post_content den abgeschnittenen $akt_text aus, und feddisch, die Zwischenüberschrift mit dem Text „Einleitung“ ist draussen!

ohne_einleitung_alle_posts_mit_links

ohne_einleitung_alle_posts_mit_links

Ich lieeebe die String-Funktionen von PHP!
Hier kommt nochmal die ganze neue Foreach-Schleife:

foreach_ohne_einleitung

foreach_ohne_einleitung

Jetzt müßte man nur noch den Beitragstext irgendwie vernünftig kürzen, aber dafür gibts 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

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

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.

 

 

 

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

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:

  1. ein Kürzel
  2. 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

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

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.

 

 

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

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

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

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.

 

Wer schreibt schon Kommentare? Die Spam-Bots!

Das mit den Kommentaren in WordPress ist so eine Sache. Da haben sich die WordPress-Entwickler echt Mühe gegeben und so richtig rangeklotzt, das sieht man an den fein einstellbaren Optionen unter Einstellungen/Kommentare. Ja und wozu? Jetzt will sie keiner!

Meine E-Mail soll ich angeben? Nein Danke!

Erstens schreibt kein Schwein einen Kommentar, wenn er seine E-Mail-Adresse hinterlassen soll. Das kann man zwar ausschalten, aber es ist per Default aktiviert, und schreckt erfahrungsgemäß ganz viele Besucher ab. Niemand möchte sich ungefragte Werbemails und Newsletter einfangen, und eine E-Mail-Adresse ist schließlich eine sehr persönliche Information, die man nicht so ohne weiteres auf einer fremden Seite eingibt. Ausserdem gibt es wohl eine sehr hohe Hemmschwelle, auf fremden Seiten überhaupt Spuren zu hinterlassen. Die überwiegende Mehrzahl der Besucher bleibt lieber in der passiven Betrachter-Rolle und kommentiert auch dann nicht, wenn die E-Mail-Addi nicht abgefragt wird. Anders sieht das in den unzähligen gutbesuchten Hobby- und Freizeitforen aus, da ist die Hemmschwelle derartig niedrig, daß die Leute in den Forenbeiträgen über alles, aber wirklich alles plaudern. Scheinbar ohne sich dessen bewußt zu sein, daß JEDER ihre Beiträge lesen kann. Schauen sie mal bei chefkoch.de in die Plauderecke, dann wissen sie was ich meine…
Aber das ist jetzt ein bißchen sehr Off Topic, zurück zu unserer durchschnittlichen WordPress-Webseite.

Kommentare zu geschäftlichen Seiten – macht das überhaupt Sinn?

WordPress ist ja das ideale Frontend für überschaubare Webauftritte von kleinen Unternehmen und Selbständigen, für den Metzger und die Gaststätte um die Ecke, für das Lebensmittelgeschäft, die Autowerkstatt, für Ärzte, Anwälte, Steuerberater – was diese Kundschaft benötigt, ist einfach eine Visitenkarte im Internet, in der sich die Firma darstellt, und in der die relevanten Firmeninformationen  (Geschäftsfeld, Angebote, Spezialitäten, Öffnungszeiten, Anfahrtskizze etc pp.) zu finden sind. Meistens  ist noch ein einfaches Kontaktformular gefragt, und mehr nicht. Das geht sogar noch weiter: die Blog-Funktionalität von WordPress wird größtenteils kaum genutzt, ganz selten gibt es mal die Anforderung nach einer Seite mit aktuellen Informationen wie z.B. die Wochenkarte eines Restaurants oder das monatliche Mandantenrundschreiben eines Steuerberaters. In der Regel aber sind die WordPress-Seiten für kleinere Unternehmen statisch, erfordern keinerlei Interaktivität und möchten auch bittesehr keine Kommentare haben, die werden fast immer ganz deaktiviert, punktum.

Und wie ist das mit dem Spam?

Das hält sich dank Akismet, Antispam Bee und Konsorten in sehr überschaubaren Grenzen. Ein Spamschutz-Plugin ist ein Muß für jede WordPress-Webseite, die irgendeine Art von Kontaktformular anbietet. Aber die bekannten Spamwächter funktionieren absolut zuverlässig und sind völlig problemlos sowohl in der Installation als auch im laufenden Betrieb.

Und was ist mit Captcha als Schutz?

Mit Kanonen auf Spatzen geschossen. Ausserdem sind Captcha und reCaptcha und wie sie alle heissen unüberwindliche Hindernisse im Sinne der Accessibility/Barrierefreiheit. Einen sehr informativen Artikel hierzu finden sie hier bei bitv-lotse.de, und den empfehle ich jetzt als Abendlektüre.