Archiv der Kategorie: Contact Form 7

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.

 

 

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.

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

Über den TV Weiß-Blau

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

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

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

Das Datenmodell in WordPress und Contact Form 7

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

anmeldeformular_adressdaten

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

fitness_sportarten

fitness_sportarten

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

Woher kommen nun die Daten?

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

Kleine Anmerkung zur tabellarischen Darstellung in CF7

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

cf7_tabellen

cf7_tabellen

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