Archiv für den Monat: August 2017

Wir basteln uns einen kleinen Schmuckladen

Da ich mit konkreten Beispielen immer am Besten arbeite, basteln wir uns jetzt einen kleinen Online-Shop für meinen Glasperlenschmuck. Da haben wir übersichtliche Produktdaten und eine hübsche Fotoauswahl. Ich habe das Theme Twentysixteen genommen und mir gleich mal ein Child Theme erstellt, das brauchen wir bestimmt noch. Jetzt noch schnell wooCommerce installiert, und es kann losgehen.

Der erste Eindruck: sie sehen, daß sie nichts sehen

Woo legt uns ein paar neue Seiten an (näheres später) und stellt uns den Shop als Startseite ein. Da wir noch keine Waren in unserem Shop haben, sieht das Ganze erstmal ziemlich leer aus.

shop_leer

shop_leer

Ein kurzer Blick auf die Datenbank

Ach du liebes Lieschen, wie sieht dann das aus! Woo hat sage und schreibe 14 neue Tabellen erstellt!

woo_tabellen

woo_tabellen

Immer mit der Ruhe, die nehmen wir uns der Reihe nach vor, wie wir sie brauchen. Und ich kann ihnen gleich zur Beruhigung sagen: die meisten davon brauchen wir erstmal noch gar nicht. Ein wenig Geduld, wir machen schon noch ein bißchen Spaß auf der Datenbank. Jetzt füllen wir erstmal unseren Shop mit Leben.

Produkte hinzufügen

Woo beschert uns zwei neue Menüpunkte im Dashboard, „WooCommerce“ und „Produkte“.

woo_menus

woo_menus

Wir nehmen eine Abkürzung und gehen gleich mal auf „Produkt hinzufügen“, alles andere später. Der Produkteditor ist recht übersichtlich, das ist nix anderes als eine Variante des gewohnten Beitragseditors. Wir fügen jetzt mal ein paar Produkte hinzu, damit unser Shop lebendiger wird. Wir haben pro Produkt fünf Attribute, die wir in unseren Shop einpflegen wollen:

  • den Produktnamen
  • die Kategorie
  • die Beschreibung
  • Angaben zur Größe
  • den Preis

Das Produktfoto muß auch noch rein, aber das wars. Ich verteile meine Produktdaten wie folgt:

  1. Produktname in den Titel
  2. Beschreibung in den Text
  3. Preis in das Feld „regulärer Preis“

Und dann noch die Größenangabe… tscha, und da hakts schon zum ersten mal. Sollen wir dafür ein Benutzerdefiniertes Feld anlegen? Lieber nicht. Weiter unten gibt es noch ein Textfeld „Produkt Kurzbeschreibung“, das nehmen wir, das sieht freundlich aus.

produkt_kurzbeschreibung

produkt_kurzbeschreibung

Für die Produktkategorien gibt es rechts ein „Produktkategorien“-Untermenü, das nehmen wir natürlich auch gleich noch mit. Ich trage mal gleich ein paar Kategorien ein, die werden wir ja später noch brauchen… aber Obacht! Nichts verwechseln, das sind jetzt woo-eigene Kategorien, die nichts mit den gewohnten Beitragskategorien zu tun haben. Da lauert Verwechslungsgefahr, das muß man unterscheiden. Aber ich trag mal trotzdem hier was ein:

produkt_kategorien

produkt_kategorien

So, fehlt noch das Foto, das kommt rechts bei „Produktbild“ rein, die Produktgalerie lassen wir jetzt noch aussen vor. Alles drin? Dann werfen wir jetzt mal einen Blick auf unseren Shop.

Shop mit einem Produkt

Das sieht doch schon mal ganz nett aus.ein_produkt

ein_produkt

Wenn man auf das Produktbild draufklickt, kommt man in die Einzelansicht, hier werden auch die restlichen Daten zum Produkt angezeigt, und hier kann man das Produkt in gewünschter Stückzahl in den Warenkorb packen, oder auch eine Produktbewertung abgeben.

einzelansicht

einzelansicht

Momentchen noch: in meinem Schmuckladen gibt es nur Unikate, das heißt jedes Produkt ist genau einmal vorhanden. Da dürfte beim Warenkorb genau genommen keine Stückzahl > 1 angegeben werden – aber ja, ich hörs schon, sie haben recht, das sind Feinheiten, um die kümmern wir uns später.

Das reicht uns jetzt mal fürs erste, geben sie mal zwei, drei Produkte ein, und wenn sie das haben gehts weiter. In einem neuen Beitrag.

 

 

 

 

Das bekannteste eCommerce-Plugin: wooCommerce unter der Lupe

Warum WooCommerce so beliebt ist

Wer einen Online-Shop mit WordPress betreiben will, wird sich in den meisten Fällen erstmal für wooCommerce entscheiden. Erstens ist es kostenlos und trotzdem praxistauglich, zweitens reich an Features und nahezu unbegrenzt erweiterbar, und drittens gibt es hervorragenden (ebenfalls kostenlosen) Support dafür. Mit bis dato ca. 15 Millionen Downloads (schlag nach bei Wiki) eine echte OpenSource-Perle – möchte man meinen. Ich hab dazu eine eigene Meinung. Wir werden uns im Folgenden aus der zugegeben nicht unparteiischen Sicht einer alten Datenbankerin näher mit WooCommerce befassen, und ich denke ich werde im Verlauf dieses neuen Themas schon ein bißchen klar machen können, wo es meiner Meinung nach hakt.

WooCommerce: Pfusch auf der Datenbank?

Ja. Zwar auf sehr hohem Niveau, aber Pfusch bleibt Pfusch. WooCommerce klemmt sich nunmal ins enge, überalterte Datenkorsett von Madame WordPress, und da gibt es abenteuerliche Konstrukte – aber dazu später mehr. Seid ihr bereit für eine Achterbahnfahrt auf der Datenbank? Dann mal los, zieht euch eine neue WordPress-Instanz auf und installiert euch WooCommerce zum Testen, da ist nichts weiter dabei. Morgen gehts dann los – ich habe euch wieder ein bißchen Spaß auf Datenbank versprochen, aber ich kann nicht garantieren daß es nicht an manchen Stellen zur Kuriositätensammlung mutiert…

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!