Archiv der Kategorie: MySQL

Die bessere Alternative zum -zigfachen Join: Kreuztabelle

Also, zuerst mal dieses: ich habe versucht herauszufinden, ob MySQL Kreuztabellen (Pivot Tables) kann oder nicht, und die Tendenz beim Googlen geht zu eher nicht. Jedenfalls gibt es keinen Transform-Befehl, man muß sich da irgendwie anders behelfen.

Ich habe da die tollsten Konstrukte gefunden, hier ein besonders Hübsches mit einem Case für jedes Feld… na, das ist ja wohl nicht der Weisheit letzter Schluß. Da greife ich doch lieber auf meine Leib- und Magendatenbank zurück, nämlich Microsoft Access. Ich bin ja sonst kein Microsoft-Fan, aber das gute alte Access ist einfach eine tolle Datenbank mit einem sagenhaften Bedienkomfort im Entwurfsmodus. Auch wenn die zugrundeliegende Jet-Engine schon viele Jahre auf dem Buckel hat, im intuitiven Zusammenstellen aller möglichen Arten von Abfragen ist Access echt ungeschlagen.

Was wollen wir erreichen?

Wir haben ja im letzten Artikel gesehen, daß wooCommerce zu jeder Bestellung mindestens 48 Einträge in der wp_postmeta anlegt. Ich hätte jetzt gerne einen tabellarischen Überblick über alle Bestellungen, mit allen 48 Werten aus der wp_postmeta zu jeder Bestellung.

Das heißt im Klartext: eine Tabelle mit den relevanten Daten aus der wp_posts, und allen 48 Meta Keys als Felder in einer Zeile. Auf jeden Fall brauchen wir einen Join von der wp_posts auf die wp_postmeta über die ID der Bestellung, und dann noch die Meta Keys als Feldnamen, befüllt mit den Meta Values. Klingt schaurig kompliziert, ist aber in Access relativ einfach machbar, nämlich mit einer Kreuztabelle.

Der SQL für die Kreuztabelle

…sieht so aus:

TRANSFORM First(postmeta_alle_orders.meta_value) AS ErsterWertvonmeta_value
SELECT postmeta_alle_orders.post_id, postmeta_alle_orders.post_title, postmeta_alle_orders.post_status, postmeta_alle_orders.post_type
FROM postmeta_alle_orders
GROUP BY postmeta_alle_orders.post_id, postmeta_alle_orders.post_title, postmeta_alle_orders.post_status, postmeta_alle_orders.post_type
PIVOT postmeta_alle_orders.meta_key;

Den kann man sich mit Hiilfe des Kreuztabellen-Assistenten erstellen und dann im Entwurfsmodus komfortabel editieren.

Das Ergebnis der Kreuztabelle

Ich habs mal schnell der Übersichtlichkeit halber in ein Formular gepackt (auch hierfür hat Access einen prima Assistenten), da sieht dann z.B. unser Datensatz mit der Nummer 42 so aus:

formular_kreuztabelle

formular_kreuztabelle

Na, da hat man wenigstens mal alle Felder im Blick. Wenn man jetzt noch wüßte, für was die alle gut sind… aber da lasse ich jeden selber raten, anhand der Feldnamen müßte man da relativ weit kommen.

Wie kann man es übersichtlicher machen?

Wir haben jetzt wenigstens ein bißchen den Überblick gewonnen, mit 7 Zeilen Jet-SQL statt 48 mal Join und Case. Die Krux ist halt, dass es von vorne herein ein Unding ist, einem Datensatz so viele Werte redundant zuzuordnen.

Wenn sie nur mal die vielen Felder anschauen, die etwas mit Adressen zu tun haben, die gehören ausgelagert! Da gehört ein Fremdschlüssel auf die Kundennummer rein, und zu den Kunden-Basisdaten in einer eigenen Tabelle legen wir uns noch eine schnuckelige zweite Tabelle mit Rechnungsadresse und Lieferadresse (falls abweichend) des Kunden an, das wars dann und ist sauber gelöst.,

Damit können die ganzen Adressfelder aus den Bestellungen rausfliegen, das macht so über den Daumen gepeilt schon mal etwas mehr als 20 Felder weniger. Genauso sieht es mit den Zahlungsmodalitäten und den Steuerinformationen aus, auch die gehören normalisiert und ausgelagert, das wären dann noch mal ein rundes Dutzend Felder weniger.

Aber… die wooCommerce-Entwickler wissen ja anscheinend nicht, wie man Daten normalisiert und Detailtabellen anlegt, deshalb dieser unüberschaubare Datenwust. Das ist einfach nur grottenschlecht programmiert, da beißt die Maus kein Faden ab. Es kann sich ja jeder selber überlegen, wie ein sauberes Datenmodell für die Bestellungen aussehen könnte, so als Fingerübung zum Entspannen 😉

Ich mach hier mal Schluß, und überleg mir ein neues Thema. See you demnächst, ich wünsche gute Erholung vom wooCommerce-Datenchaos!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Nix für schwache Nerven: wooCommerce-Bestellungen auf der Datenbank

1 Bestellung = 1 Beitrag

Wenn jetzt endlich ein Kunde etwas in unserem Online-Shop gekauft hat, landet die Bestellung – wie könnte es anders sein – in der wp_posts mit dem Post Type „shop_order“. Das schauen wir uns mal ganz kurz an. Ich nehme nur ein paar ausgewählte Felder, sonst wirds unübersichtlich:

SELECT wp_posts.ID, wp_posts.post_author, wp_posts.post_content, wp_posts.post_title, wp_posts.post_status, wp_posts.post_name, wp_posts.post_type, wp_posts.comment_count
FROM wp_posts
WHERE (((wp_posts.post_type) Like „shop_order“));

Ergebnis:

shop_orders

shop_orders

Der post_status scheint noch interessant zu sein, da steht nur einer auf wc-completed, alle anderen auf wc-on-hold. Was ein comment_count von 3 bedeuten soll ist mir allerdings ein Rätsel – und es ist mir schnuppe.

Eine Bestellung, wie viele Einträge in der wp_postmeta?

Wir klemmen uns mal die erste Order-ID, das ist die 42, und gehen in der wp_postmeta suchen, was dazu alles abgespeichert ist. Zur Erinnerung: in der wp_postmeta ist jedem Datensatz die zugehörige post_id aus der wp_posts zugeordnet.

SELECT wp_postmeta.meta_id, wp_postmeta.post_id, wp_postmeta.meta_key, wp_postmeta.meta_value, wp_posts.ID, wp_posts.post_title, wp_posts.post_status, wp_posts.post_type
FROM wp_postmeta INNER JOIN wp_posts ON wp_postmeta.post_id = wp_posts.ID
WHERE (((wp_postmeta.post_id)=“42″) AND ((wp_posts.post_type) Like „shop_order“));

Das – halleluja! Spuckt 48 Datensätze aus. Achtundvierzig. Will heissen, zu Order Nr. 42 hat wooCommerce 48 Einträge in der wp_postmeta angelegt und dort irgendwelche Daten gespeichert. Ich stelle hier mal spaßeshalber eine Liste der Meta-Keys rein:

 

order_42
meta_key
_order_key
_customer_user
_payment_method
_payment_method_title
_transaction_id
_customer_ip_address
_customer_user_agent
_created_via
_date_completed
_completed_date
_date_paid
_paid_date
_cart_hash
_billing_first_name
_billing_last_name
_billing_company
_billing_address_1
_billing_address_2
_billing_city
_billing_state
_billing_postcode
_billing_country
_billing_email
_billing_phone
_shipping_first_name
_shipping_last_name
_shipping_company
_shipping_address_1
_shipping_address_2
_shipping_city
_shipping_state
_shipping_postcode
_shipping_country
_order_currency
_cart_discount
_cart_discount_tax
_order_shipping
_order_shipping_tax
_order_tax
_order_total
_order_version
_prices_include_tax
_billing_address_index
_shipping_address_index
_shipping_method
_recorded_sales
_recorded_coupon_usage_counts
_order_stock_reduced

Hübsch, nicht wahr? Wenigstens haben die wooCommerce_Entwickler recht sprechende Namen für die Meta-Keys verwendet, da kann man sich in den meisten Fällen wenigstens denken, was das sein soll.

Und das sind nur die Einträge zu einer einzigen ausgewählten Bestellung!

Was, wenn ich Auswertungen über die Bestellungen fahren will?

Aber ja verehrtes Publikum, sowas kommt vor. Daß man wissen will, wie viele Bestellungen an einem bestimmten Tag eingegangen sind. Oder wie viele davon per Scheck bezahlt wurden. Oder Bestellungen nach Postleitzahlen geordnet oder oder… sie wissen schon, was da so alles beim Kunden anliegt.

Das hatten wir schon ein paar mal, wenn man aus der wp_postmeta die meta_values zu einer bestimmten ID aus der wp_posts herauskriegen will, muß man pro Meta Key einen Join auf die wp_postmeta anlegen. Würde im Ernstfall hier einen 48fachen Join verlangen, das muß man sich mal so richtig reinziehen…

Eine andere Möglichkeit wäre eine Kreuztabelle (Microsoft Access kann sowas, bei MySQL bin ich mir nicht sicher), aber die hätte dann mehr als 48 Felder, das ist auch eher von der unhandlichen Sorte.

Ja Kruzitürken, haben die noch nie etwas von Fremdschlüsseln und Detailtabellen gehört?

Ein Beispiel wie man’s NICHT macht

Wir nehmen nur mal ein Beispiel:

Beim meta_key _payment_method steht in meinem Datensatz Nr. 42 der meta_value „cheque“. Dann nehmen wir den meta_key _payment_method_title noch mit, der hat den Wert „Scheckzahlung“

Und wenn ich jetzt ein paar Hundert oder Tausend Bestellungen habe, stehen der cheque und die Scheckzahlung eben auch Hundert oder Tausend mal in der wp_postmeta. Das, verehrtes Publikum, ist Redundanz, und zwar so richtig kriminelle Redundanz. So macht man sowas nicht. Da nimmt man eine Detailtabelle mit den Zahlungsarten (Scheck, Nachname, Bar bei Abholung…), von denen kriegt jede eine ID, die wird zu den Bestellungen dann als Fremdschlüssel gespeichert. Das ist Datennormalisierung für Anfänger, erstes Semester.

Und damit, liebe Leser, lasse ich euch mal mit den 48 Meta Keys allein meditieren, das langt für einen Beitrag.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Noch’n Déja vu: was ist das führende System?

Das, liebes Publikum, hatten wir  schon mal, als es um die Mitgliederdaten des Turnvereins Weiß-Blau ging – erinnert sich noch jemand? Man kann Massendaten per CSV-Upload in WordPress reinjagen, aber man muß vorher ganz klar entscheiden, was das führende System ist. Das ist jetzt noch nicht mal WordPress-spezifisch, diese Überlegung muß man immer wieder anstellen, wenn es um die elektronische Verarbeitung von Betriebsdaten geht. Dabei stellen sich immer wieder die folgenden Fragen:

  1. Was passiert, wenn nach dem ersten Load noch Datensätze dazukommen?
  2. Was passiert, wenn sich an den Stammdaten mal etwas ändert?
  3. Aus welchem System fährt man betriebliche Auswertungen und Statistiken?

Wir gehen es mal der Reihe nach durch und klopfen ab, ob sich wooCommerce als führendes System für unsere Artikelstammdaten eignet.

Hinzufügen von Datensätzen:

Wenn es wirklich nur einzelne Datensätze sind, kann man die tatsächlich per Hand einpflegen, das heißt in unserem Fall: vereinzelt dazukommende neue Artikel werden manuell in wooCommerce angelegt. Stammdaten einpflegen, Bild hochladen, fertig.
Sobald es aber mehr als sagen wir mal ein halbes Dutzend neue Datensätze pro Monat sind, ist das zu viel Aufwand und eben auch fehlerträchtig. Dann braucht man einen selektiven CSV-Upload, der die bereits existierenden Bestandsdaten unberührt läßt und nur die neu hinzugekommenen Artikel neu anlegt. Ob das funktioniert, muß man vorher abklären, ehe man sich für ein CSV-Upload-Plugin entscheidet.

Stammdaten Pflege:

Hier sieht es ähnlich aus wie oben, das kommt darauf an wieviele Änderungen man zu machen hat. Vereinzelte Datensätze kann man per Hand editieren, bei Massenänderungen an den Bestandsdaten geht man doch lieber an die Datenbank.

Ich nenne mal ein einfaches Beispiel für eine typische Massenänderung: nehmen wir mal an, die nickelfreien Ohrringhaken sind im Einkauf 20 % teurer geworden, und ich möchte in der Folge die Preise für alle Ohrringe in meinem Sortiment etwas anheben, sagen wir mal um pauschal 5 %. Das geht bei drei, vier Ohrringen in meinem Onlineshop noch per Hand, sobald das allerdings mehr werden ist eine manuelle Änderung nicht mehr zumutbar.

Was tut der EDV-Fuzzy in so einem Fall? Ja klar, wir fahren einen Update auf der Datenbank! Der SQL auf einer Produkt-Stammdaten-Tabelle sieht so oder ähnlich aus:

update products set products_price=products_price*1.05 where products_category like „Ohrringe“;

Wenn’s denn so einfach wäre! Ich erinnere mal kurz an den letzten Artikel: um allein an die Produktkategorie eines Artikels heranzukommen, brauche ich einen Join über mindestens 4 Tabellen, der sah so aus:

(„SELECT Wp_term_relationships.*,Wp_terms.* FROM Wp_term_relationship
LEFT JOIN Wp_posts  ON Wp_term_relationships.object_id = Wp_posts.ID
LEFT JOIN Wp_term_taxonomy ON Wp_term_taxonomy.term_taxonomy_id = Wp_term_relationships.term_taxonomy_id
LEFT JOIN Wp_terms ON Wp_terms.term_id = Wp_term_relationships.term_taxonomy_id
WHERE post_type = ‚product‘ AND taxonomy = ‚product_cat‘
AND  object_id = „.$aktuelleID.““)

Und das ist erst der Select für die Kategorie zu einem einzelnen Artikel. Einen Update auf den _regular_price aus der wp_postmeta (noch ein Join mehr) mit einer Where-Klausel wie „where wp_terms.name like „Ohrringe““ kann sich jeder selber daraus basteln.

Das, liebe alte Datenbankfüchse, ist zwar interessantes SQL, aber in der realen Anwendung eine Zumutung!

Betriebliche Auswertungen und Statistiken oder: was zum Donner ist denn nun unser führendes System?

Die Artikelliste ist mein führendes System. Ich meine diese hier:

artikelliste_excel

artikelliste_excel

Mir ist es nämlich echt zu mühselig, statistische Auswertungen meiner Stammdaten über die WordPress/wooCommerce-Tabellen zu fahren. Mein Kunde möchte zum Beispiel wissen, wieviele Ketten und Colliers über 15 € er im Sortiment hat. Oder auch nur die Anzahlen der Artikel zu den einzelnen Kategorien, oder so etwas in der Richtung. Das macht man im Zweifelsfall im Excel mit den entsprechenden Filtern, das ist ratzfatz erledigt. Über die WordPress-Datenbank geht es nur mit solchen akrobatischen Verrenkungen und Joins über mehrere Tabellen wie gerade eben gezeigt, das ist mir einfach zu umständlich.

Wie sieht das in der Praxis aus?

Stammdatenänderungen müßten dann ausschließlich in der Excel-Tabelle passieren, aber vielleicht laden wir sie ja in Access, dann gehen solche Sonderwünsche wie ein seleketiver Update auf den Preis in ein paar Minuten. Export nach CSV, selektiver Upload – da müßte man dann die Option haben, bestehende Datensätze zu aktualisieren, aber das bieten die meisten Import-Plugins schon an. WooCommerce wäre dann ganz klar das sekundäre System, und da gehört es auch hin, wenn sie mich fragen. Für eine Bestandsführung mit allem was dazugehört ist es nämlich schlicht nicht geeignet. Meine Meinung, und natürlich subjektiv aus der Sicht einer alten Datenbankerin.

Aber ich will wooCommerce nicht in Bausch und Bogen verdammen, es ist nämlich schon ein intelligenter Online-Shop und hat noch etliche interessante Features zu bieten. Dazu mehr im nächsten Artikel.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Kraut und Rüben auf der Datenbank: wo wooCommerce die Produktdaten speichert

Ein Produkt = Beitrag: ja, und der Rest?

Wie ihnen bei einem kurzen Blick auf die Datenbank vielleicht schon aufgefallen ist, speichert wooCommerce die Produkte in der wp_posts mit dem post_type „product“. Das kennen wir ja schon, die wp_posts muß oft für allerlei Datengemusel herhalten, das mit „posts“, also mit Beiträgen, nicht im entferntesten was zu tun hat.Die Produktbilder landen übrigens auch in der wp_posts, aber das kennen wir ja auch schon, WordPress macht das halt mit Bildern so, mit dem post_type „attachment“.

Über Sinn und Unsinn dieser Praxis kann man lange diskutieren, es wird halt oft so gemacht und sogar als Best Practice empfohlen. Und da wir uns für wooCommerce als Shopsoftware entschieden haben, leben wir halt damit. Ich mach das hier mal nur im Schnelldurchgang, die Details kann ja jeder selber nachschauen.

Kleine Wiederholung: unsere Produktdaten

  1. Feld in der CSV-Datei:
    Artikelnummer;Kategorie;Bezeichnung;Beschreibung;Format;Preis
  2. Feld in der Dropdown-Liste:
    sku; category; post_title; post_content; post_excerpt; regular_price

Die fett markierten Felder stecken in der wp_posts unter den bekannten Feldnamen. Aber wo sind die anderen? Gehen wir’s mal der Reihe nach durch.

  1. Artikelnummer: sku
    Die sku ist in der wp_postmeta abgespeichert, unter dem meta_key _sku. Wir filtern uns die mal im phpmyadmin raus:

    _sku

    _sku

    Zur Erinnerung: in der post_meta ist über die post_id zugeordnet, zu welchem Beitrag der meta_key gehört.

  2. Preis = _regular_price
    Auch der steckt in der wp_postmeta, eben unter dem meta_key _regular_price.
  3. Kategorie = category
    Obacht! Das sind von wooCommerce eigens angelegte Produktkategorien, nicht die altbekannten Beitragskategorien von WordPress. Und hier wirds jetzt richtig lustig, die zugehörigen Daten sind nämlich über die vier Terms-Tabellen verteilt. Um herauszufinden, welche Produktkategorie zu einem Produkt gehören, muß man einen Join über mindestens drei Tabellen fahren, da sieht dann der Select ungefähr so aus:

    („SELECT Wp_term_relationships.*,Wp_terms.* FROM Wp_term_relationships

                LEFT JOIN Wp_posts  ON Wp_term_relationships.object_id = Wp_posts.ID

                LEFT JOIN Wp_term_taxonomy ON Wp_term_taxonomy.term_taxonomy_id = Wp_term_relationships.term_taxonomy_id

                LEFT JOIN Wp_terms ON Wp_terms.term_id = Wp_term_relationships.term_taxonomy_id

                WHERE post_type = ‚product‘ AND taxonomy = ‚product_cat‘

                AND  object_id = „.$aktuelleID.““)

    Und das finde ich jetzt schon weniger lustig.

Und wenn ich mal alle relevanten Daten zu meinen Produkten brauche?

Ja, dann fahren wir halt einen Join über die wp_posts, die wp_postmeta und die bekannten Terms-Tabellen. Das wird dann so richtig übersichtlich. Darf ich bei dieser Gelegenheit mal daran erinnern, wie unsere Artikelliste ursprünglich mal aussah:

artikelliste_excel

artikelliste_excel

Ach, was war das noch schön einfach und übersichtlich! Ganz ehrlich, ich finde es schon ziemlich hanebüchen, welche Bauchaufzüge man machen muß um wooCommerce die eingegebenen Produktdaten auf Datenbankebene wieder zu entlocken.

Da kommt jetzt natürlich die berechtigte Frage: wer braucht das schon? Reicht doch, wenn wir die Produkt-Daten per CSV reinjagen und in wooCommerce verwalten. Das, liebes Publikum, ist eine extra Diskussion wert. In einem neuen Artikel.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

WordPress als führendes System für die Mitgliederverwaltung? Ein Fazit

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!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Nachtrag zu Evis CSV-Importer

Euer Wunsch ist mir Befehl

Ich bin gebeten worden, die Mechanik wie man abfragt ob ein Datensatz beim Import schon vorhanden ist, doch noch mal näher zu erläutern. Also, eigentlich ist die Sache ganz einfach. Wir haben ja die Konvention, daß der Beitragstitel für einen Mitgliedsbeitrag immer mit der eindeutigen ID (mnr) beginnt, danach folgt ein Leerzeichen, danach Vorname, Leerzeichen, Nachname. Da die ID eindeutig ist, reicht es völlig aus auf einen Substring zu prüfen. der Select sieht im einfachsten Fall so aus:

$schon_da = $wpdb->get_results( "SELECT * from wp_posts 
                where post_status like 'publish'
                and SUBSTRING_INDEX( post_title,' ',1) like ".$arr_akt_zeile[0]."");

Der SUBSTRING_INDEX() holt uns alle Zeichen des Post Title vor dem ersten Leerzeichen, und das vergleichen wir mit der aktuellen Mitgliedsnummer, die im Array $arr_akt_zeile[0] steckt. Den post status checken wir noch ab, und das wars schon!

Man kann dann bequem die Anzahl der zurückgegebenen Datensätze mit num_rows abholen:

$anzahl_gefunden = $wpdb->num_rows;

Dann packt man den ganzen Programmabschnitt zur Anlage des neuen Datensatz in eine If-Abfrage, die nur ausgeführt wird wenn noch kein Datensatz mit der aktuellen ID vorhanden ist. Ich hänge mal noch eine Debug-Ausgabe in den else-Zweig, aber das reicht jetzt wirklich.

if ($anzahl_gefunden == 0) {

... neuen Beitrag anlegen und benutzerdefinierte Felder füllen...

} else {
        
        echo "Datensatz mit der ID ".$arr_akt_zeile[0]." Ist bereits vorhanden <br>";
        
    }

 

Nützlicher Helfer: Bulk Delete

Wahrscheinlich gehts euch wie mir, beim Testen hab ich -zig Beiträge neu angelegt, und die in WordPress oder im phpmyadmin einzeln wieder rauszuloschen, ist ein mühselig Spiel.Nein, da kann man lange suchen, es gibt im WordPress-Beitragseditor keine Möglichkeit „Alle Beiträge“ zu selektieren.

Dafür gibts ein praktisches Plugin: Bulk Delete erlaubt die selektive Löschung von Beiträgen etc. en masse, das kann man hier ganz gut gebrauchen. Schauts euch mal an, ist immer wieder mal nützlich!

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Andere Importer, zentrale Datenhaltung und Custom Fields

Noch mehr Testberichte?

Nein, da muß ich euch enttäuschen. Ich hab zwar noch eine ganze Latte anderer Import-Plugins ausprobiert, eine Auswahl davon findet ihr hier bei winningWP, aber so richtig begeistert war ich von keinem davon. Die mit den meisten Features sind nahezu beliebig kompliziert in der Bedienung und erfordern einen erheblichen Einarbeitungsaufwand, und die einfacheren Genossen können allesamt keine Benutzerdefinierten Felder (Custom Fields). Zumindestenst nicht die Free Editions, die kostenpflichtigen Pro-Ausgaben sollens dann schon können. Aber die, wie ich schonmal gesagt hatte, kommen bei mir nicht zum Einsatz – mir fehlt das nötige Kleingeld, und mir gehts auch ums Prinzip. Open Source, sie wissen schon.

Warum mir die Custom Fields so wichtig sind

Da muss ich ein bißchen ausholen. Ich (und einige Legionen anderer WordPress-Entwickler da draussen) stehe immer wieder vor der Herausforderung, bestehende Unternehmensdaten in WordPress integrieren zu müssen. Darüber habe ich mich in diesem Artikel kürzlich ausführlicher ausgelassen, das will ich jetzt nicht alles wiederholen. Bleiben wir bei einem einfachen Beispiel:

Der Turnverein Weiß-Blau mit dem Mitgliederverzeichnis

Gehen wir davon aus, daß beim Kickoff unseres WordPress-Projekts bereits Mitgliederdaten vorhanden sind, das ist schließlich der Normalfall.  Gehen wir weiter davon aus, daß diese Daten als Excel-Liste geführt werden. Auch das ist eher der Normalfall, und da kommen wir relativ simpel an unser CSV ran. Wir klemmen uns ein Import-Plugin, erzeugen uns für jeden Mitgliederdatensatz einen Beitrag in WordPress, schubsen unsere Mitgliedsnummer, den Vornamen und den Nachnamen in die Titelzeile und den Rest (Adresse, Email, Telefonnummer und sportliche Präferenzen) in den Post Content, und fertig.

Fertig? Nein, jetzt gehts erst los!

Der Kunde ist erfreut, man kann sich die Liste der Mitglieder sowohl auf der Blogseite als auch im Dashboard anschauen, man kann suchen, z.B. nach Namen oder nach Ort, man kann (im Beitragseditor) die kompletten Mitgliederdaten anschauen und auch ändern, und – halt, Stopp. Da haben wir jetzt einen ganz wichtigen Knackpunkt erwischt. Was ist zu tun, wenn sich Mitgliederdaten ändern? Jemand hat eine neue Telefonnummer oder ist umgezogen und die ganze Adresse ändert sich, jemand interessiert sich jetzt auch noch für Aerobic und möchte das eingetragen haben, oder -Gott bewahre! – es kommen nach dem CSV-Import noch neue Mitglieder dazu… was ist dann zu tun?

Die schwierige Entscheidung: was ist das führende System?

Diese Frage stellt sich bei nahezu jedem IT-Projekt, und wenn man das nicht frühzeitig entscheidet, kommt man in Teufels Küche. Ich habe da selbst in Großprojekten, an denen ganze Mannschaften von Programmierern monatelang schufteten, schon die tollsten Pleiten erlebt, nur weil nicht von Anfang an entschieden wurde, was denn nun de Facto das führende System ist. Dabei ist es im Prinzip ganz einfach. Man muß festlegen, wo die Datenpflege passiert. In der Praxis heißt das meistens, wo die Inserts von neuen Datensätzen und die Updates von bereits existierenden Bestandsdaten erfolgen. Im Regelfall wird das eine Tabelle sein, oder bei komplexeren Systemen auch mehrere verknüpfte Tabellen. Wenn man es richtig macht, implementiert man eine Logik die festlegt was zu tun ist wenn z.B. ein neues Mitglied im Turnverein hinzukommt, und sorgt programmtechnisch dafür, daß der neue Mitgliederdatensatz ordentlich angelegt wird, mit eindeutiger Mitgliedsnummer (ID) und allem Pipapo. Ebenso bei der Änderung von Daten eines bereits vorhandenen Mitglieds, da wird man im Regelfall den zu ändernden Datensatz anhand der Mitgliedsnummer identifizieren und updaten. Alles klar soweit? Und dann?

Jetzt kommts: alle anderen Systeme referenzieren auf das führende System

Sinn und Zweck der ganzen Übung ist natürlich der: man möchte Datenänderungen nur zentral an einer Stelle im System vornehmen und es nicht an -zig verschiedenen Stellen (Huhu SAP!) eintragen müssen, wenn sich irgendwo zum Beispiel eine Telefonnummer oder eine Bankverbindung ändert. Wenn die zentralen Daten an anderer Stelle in der IT-Architektur des Unternehmens gebraucht werden (Beispiele kommen gleich) greift man auf die zentrale Datenhaltung zu und saugt sich die entsprechenden Daten aktuell ab. Im Idealfall sorgt der Entwickler sogar für eine dynamische Verknüpfung, so daß bei einer Änderung in den Stammdaten die abhängigen Systeme in Echtzeit mitkriegen, daß was passiert ist.

Ganz einfache Beispiele

Der Vorstand unseres Turnvereins möchte gerne wissen, wie viele unserer Turnvereinsmitglieder sich für Aerobic interessieren. Früher ist man da in die Excel-Liste gegangen, hat einen Filter auf die Spalte „Aerobic“ gesetzt und abgezählt bei wie vielen Mitgliedern da ein „ja“ drinstand. Ein bißchen EDV zu Fuß, aber es hat funktioniert.

Oder die Pressereferentin möchte alle weiblichen Mitglieder anschreiben und nachfragen, ob Interesse an einem Mutter-Kind-Training besteht – ja echt, sowas ist der Renner in unserem Stadtteilzentrum! Wieder kommt unsere Excel-Liste zum Einsatz, wir filtern nach Geschlecht und holen uns nur die Spalten mit den Namen und Adressdaten heraus, und die Mailing-Aktion kann starten.

Sie sehen, auf was ich hinauswill? Nennt sich zentrale Datenhaltung, oder neudeutsch „Data Warehousing“. In unserem Fall, dem ganz konkreten Mitgliederverzeichnis des Turnvereins, stellt sich die zentrale Frage:

Was ist unser führendes System: WordPress oder Excel?

Wenn wir unsere Mitgliederdaten per CSV-Import schon so schön in Wordpess reinjongliert haben, möchte unser Kunde mit an Sicherheit grenzender Wahrscheinlichkeit jetzt auch weiterhin mit WordPress arbeiten. Neue Mitglieder hinzufügen, Bestandsdaten ändern, kleine Datenauswertungen (siehe oben) für den Vorstand, die Buchhaltung und sonst noch etliche Anwender fahren, das hatten wir ja gerade. Gehts, oder gehts nicht? Das kommt ganz schwer darauf an, und jetzt kommen wir endlich zu den Custom Fields. Es geht nämlich erstmal nicht.

Text ist Text, da beißt die Maus keinen Faden ab

So wie die meisten CSV-Importer (zumindest die Free Editions) funktionieren, landen unsere Mitgliederdaten erstmal gesammelt im Post Content. Das ist ein Longtext. Da kann man die Daten zwar anschauen oder  editieren, aber wenn man sich jetzt z.B. alle Münchner Adressen rausfischen will, steht man schon am Ende der Fahnenstange. Ja nee, man könnte mit einem „post_content like %München%“ vielleicht die meisten Datensätze erwischen, aber sauber ist das nicht. Und wenn man jetzt alle Datensätze herausholen will, die bei Aerobic ein „ja“ drinstehen haben, ist endgültig Schluß, das geht so nicht.

Jetzt endlich: Custom Fields, ihr Einsatz!

Um bei dem Beispiel mit den Münchnern zu bleiben: wenn man den Ort aus der Exceltabelle in ein Custom Field namens „ort“ importieren könnte, könnte man später einen sauberen Select über „ort = ‚München'“ fahren. Wir erinnern uns nochmal kurz an die Logik der Custom Fields:

Ich habe z.B. ein neues Benutzerdefiniertes Feld „Preis“ mit dem Wert 12,80 angelegt. In der Tabelle wp_postmeta landet ein neuer Eintrag mit einer laufenden meta_id:

post_meta_custom_field

post_meta_custom_field

Hier wird über die post_id der Name (meta_key) und der Wert (meta_value) des benutzerdefinierten Feldes festgehalten.

Ich hätte also für unseren Ort den meta_key „ort“ und bei jedem Datensatz (erkenntlich an der post_id) entsprechend den meta_value „München“ oder eben einen anderen Ort. Da geht im Schnellschuss mal ein Join der wp_posts auf die wp_postmeta, das könnte etwa so aussehen:

Select * fom wp_posts left join wp_postmeta on wp_posts.ID = wp_postmeta.post_id 
where  wp_postmeta.meta_key = "ort" and wp_postmeta.meta_value = "München"

Damit hätte man zumindest mal sauber alle Münchner herausgefiltert. Auch wenn ich die WordPress-Puristen hier schon maulen höre: dafür gibts doch vordefinierte Funktionen, get_post_meta() zum Beispiel! Ja, ich weiß. Aber Hier gehts ums Prinzip, nämlich der programmtechnischen Auswertbarkeit von in WordPress enthaltenen Daten.

Die schlechte Nachricht: wie sieht der Select bei mehreren Custom Fields aus?

Da wirds ein bißchen unübersichtlich. Mit der eben beschriebenen Merthode müßte man tatsächlich für jedes weitere Custom Field einen weiteren Join hinzufügen, ich hab mir da mal ein Beispiel mit vier Feldern bei stackoverflow ausgeliehen:

SELECT wp_posts.ID, wp_posts.post_title, wp_posts.whatever,
            color.meta_value        AS color,
            transmission.meta_value AS transmission,
            model.meta_value        AS model,
            brand.meta_value        AS brand
       FROM wp_posts

  LEFT JOIN wp_postmeta  AS color 
         ON wp_posts.ID = color.post_id        AND color.meta_key='color'

  LEFT JOIN wp_postmeta  AS transmission
         ON wp_posts.ID = transmission.post_id AND transmission.meta_key='transmission'

  LEFT JOIN wp_postmeta  AS model
         ON wp_posts.ID = model.post_id        AND model.meta_key='model'

  LEFT JOIN wp_postmeta  AS  brand
         ON wp_posts.ID = brand.post_id        AND brand.meta_key='brand'

      WHERE wp_posts.post_status = 'publish'
        AND wp_posts.post_type = 'car'
   ORDER BY wp_posts.post_title

Beeindruckend, nicht wahr? Aber nicht wirklich schön. Der ganze Heckmeck ist nötig, weil die Tabelle wp_postmeta eine sogenannte Pivot-Struktur (Excel-Fexe kennen das) für die Custom Fields einsetzt, und dafür gibts in MySQL keine einfachere Auswertelogik. Hier ebenfalls bei Stackoverflow ist ein interessanter Beitrag mit einem anderen Lösungsansatz, aber das führt mir jetzt wirklich zu weit, und ausserdem ist dieser Beitrag schon lang genug. Ich hoffe, dass ich einigermassen klarmachen konnte, warum ich den Datenimport in Custom Fields für unbedingt notwendig halte, und werde mich im nächsten Beitrag darum kümmern, die Custom Fields auch angezeigt zu bekommen. Wollen doch mal sehen, wie sich WordPress als führendes System so anlässt.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Ein Dirty Trick: wir holen uns die wp-load.php

Wo ist unser wpdb-Objekt geblieben?

In unserer „nackten“ PHP-Datei steht es nämlich erstmal nicht zur Verfügung. Um jetzt aber trotzdem ranzukommen – wir wollen ja schließlich wieder mit $wpdb->get_results und all den praktischen Helferlein arbeiten – gibt es eine einfache, wenn auch unter WordPress-Puristen umstrittene Methode. Man holt sich mithilfe einer require()-Anweisung die Datei wp-load.php ins Boot, und schon kann man die WordPress-Funktionalitäten wieder nutzen. Wo diese Datei liegt, ist abhängig von der jeweiligen WordPress-Installation, normalerweise steckt sie im Stammverzeichnis, da wo auch wp-config.php und Konsorten zu finden sind. Falls sie also da zu finden ist, kann man sich so behelfen:

require(‚../../../wp-load.php‘);

Das ist natürlich nicht besonders Foolproof und fällt auf die Nase, wenn die Datei woanders liegen sollte.

Sauberere Methode – wenn auch etwas kryptisch

Eigentlich hasse ich es ja, Code zu verwenden, den ich nicht ganz verstehe. Aber hier mache ich mal eine Ausnahme, es funktioniert nämlich einwandfrei. Das Code Snippet stammt von Frankie Jarrets Seite, und dort kann man auch nachlesen warum man es so NICHT machen sollte…

Statt dem wie oben codierten absoluten Pfad kann man nach Frankie folgende Lösung verwenden:

$parse_uri = explode( ‚wp-content‘, $_SERVER[‚SCRIPT_FILENAME‘] );
require_once( $parse_uri[0] . ‚wp-load.php‚ );

Wie dem auch sei, wir holen uns halt unsere wp-load.php, auch wenn die Puristen Zetermordio schreien. Für unser kleines Adresseneditor-Plugin tuts diese Lösung wirklich, da werden wir keine Probleme mit Serverlast Verdopplung etc. zu erwarten haben.

Hurra, das wpdb-Objekt ist wieder da!

Und deshalb können wir den Code aus unserem ersten Adresseneditor-Plugin (fast) unverändert übernehmen. Die ID für den aktuellen Datensatz haben wir ja schon, die steckt in:

$akt_id = $_POST[„id“];

ganz am Anfang der Datei edit-adresse.php und kommt aus unserem aufrufenden Formular.

Der Select

… ist jetzt wie gehabt:

global $wpdb;
        $alleposts = $wpdb->get_results( „SELECT * from „.MAINTABLE.“ where ID = „.$akt_id.““);
      

Kleiner Negertrick in der Foreach-Schleife

Wenn wir den Foreach auch ungeändert übernehmen, kommt es nach dem Editieren des Datensatzes und Drücken des „Änderungen speichern“-Buttons zu einem unerwünschten Effekt: die Formularfelder werden auf die ursprünglichen Werte zurückgesetzt. Das führt natürlich zu heftiger Verwirrung beim Anwender, weil seine Änderungen plötzlich verschwunden sind. Dabei sind sie doch schon in der Datenbank gespeichert! Ich mach da mal kurzen Prozess und unterbinde die Anzeige des Formulars, wenn auf den „Änderungen speichern“-Button gedrückt wurde, dann siehts sauberer und für den Anwender besser logisch verständlich aus. Dazu binde ich eine IF-Abfrage mit ein, hier unten fett hervorgehoben:

foreach ( $alleposts as $einpost ) {     
    
//Begin Formular
echo ‚<form method=“post“>‘;

        if (!isset($_POST[’speichern‘])){
            echo „<div style = ‚border: 3px solid blue; padding: 10px; display: inline-block‘>“;
        echo ‚ID: &nbsp‘.$einpost->id.'<input type=“text“ name=“id“ value = „‚.$einpost->id.'“ hidden/></br>‘;
        echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“/></br>‘;
        echo ‚Nachname: <input type=“text“ name=“nachname“ value = „‚.$einpost->nachname.'“></br>‘;
       
        echo ‚<input type=“submit“ name = „speichern“ value=“Änderungen speichern“/>‘.“<br>“;
        } //end von nicht isset
        echo „</div>“;
        
echo ‚</form>‘;
// End Formular
    
} //end foreach

Damit verschwindet das Formular, sobald auf den „Änderungen speichern“-Button geklickt wurde.

Der Update wie gehabt

An der Update-Logik ändert sich auch nicht das Geringste, die übernehmen wie 1:1.

Zurück zur Adressenliste

Jetzt fehlt noch ein Link zurück zur Adressenliste, und auch das mach ich kurz und schmerzlos mit der URL der ersten Seite des Plugins:

echo „<a href = ‚http://localhost/turnverein/wp-admin/admin.php?page=adressen-tabelle’/><h1>Zurück zur Adressenliste</h1></a>“;

Sie müssen hier natürlich ihre eigene URL einsetzen, aber das sollte ja nun wirklich kein Problem sein. Funktionierts? Nach dem Klick auf  „Zurück zur Adressenliste“ sollte jetzt natürlich wieder unsere Adressentabelle auftauchen, mit den eben gemachten Änderungen.

Funktioniert – aber wie sieht denn das aus? Nacktes PHP!

Gemach, gemach, hier ging es um die Funktionalität. Zugegeben, besonders schön ist das nicht mit dem „weissen“ Unterformular ohne die gewohnte WordPress-Umgebung, aber das zu ändern ist nicht wirklich einfach, da bin ich noch am Forschen. Die Lösung könnte evtl. in diesem Artikel stecken oder auch hier, aber da bin ich noch nicht ganz durch. Ich halte euch auf dem Laufenden, wenn da mal eine Lösung in Sicht kommt.

 

 

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Datenbankeditor die Letzte: Source als ZIP und Ausblick

Der Datenbankeditor kann jetzt marschieren

Das war jetzt (fast) reines HTML/PHP, und man kann das Prinzip des Datenbankeditors ja auch auf MySQL-Tabellen ausserhalb von WordPress anwenden, dann gehts halt nicht mit der $wpdb->update Methode, sondern mit einem pdo und einem Prepared Statement. Das hat jetzt aber wirklich gar nichts mehr mit WordPress zu tun, da schenke ich mir jetzt eine längere Erklärung und verweise für den Update in PHP auf diesen Artikel . Lieber gebe ich hier noch einen kleinen Ausblick.

Editor für alle Fälle, für jede eigene Tabelle

Jedenfalls habe ich hoffentlich verständlich dargestellt, wie man in WordPress Datensätze aus beliebigen MYSQL-Tabellen anzeigen, editieren und wieder wegschreiben kann. Diese Funktionalität ist immer wieder mal gefragt, besonders wenn man mit eigenen Tabellen arbeitet, für die hat man ja in WordPress erstmal kein Benutzerinterface. Ich habs jetzt mal als Plugin gezeigt, das nur der Admin bedienen darf. Wenn sie einen Tabelleneditor für die Benutzerseite anlegen wollen, packen sie die Funktionalität in einen Shortdode, geht genauso.

Man könnte jetzt noch ehrgeizig werden und zum Beispiel statt der manuellen Eingabe der ID (in unserem Fall der Mitgliedsnummer) auch die Auswahl aus einer Liste anbieten wollen, oder man könnte eine Liste aller Mitglieder ausgeben und nach jedem Datensatz einen „Ändern“-Button anzeigen, der dann  in den Datenbankeditor springt, oder oder oder… aber da gehts echt verschärft nach PHP, das darf sich jeder selber austüfteln.

Jetzt gibts noch wie versprochen hier das Plugin adressen-editor als ZIP-Datei, und damit lassen wir es gut sein. Viel Spaß beim Anpassen an ihre eigenen Tabellen!

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Datenbankeditor die Dritte: Formular im Formular

Editierbare Felder – bloß wie?

Wir waren dabei stehengeblieben, daß wir die Adressdaten zu einer vom Benutzer eingegebenen Mitgliedsnummer angezeigt haben. Jetzt gehts zum nächsten Schritt, wir wollen die Daten ja nicht nur anzeigen, sondern auch ändern. Dafür nehmen wir – ein Formular! Und zwar innerhalb unserer Foreach-Schleife, wir wollen ja genau den Inhalt des einen von unserem Select zurückgegebenen Datensatzes ausgeben.

Das Unterformular in der Foreach-Schleife

Das ist keine Hexerei, sondern ein stinknormales Formular mit einem Submit-Button. Die Konstruktion beginnt so:

foreach ( $alleposts as $einpost ) {     
    
//Begin Formular
echo „<form method=“post“>“;

//Hier kommen die Formularfelder hin       
        
echo ‚<input type=“submit“ name = „speichern“ value=“Änderungen speichern“/>‘.“<br>“;

echo „</form>“;
// End Formular

} //end foreach

Werte (values) der Input-Felder vorbelegen

Wir nehmen ganz normale Text-Inputfelder, und jetzt kommt der Witz an der ganzen Sache: sie werden mit unseren Feldinhalten aus der Datenbank gefüllt. Das geht ganz einfach, wir sind ja innerhalb der Foreach-Schleife und kommen z.B. mit $einpost->vorname an den Wert des Vornamen-Feldes ran. Das editierbare Formularfeld für den Vornamen mit Vorbelegung sieht dann so aus:

echo ‚Vorname: <input type=“text“ name=“vorname“ value = „‚.$einpost->vorname.'“></br>‘;

Hier muss man mit den doppelten und den einfachen Anführungszeichen ein bißchen aufpassen, aber ich pack euch nachher den Code noch in ein ZIP-File, dann habt ihrs ganz genau. Falls die Ausgabe eines Values beim ersten Leerzeichen abgeschnitten wird, stimmt was mit den Anführungszeichen nicht, darüber fällt man am Anfang gerne.

Das Feld für die ID (Mitgliedsnummer) kriegt eine Sonderbehandlung, das soll ja um Himmels Willen nicht geändert werden, auch nicht versehentlich, deswegen setzen wir es gleich auf disabled:

echo ‚ID: <input type=“text“ name=“id“ value = „‚.$einpost->id.'“ disabled></br>‘;

Die anderen Felder (Nachname, Telefon, Ort usw.) werden ganz genau so wie oben beim Vornamen konstruiert, so sieht das fertige Produkt dann aus:

unterformular_screenshot

unterformular_screenshot

Ich hab noch einen <div> mit einem Rahmen um die ganze Sache gelegt und die Felder für E-Mail und Strasse mit size=“50″ grösser gemacht, aber das wars dann schon. Eure Bildschirmanzeige nach Abschicken der Mitgliedsnummer sollte jetzt etwa so aussehen:

 

unterformular_anzeige

unterformular_anzeige

Sieht doch schon mal ganz gut aus, oder? Jetzt müßte nur noch etwas passieren, wenn man auf „Änderungen speichern“ klickt, aber dazu gibts einen neuen Beitrag.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend