Archiv der Kategorie: woocommerce

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

Déja vu im Online-Shop: wollen wir das wirklich alles per Hand eingeben?

… natürlich nicht. Wie sie wahrscheinlich beim Erstellen der Test-Produkte gemerkt haben, hält das Prozedere ganz schön auf, und mehr als eine Handvoll Produkte per Hand in unseren nagelneuen Online-Shop einzupflegen ist eigentlich in der Praxis nicht zumutbar. Das dauert viel zu lang und ist auch ungeheuer fehleranfällig, das kann man keinem Kunden zumuten. Aber keine Bange, es ist Abhilfe in Sicht.

Produktliste – haben wir sehr wahrscheinlich schon

In jeder noch so kleinen Klitsche gibt es in irgendeiner Form eine Liste der Produkte für den Verkauf, dafür lege ich meine Hand ins Feuer. Das kann ein Word- oder Excel-Dokument sein, oder (im Idealfall) vielleicht sogar ein kleines Datenbankerl mit OpenOffice oder Access.

Jedenfalls haben wir mit an Sicherheit grenzender Wahrscheinlichkeit schon eine Liste unserer Verkaufsprodukte, und wahrscheinlich haben wir sogar schon einen Primärschlüssel, nämlich eine eindeutige Artikelnummer. In meinem Schmuckladen gibt es die allerdings tatsächlich nicht, da sind die Produkte nur über den (hoffentlich einmaligen) Namen eindeutig identifizierbar. Aber im Normalfall haben wir einen eindeutigen Identifikator, das kann eine EAN sein, oder eine fortlaufende Nummer, oder eine Kombination aus Zahlen und Buchstaben.

Liste? CSV, Import!

Genau! Wenn wir schon eine Produktliste haben, die wollen wir doch dem wooCommerce direkt einfüttern und uns einen Haufen Handarbeit sparen. Also dann, frisch ans Werk! Ich hab mir mal eine kleine Produktliste in Excel erstellt, die sieht so aus:

artikelliste_excel

artikelliste_excel

Wie kriegen wir die jetzt ins wooCommerce? Genau! Dafür gibt es Plugins! Zum Beispiel den

Woocommerce CSV importer v

Den installieren wir uns, und dann wird ausprobiert. Ich mach hier mal kurzen Prozess und beschreibe kurz, wie der Importer funktioniert.

  1. Man erstellt eine Header-Datei, das ist nichts anderes als ein CSV, das als einzige Zeile die Feldnamen mit Trennzeichen enthält. Das sieht so aus:

    header

    header

  2. Man erstellt sich die dazu passende Artikelliste als CSV

    schmuck_csv

    schmuck_csv

  3. Man wählt in den CSV Import Settings das richtige Trennzeichen (field seperator), wir haben ein „;“ (Semikolon)

Und dann kanns losgehen. Header laden, Feldzuordungen vornehmen, CSV-Artikelliste laden… aber mal langsam mit den jungen Pferden.

Die Feldzuordnungen beim CSV-Import: bin ich Hellseher?

Man kriegt hier in einer hübschen Dropdown-Liste die Feldnamen in WordPress/wooCommerce angezeigt, und kann hier entsprechen die Zuordnungen vornehmen. Dazu muß man alllerdings wissen, welches Feld in der Dropdownliste welchem Feld in der Artikelliste in unserer CSV-Datei entspricht.

header_feldzuordnung

header_feldzuordnung

Geht schon ganz oben los: das Feld „sku“ ist für die Artikelnummer vorgesehen, aber das muß man erstmal wissen. Jetzt wäre es halt verdammt nützlich, wenn man wüßte wie wooCommerce was in der Datenbank abspeichert, und das ist leider nicht unbedingt selbsterklärend. Das ist sogar ein kleiner Trip ins Datenchaos, aber dazu gibt es dann später einen neuen Beitrag.

Ich sag hier nur mal kurz, wie man unsere paar Import-Felder sinnvoll zuordnet. Die Logik ist wie folgt:

  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

Alles klar? Damit dürfte dem erfolgreichen Import nichts mehr im Wege stehen. Man bekommt sehr schön eine Preview angezeigt, und wenn die hinhaut, können wir die CSV-Datei laden.

import_preview

import_preview

Presto! Unsere neuen Artikel sind drin und auch gleich im Shop zu sehen.

neue_artikel

neue_artikel

Allerdings ohne Bilder. Und mit Duplikaten, weil es manche Artikel vorher schon gab, per Hand eingeklopft. Aber wer wird denn da kniefieselig sein? Ich schon. Die Duplikate kann man noch per Hand löschen, das waren nicht so viele. Und was ist mit den Bildern?

Plugins für den Bilder-Import: kosten Kohle

Es gibt unzählige Import-Plugins für wooCommerce, viele davon OpenSource und kostenlos. Ich hab allerdings noch kein freies Plugin gefunden, das auch Produktbilder importieren kann, und ich kaufe prinzipiell keine kostenpflichtigen Plugins. Sorry Freunde, aber hier ist das Ende der Fahnenstange.

Aber jetzt wirds Zeit uns mal drum zu kümmern, was wooCommerce auf der Datenbank macht, und dazu gibt es einen neuen Artikel.

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

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.

 

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

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…

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

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.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

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.

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend