Archiv der Kategorie: woocommerce

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…

Ein CMS muss sowas können: Datenimport auch en masse

Am Anfang war der Blog

Wenn man sich die alte Dame WordPress unter dem Aspekt CMS mal genau anguckt, schauen unter jedem Rockzipfel noch die Anfänge heraus. WordPress ist nunmal dafür konzipiert worden, daß auch Otto Normalblogger auf einfache und leicht erlernbare Weise seine Beiträge im Web veröffentlichen kann, auf daß sie von möglichst vielen Besuchern gelesen, kommentiert und diskutiert werden können. Das sieht man besonders an der zentralen Tabelle wp_posts, wo die meisten Felder unmittelbar mit Eigenschaften zu tun haben, wie sie ein typischer Blogbeitrag nun mal hat. Author, Erscheinungsdatum, Titel, Inhalt, Excerpt, Datum der letzten Änderung, Anzahl Kommentare usw., all das stammt noch aus den Zeiten, als sich unzählige von frischgebackenen Bloggern auf das geniale WordPress stürzten und sich damit mehr oder weniger erfolgreich im Internet darstellten. Auch die ausgefeilte Verwaltung von Kommentaren und Kategorien mit ihren diversen Verschachtelungsmöglichkeiten stammt noch aus der ursprünglichen Konzeption als Blogsoftware.

Weils so schön einfach ist: Webseiten auch mit kleinem Budget

Da es mit WordPress genauso einfach ist, statische Seiten zu erstellen wie sagen wir mal einen neuen Blogbeitrag zu schreiben, hat es sich sehr schnell zur mit grossem Abstand beliebtesten Software für kleine und mittlere Webauftritte entwickelte. Laut dieser Studie von upload magazine  beherrscht WordPress aktuell (Stand März 2017) 58,9 Prozent des CMS-Marktes. Das hat natürlich den Hauptgrund, daß WordPress Open Source und kostenlos ist, und durch unzählige Plugins erweiterbar. Die oft gestellte Frage, ob WordPress auch wirklich ein vollwertiges CMS ist, wird hiermit akademisch. Es wird als CMS millionenfach verwendet, da schaffen die Fakten die Antwort. Eigentlich ist die Frage ja auch unsinnig, denn wenn man Tante Google mal bemüht, ist die Antwort auf „Was ist ein cms?“ schlicht und ergreifend:

Ein Content Management System (kurz CMS) ist eine Software, die zur Erstellung und Verwaltung von Inhalten – in Text-, Bild-, Video- oder sonstiger Form – verwendet wird. CMS werden vor allem zum Betreiben von Websites, aber auch für „Offline-Plattformen“ (in Intranetzwerken) eingesetzt.

Alles klar? Natürlich ist WordPress ein CMS. Die Frage ist nur: wie gut?

CMS für Fortgeschrittene: wer brauchts nicht?

Ich geh mal von ein paar einfachen Anwendungsbeispielen aus. Wenn nur eine „Visitenkarte“ im Web gebraucht wird, etwa für einen Arzt, einen Anwalt, einen Steuerberater, eine Werkstatt oder einen kleinen Laden, da muß man nicht mit Kanonen auf Spatzen schießen. Eine Startseite mit Informationen „Über uns“, Eine Seite „Unser Angebot“, Öffnungszeiten und Anfahrtskizze, ein Kontaktformular, vielleicht noch eine Seite für „Termine/Aktuelles“ (hier kommt die Blogfunktionalität zum Einsatz), AGBs und Impressum, das war’s in ganz vielen Fällen schon.

Dafür ist WordPress ganz ideal, so eine Webseite kann schnell und unkompliziert erstellt werden und innerhalb weniger Tage fertig sein. Der Pflegeaufwand hält sich auch meistens in Grenzen, ein Steuerberater möchte vielleicht einmal im Monat ein Mandantenrundschreiben mit aktuellen Steuerinformationen als PDF zum Download anbieten, ein Restaurant hat eine Wochenkarte oder ein aktuelles Tagesgericht, Urlaubstermine oder aktuelle Sonderangebote gehören eingepflegt, das wars dann meistens schon. Hier ist kein weiteres technisches Brimborium nötig, da macht man einen kleinen Wartungsvertrag und pflegt die Änderungen im Einzelfall manuell ein, ist ja kein Aufwand.

Für wen reicht das nicht?

Das ist gar nicht so einfach zu beantworten. Ich fang mal so an: in jedem (und sei es auch noch so kleinen) Unternehmen gibt es Listen. Preislisten, Kunden- und Lieferantenadressen, Kassenbuch, Lagerbestände, Terminkalender, Artikelstammdaten usw usf… und alle alten Programmierer lieben Listen! Ob diese jetzt in Excel (der Otto-Normalfall), Access (hach, schön wenn’s so ist), einem kleinen oder großen ERP/CRM oder auch nur auf Papier geführt werden, die Unternehmensdaten sind da, sie leben und werden gepflegt und sind immens wichtig für den Bestand des Ladens.

Wenn man jetzt nur sowas wie die Wochenkarte eines Restaurants oder die Preisliste eines Friseurs auf die Webseite bringen will, muß man da auch nicht lange rummachen, das geht mit copy&paste auf eine statische Seite, oder (etwas vornehmer) als hübsch formatiertes PDF zum Download. Aber schon mit den Artikelstammdaten einer Metzgerei oder eines Lebensmittelgeschäfts steht man da ganz schnell am Ende der Fahnenstange. Schon bei ein paar hundert Artikeln im Tante-Emma-Laden wird die Sache sehr schnell unübersichtlich.

Die Antwort in vielen Fällen: ein Online-Shop muss her!

Und da landet man unweigerlich ganz schnell bei woocommerce, dem verbreitetsten Shopsystem-Plugin für WordPress. Es ist auf den ersten Blick recht übersichtlich, wie man ein Produkt mit den entsprechenden Daten anlegt ist recht schnell gelernt, es gibt -zig Anleitungen und Hilfeseiten bei Tante Google zu finden. Bevor sie jetzt aber vor lauter Begeisterung anfangen, ihre Wurstsorten und Fleischspezialitäten da manuell einzuhacken, ziehen wir die Notbremse. Das geht auch einfacher!

Der Knackpunkt: die Import-Funktionalität

Und das gilt nicht nur für den Online-Shop, das gilt überall, wo sie Listen mit Unternehmensdaten ins Web bringen wollen. Es ist einfach nicht zumutbar, hunderte oder tausende von Datensätzen manuell zu erfassen, das ist rausgeschmissene Arbeit und viel zu aufwendig und fehlerträchtig. Wir alten Programmierer sind alle Experten darin, existierende Unternehmensdaten, in welcher Form sie auch immer vorliegen mögen, weiterzuverarbeiten und in den meisten Fällen in unsere Datenbank zu schubsen, damit wir schön mit ihnen jonglieren können. Wie das mit WordPress funktionieren kann, darüber gibts einen neuen Artikel, der hier ist lang genug. Aber ich hoffe es ist klargeworden, warum Datenimport so eine wichtige Sache ist.

Da staunste Bauklötze: vielleicht serialized, vielleicht nicht

Wenns klemmt im Datenkorsett

Ich habe mich schon an anderer Stelle darüber ausgelassen, daß das Datenmodell von WordPress alles andere als relational wohlstrukturiert und insgesamt renovierungsbedürftig ist.  Wenn  man sich ein bißchen mit multifunktionalen Plugins wie z.B. woocommerce beschäftigt, stellt man immer wieder fest, daß Entitäten in die vorhandenen WordPress-Tabellen gequetscht werden, die eigentlich nicht wirklich hineinpassen. Um beim Beispiel woocommerce zu bleiben, weil das ja doch sehr verbreitet und gut dokumentiert ist: da werden die zu verkaufenden Produkte in der Tabelle wp_posts wie Beiträge angelegt, und was man hier an Produkteigenschaften und benutzerdefinierten Feldern nicht mehr untergebracht hat, landet in der wp_options, der wp_postmeta oder in der wp_terms und ihren Verwandten. Damit man hier auch alles unterbringt, obs jetzt logisch paßt oder nicht, kommt ein tolles Konstrukt zum Einsatz (übrigens nicht nur in WordPress, das gibts auch anderswo):

Serialized Data

Was ist das? Wenn sie einen Datenbankeintrag finden , der so aussieht:

a:1:{s:14:“pa_code“;a:6:{s:4:“name“;s:14:“pa_code“;s:5:“value“;s:0:““;s:8:“position“;i:0;s:10:“is_visible“;i:1;s:12:“is_variation“;i:0;s:11:“is_taxonomy“;i:1;}}

Das sind serialisierte Daten. Es handelt sich hier um ein Produktattribut namens „code“, das in dieser besonders verklausulierten Form abgelegt wurde. Wer genauer wissen möchte, was serialisierte Daten sind, kann hier im PHP-Manual mal nachlesen, und mir ganz ehrlich sagen wenn er auch nur die Hälfte verstanden hat. Soweit ich es kapiert habe, erlaubt es die Serialisierung, in einem einzigen Datenbankfeld mehrere Variable unterschiedlicher Datentypen zu speichern.  In einem Array, mit Hilfe eines Objekts. Aber, ich gebe wie gesagt ehrlich zu ich hab nicht genau verstanden, wie das wirklich funktioniert. Da schwirrt es in den Manuals nur so von Objekten und Klassen und Methoden, und mir fehlt echt die Geduld (und der Hang zur Verkomplizierung) mich da weiter einzulesen. Ich habs versucht, und bin dabei unter anderem auf einen besonderen Leckerbissen gestossen:

Eine Funktion namens maybe_serialize()

Allen Ernstes. Laut Codex macht die Folgendes: sie serialisiert Daten, falls nötig. Ich muß da unbedingt mal wörtlich zitieren:

Confusingly, strings that contain already serialized values are serialized again, resulting in a nested serialization. Other strings are unmodified.

Ach nee, „confusingly“, also verwirrenderweise? Da brat mir doch einer einen Storch! Und wie kriegt man die Daten da wieder raus? Gute Frage. Es gibt tatsächlich auch eine Funktion namens maybe_unserialize(), ist das nicht schön? Irgendwas muß man damit doch anfangen können… meine Recherchen haben aber noch nicht ergeben, was man sinnvollerweise damit macht.

Wofür soll das alles gut sein?

Der Knackpunkt ist: hier werden buntgemischte Daten in ein einziges Tabellenfeld geklemmt, statt sie sauber nach Datentypen getrennt in einer passenden Tabelle zu speichern. Damit bringt man mehr Informationen als vorgesehen in einer bereits vorhandenen Tabelle unter, aber das Auslesen und Weiterverarbeiten wird beliebig kompliziert und erstmal sehr verwirrend und umständlich. Und mal ganz im Ernst: eine Funktion, die „maybe“ irgendwas macht, die kann ich nicht gebrauchen. Das sind Stilblüten der objektorientierten Programmierung, die allem widersprechen, was ich über Datenmodellierung und Tabellenstrukturierung je gelernt habe.

Um beim Beispiel woocommerce zu bleiben: das Plugin gönnt sich ja ohnehin ein gutes Dutzend eigener Tabellen. Warum legt man dann für die Produktattribute nicht auch eine eigene Tabelle an, in der die nötigen Daten in lesbarer und vor allem auch per SQL auswertbarer Form gespeichert werden? Kostet auch nicht mehr, und wäre unendlich benutzerfreundlicher. Den Mumpitz mit den vielleicht oder auch nicht serialisierten Daten könnte man sich dann echt sparen.