Ich habe mich jetzt in etlichen Beitr\u00e4gen mit dem CSV-Import eigener Daten f\u00fcr eine Mitgliederverwaltung in WordPress herumgeschlagen, da wird es Zeit, ein Resumee zu ziehen.<\/p>\n
Zur Erinnerung: ich habe mich daf\u00fcr entschieden, immer die komplette CSV-Datei zu importieren, und einen Select vorzuschalten, der bereits vorhandene Datens\u00e4tze (kenntlich an der eindeutigen ID\/Mitgliedsnummer) unber\u00fchrt stehenl\u00e4\u00dft.<\/p>\n
Das kann man wirklich so machen, da im WordPress-Beitragseditor vorgenommene \u00c4nderungen an Mitgliederdaten so erhalten bleiben. Man mu\u00df halt nur konsequent sein, und eventuelle \u00c4nderungen von Adress- oder sonstigen Daten wirklich in WordPress einpflegen und nicht in der Excel-Liste, die ja nach wie vor weitergef\u00fchrt wird.<\/p>\n
Was nicht so sch\u00f6n ist: die Vergabe einer neuen Mitgliedsnummer mu\u00df in der Excel-Liste manuell erfolgen. Man k\u00f6nnte 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\u00f6glichen Ru\u00df in der wp_posts speichert, Bilder und andere Attachments und Seiten und und und….<\/p>\n
In der Praxis wird man hier fr\u00fcher oder sp\u00e4ter von der Excel-Liste auf eine separate Datenbanktabelle umstellen, sei es nun MySQL oder Access oder was auch immer. Hier hat man die M\u00f6glichkeit, die neue ID f\u00fcr ein neues Vereinsmitglied per AutoIncrement automatisch erzeugen zu lassen, das schlie\u00dft Fehler bei der Vergabe einer neuen ID effektiv aus, und man kann seinen Nummernkreis selbst bestimmen.<\/p>\n
Genau! Meine Rede! Wir entscheiden uns f\u00fcr eine MySQL-L\u00f6sung, und dann gehen wir weit, weit zur\u00fcck und erinnern uns, was ich in etlichen Beitr\u00e4gen vor langer Zeit \u00fcber die Einbindung eigener Tabellen in WordPress erz\u00e4hlt habe. Es ist relativ einfach zu realisieren, die Datenpflege kann \u00fcber 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\u00e4tte:<\/p>\n
Wir k\u00f6nnen sie auch relativ problemlos anzeigen, aber was ist, wenn ich mal eine gezielte Suchauswertung \u00fcber mehrere Custom Fields fahren will? Zum Beispiel alle Mitglieder herausfinden, die in M\u00fcnchen wohnen, m\u00e4nnlich sind und an Fu\u00dfball interessiert.<\/p>\n
Da hakts n\u00e4mlich kr\u00e4ftig. WordPress bietet so ad hoc keine M\u00f6glichkeit daf\u00fcr. Ja ich h\u00f6rs schon, es gibt Plugins die einem da behilflich sind und eine gezielte Suche nach benutzerdefinierten Feldern erm\u00f6glichen, aber wie sieht das Ergebnis aus? Krieg ich halt die Ergebnisse meiner Suche auf einer WordPress-Seite als HTML angezeigt.Na prima.<\/p>\n
Und was ist wenn ich das weiterverarbeiten will, z.B. f\u00fcr eine gezielte Mailing-Aktion an alle meine M\u00fcnchner Fu\u00dfballm\u00e4nner? Da muss ich schon auf die Datenbank.<\/p>\n
Zur Erinnerung, meine benutzerdefinierten Felder stecken in der wp_postmeta und sind dort \u00fcber die post_id den Datens\u00e4tzen in der wp_posts zugeordnet. Das Feld f\u00fcr den Ort hat den meta_key „ort“ und als meta_value den entsprechenden Eintrag, z.B. M\u00fcnchen. Um jetzt alle Datens\u00e4tze herauszufischen, die in der wp_postmeta beim meta_key einen Ort haben, mu\u00df ich die Tabellen \u00fcber die post_id joinen, das sieht dann in etwa so aus:<\/p>\n
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<\/em> Ganz sch\u00f6n viel Holz f\u00fcr ein einzelnes Feld, nicht wahr? Wenn ich jetzt zus\u00e4tzlich noch ein zweites Feld, z.B. die Postleitzahl, mit dazuhaben m\u00f6chte, mu\u00df ich tats\u00e4chlich die Tabellen ein zweites Mal\u00a0 joinen und die where-Klausel nochmal stellen mit wp_postmeta.meta_key) Like „plz“,<\/strong><\/em> 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<\/em> Das, liebe Freunde, gef\u00e4llt mir \u00fcberhaupt nicht. Auf meiner eigenen Datenbanktabelle w\u00fcrde der Select n\u00e4mlich ungef\u00e4hr so aussehen:<\/p>\n Select ID, vorname, nachname, ort, plz from meine_tabelle<\/em><\/strong><\/p>\n Fertig. Ist irgendwie h\u00fcbscher, nicht wahr?<\/p>\n Mir ist f\u00fcr so etwas die simple MySQL-Abfrage auf der eigenen Datenbanktabelle -zigfach sympathischer als der m\u00fchsame mehrfache Join von wp_posts und wp_postmeta. Das ist meine pers\u00f6nliche Pr\u00e4ferenz als alte Datenbankerin.<\/p>\n Und mein Fazit lautet: Ich w\u00fcrde meinem Kunden auf jeden Fall die L\u00f6sung mit der eigenen Datenbanktabelle als die wesentlich flexiblere und \u00fcbersichtlichere Methode nahelegen. Aber wie gesagt, ich bin da vorbelastet, ich lieeebe Datenbankl\u00f6sungen und spiele gern mit MySQL. Am Ende mu\u00df jeder selber entscheiden, was ihm bzw. seinem Kunden besser taugt.<\/p>\n Ich lass es jetzt mal gut sein und \u00fcberlege mir ein neues Thema f\u00fcr etwas praktischen Spa\u00df auf der Datenbank. Stay tuned!<\/p>\n","protected":false},"excerpt":{"rendered":" Ich habe mich jetzt in etlichen Beitr\u00e4gen mit dem CSV-Import eigener Daten f\u00fcr eine Mitgliederverwaltung in WordPress herumgeschlagen, da wird es Zeit, ein Resumee zu ziehen. Ist die L\u00f6sung mit dem CSV-Import praxistauglich? Zur Erinnerung: ich habe mich daf\u00fcr entschieden, immer die komplette CSV-Datei zu importieren, und einen Select vorzuschalten, der bereits vorhandene Datens\u00e4tze (kenntlich […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[18,25,20,7,5,2],"tags":[],"_links":{"self":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts\/572"}],"collection":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/comments?post=572"}],"version-history":[{"count":6,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts\/572\/revisions"}],"predecessor-version":[{"id":579,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/posts\/572\/revisions\/579"}],"wp:attachment":[{"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/media?parent=572"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/categories?post=572"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/evileu.de\/zum-schwarzen-pinguin\/wp-json\/wp\/v2\/tags?post=572"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nFROM wp_posts INNER JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id<\/em>
\nWHERE (((wp_postmeta.meta_key) Like „ort“<\/strong>) AND ((wp_posts.post_status) Like „publish“));<\/em><\/p>\n
\n<\/strong><\/em><\/p>\n
\nFROM 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<\/em>
\nWHERE (((wp_postmeta.meta_key) Like „ort“) AND ((wp_posts.post_status) Like „publish“) AND ((wp_postmeta_1.meta_key) Like „plz“));<\/em><\/p>\nMein Fazit<\/h2>\n