Ich habe mich jetzt in etlichen Beiträgen mit dem CSV-Import eigener Daten für eine Mitgliederverwaltung in WordPress herumgeschlagen, da wird es Zeit, ein Resumee zu ziehen.
Ist die Lösung mit dem CSV-Import praxistauglich?
Zur Erinnerung: ich habe mich dafür entschieden, immer die komplette CSV-Datei zu importieren, und einen Select vorzuschalten, der bereits vorhandene Datensätze (kenntlich an der eindeutigen ID/Mitgliedsnummer) unberührt stehenläßt.
Das kann man wirklich so machen, da im WordPress-Beitragseditor vorgenommene Änderungen an Mitgliederdaten so erhalten bleiben. Man muß halt nur konsequent sein, und eventuelle Änderungen von Adress- oder sonstigen Daten wirklich in WordPress einpflegen und nicht in der Excel-Liste, die ja nach wie vor weitergeführt wird.
Was nicht so schön ist: die Vergabe einer neuen Mitgliedsnummer muß in der Excel-Liste manuell erfolgen. Man könnte zwar auf die Idee kommen, die beim Anlegen eines Beitrags erzeugte WordPress-ID aus der Tabelle wp_posts als Mitgliedsnummer zu verwenden. Aber das ist ziemlich unbefriedigend, weil WordPress ja allen möglichen Ruß in der wp_posts speichert, Bilder und andere Attachments und Seiten und und und….
In der Praxis wird man hier früher oder später von der Excel-Liste auf eine separate Datenbanktabelle umstellen, sei es nun MySQL oder Access oder was auch immer. Hier hat man die Möglichkeit, die neue ID für ein neues Vereinsmitglied per AutoIncrement automatisch erzeugen zu lassen, das schließt Fehler bei der Vergabe einer neuen ID effektiv aus, und man kann seinen Nummernkreis selbst bestimmen.
Ja aber – wenn wirs schon in einer Datenbanktabelle haben…
Genau! Meine Rede! Wir entscheiden uns für eine MySQL-Lösung, und dann gehen wir weit, weit zurück und erinnern uns, was ich in etlichen Beiträgen vor langer Zeit über die Einbindung eigener Tabellen in WordPress erzählt habe. Es ist relativ einfach zu realisieren, die Datenpflege kann über unseren selbstgeschriebenen Datenbankeditor sehr komfortabel erfolgen, es kann in der eigenen Tabelle sehr gezielt nach den unterschiedlichsten Kriterien gesucht werden, um nur einige Pluspunkte zu nennen. Das bringt mich auf was, das ich beinahe vergessen hätte:
Benutzerdefinierte Felder sind importiert, und nun?
Wir können sie auch relativ problemlos anzeigen, aber was ist, wenn ich mal eine gezielte Suchauswertung über mehrere Custom Fields fahren will? Zum Beispiel alle Mitglieder herausfinden, die in München wohnen, männlich sind und an Fußball interessiert.
Da hakts nämlich kräftig. WordPress bietet so ad hoc keine Möglichkeit dafür. Ja ich hörs schon, es gibt Plugins die einem da behilflich sind und eine gezielte Suche nach benutzerdefinierten Feldern ermöglichen, aber wie sieht das Ergebnis aus? Krieg ich halt die Ergebnisse meiner Suche auf einer WordPress-Seite als HTML angezeigt.Na prima.
Und was ist wenn ich das weiterverarbeiten will, z.B. für eine gezielte Mailing-Aktion an alle meine Münchner Fußballmänner? Da muss ich schon auf die Datenbank.
Nochmal langsam zum Nachvollziehen: für jedes Custom Field ein Join
Zur Erinnerung, meine benutzerdefinierten Felder stecken in der wp_postmeta und sind dort über die post_id den Datensätzen in der wp_posts zugeordnet. Das Feld für den Ort hat den meta_key „ort“ und als meta_value den entsprechenden Eintrag, z.B. München. Um jetzt alle Datensätze herauszufischen, die in der wp_postmeta beim meta_key einen Ort haben, muß ich die Tabellen über die post_id joinen, das sieht dann in etwa so aus:
SELECT wp_postmeta.meta_id, wp_postmeta.post_id, wp_postmeta.meta_key, wp_postmeta.meta_value, wp_posts.post_title, wp_posts.post_content, wp_posts.post_status
FROM wp_posts INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id
WHERE (((wp_postmeta.meta_key) Like „ort“) AND ((wp_posts.post_status) Like „publish“));
Ganz schön viel Holz für ein einzelnes Feld, nicht wahr? Wenn ich jetzt zusätzlich noch ein zweites Feld, z.B. die Postleitzahl, mit dazuhaben möchte, muß ich tatsächlich die Tabellen ein zweites Mal joinen und die where-Klausel nochmal stellen mit wp_postmeta.meta_key) Like „plz“, das sieht dann schon so aus:
SELECT wp_postmeta.meta_id, wp_postmeta.post_id, wp_postmeta.meta_key, wp_postmeta.meta_value, wp_posts.post_title, wp_posts.post_content, wp_posts.post_status, wp_postmeta_1.meta_key, wp_postmeta_1.meta_value
FROM wp_postmeta AS wp_postmeta_1 INNER JOIN (wp_posts INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id) ON wp_postmeta_1.post_id = wp_posts.ID
WHERE (((wp_postmeta.meta_key) Like „ort“) AND ((wp_posts.post_status) Like „publish“) AND ((wp_postmeta_1.meta_key) Like „plz“));
Das, liebe Freunde, gefällt mir überhaupt nicht. Auf meiner eigenen Datenbanktabelle würde der Select nämlich ungefähr so aussehen:
Select ID, vorname, nachname, ort, plz from meine_tabelle
Fertig. Ist irgendwie hübscher, nicht wahr?
Mein Fazit
Mir ist für so etwas die simple MySQL-Abfrage auf der eigenen Datenbanktabelle -zigfach sympathischer als der mühsame mehrfache Join von wp_posts und wp_postmeta. Das ist meine persönliche Präferenz als alte Datenbankerin.
Und mein Fazit lautet: Ich würde meinem Kunden auf jeden Fall die Lösung mit der eigenen Datenbanktabelle als die wesentlich flexiblere und übersichtlichere Methode nahelegen. Aber wie gesagt, ich bin da vorbelastet, ich lieeebe Datenbanklösungen und spiele gern mit MySQL. Am Ende muß jeder selber entscheiden, was ihm bzw. seinem Kunden besser taugt.
Ich lass es jetzt mal gut sein und überlege mir ein neues Thema für etwas praktischen Spaß auf der Datenbank. Stay tuned!
und die
