Archiv der Kategorie: WordPress

Beitragskategorien aus der Datenbank abfassen

Für Spitzenklöppler: das WordPress-Kategorienmodell

Um an die Beitragskategorien heranzukommen, muss man sich mit sage und schreibe 5 Tabellen herumschlagen. Das kommt daher, weil die WordPress-Entwickler das Kategorienmodell unbedingt mehrstufig anlegen mussten. Das ist zwar wunderbar verschachtelbar und ergibt ganz eindrucksvolle Baumstrukturen, aber datenverarbeitungstechnisch ist es meiner Meinung nach mit Kanonen auf Spatzen geschossen. Mit einer winzigen Ausnahme (die Backrezepte im Inselfisch-Kochbuch) habe ich noch in keinem meiner Blogs eine Unterkategorien-Ebene gebraucht, und damit das hier nicht allzu unübersichtlich wird, lasse ich es auch bei der einen Ebene. Haben sie ein bißchen Zeit? dann wollen wir mal.

Die relevanten Tabellen

Erstens natürlich die wp_posts, aus der holen wir uns die ID, also den Primärschlüssel der Beiträge. Dann brauchen wir noch:

  • wp_term_relationships
  • wp_term_taxonomy
  • wp_terms
  • (wp_termmeta, nein, die brauchen wir nicht, nur der Vollständigkeit halber erwähnt)

Warum das ganze mit Term und nicht mit Category bezeichnet ist: rein theoretisch kann man sich auch noch eigene Taxonomien anlegen, die dann eben nicht Kategorie heissen sondern einen eigenen Namen kriegen. Sowas hab ich anno Dunnerkeil mal in meinem Bilderblog gemacht, da gabs eine eigene Taxonomie „Jahreszeiten“, die bestand aus genau vier Einträgen, nämlich „Frühling, Sommer, Herbst, Winter“. Bin ich wieder davon abgekommen, ich hab die Jahreszeiten einfach in die erste Kategorieebene mit aufgenommen, geht auch und ist wesentlich einfacher zu verwalten. Aber das nur am Rande bemerkt, wir holen uns die Tabellen jetzt mal ins Access rein und basteln uns die nötigen Verknüpfungen.

Das Datenmodell im Detail

Die ersten beiden Tabellen: wp_term_relationships und wp_posts

Wichtig ist hier erstens die object_id, das ist die ID des Beitrags aus der wp_posts. Einem Beitrag können ja mehrere Kategorien zugeordnet sein, deshalb tauchen die IDs hier auch mehrfach auf. Die term_taxonomy_id verweist auf die Kategorie. Die term_order könnte man für eine benutzerdefinierte Sortierung der Kategorien verwenden, aber das geht jetzt zu weit, das lassen wir weg.

screenshot_term_relationships

screenshot_term_relationships

Wir basteln uns also die erste Verknüpfung mit der object_id auf die wp_posts.

screenshot_beziehnungen_posts_relationships

screenshot_beziehnungen_posts_relationships

Die dritte Tabelle: wp_terms_taxonomy

Hier wird es schon ein bißchen undurchsichtiger. Die ersten drei Felder ID, term_taxonomy_id und term_id haben alle den selben Wert, da kann man nur raten wofür welches gut ist. Da wir nur die term_taxonomy_id aus der wp_term_relationships eindeutig zuordnen können, nehmen wir die halt, und merken uns als Hauptschlüssel die ID. Im Feld taxonomy steht immer der Wert category, wir haben ja nur diese eine Taxonomie, das können wir auch weglassen. Interessanter wäre da noch das Feld „parent“, das die übergeordnete Kategorie im Falle verschachtelter Kategorieebenen enthält, aber auch das lassen wir mal aussen vor, sonst blickt hier kein Schwein mehr durch.

Kleine Kuriosität am Rande: hier wird ein count mitgeführt, der die Anzahl der Beträge zu einer Kategorie wiederspiegelt. Kann man das nicht nachher im Rahmen einer Abfrage berechnen?

screenshot_term_taxonomies

screenshot_term_taxonomies

Unsere Beziehungen sollten jetzt so aussehen:

screenshot_beziehungen_3

screenshot_beziehungen_3

Die vierte Tabelle: wp_terms

Na gottseidank, da blickt man wenigstens halbwegs durch. Die term_id können wir aus der wp_term_taxonomy zuordnen, der name (na endlich!) ist der Name der Kategorie, slug ist auch klar, und die term_group ignorieren wir einfach.

screenshot_wp_terms

screenshot_wp_terms

Jetzt kommt endlich Butter bei die Fische, wir können unsere Beziehungen vervollständigen.

screenshot_beziehungen_4

screenshot_beziehungen_4

Haben wir da nicht noch was vergessen?

Die Tabelle wp_termmeta

Ja, die gibts auch noch, aber ehrlich gesagt weiß ich nicht so ganz genau, wofür man die verwenden könnte, die zieht nur wenn man mit mehreren Taxonomien arbeitet. Bei marketpress gibt es eine gelehrte Abhandlung dazu, ich hab sie allerdings nicht ganz verstanden, muss ich zugeben. Nachdem die Tabelle allerdings bei mir immer leer ist, ignoriere ich sie schlicht und ergreifend.

Sonst noch was? Ach ja, ich hätts beinah vergessen:

Die Tags = Schlagwörter stecken in der selben Logik

Und zwar wird für die Schlagwörter eine eigene Taxonomie „post_tag“ angelegt. Ich verwende prinzipiell keine Schlagwörter, wenn sie es getan haben lassen sie sich nicht irritieren, uns reichen die Beziehungen über die Kategorien.

Und jetzt: die Abfrage der Kategorien über alle vier Tabellen

Anmerkung: damit das hier nicht total uferlos wird, beschränke ich mich hier auf eine Kategorieebene. Sie sehen gleich, warum: Wir holen uns zunächst mal eine Auswahl relevanter Daten aus allen vier Tabellen, der SQL sieht dann so aus:

SELECT wp_posts.ID, wp_posts.post_title, wp_term_relationships.object_id, wp_term_relationships.term_taxonomy_id AS wp_term_relationships_term_taxonomy_id, wp_term_taxonomy.term_taxonomy_id AS wp_term_taxonomy_term_taxonomy_id, wp_term_taxonomy.term_id AS wp_term_taxonomy_term_id, wp_term_taxonomy.taxonomy, wp_term_taxonomy.count, wp_terms.term_id AS wp_terms_term_id, wp_terms.name
FROM wp_terms INNER JOIN ((wp_posts INNER JOIN wp_term_relationships ON wp_posts.[ID] = wp_term_relationships.[object_id]) INNER JOIN wp_term_taxonomy ON wp_term_relationships.[term_taxonomy_id] = wp_term_taxonomy.[term_taxonomy_id]) ON wp_terms.[term_id] = wp_term_taxonomy.[term_id];

Das Ergebnis: eine schon mal relativ übersichtliche Tabelle

Hier taucht jedes Rezept so oft auf, wie es Kategorien zugeordnet hat. Wenn wir jetzt ausser den Kategorien noch Schlagwörter mit drin hätten, müssten wir die herausfiltern, aber haben wir nicht, alles brav nur Kategorien.

screenshot_kategorien_rohdaten

screenshot_kategorien_rohdaten

Ein kleiner Kunstgriff: die Abfrage auf der Abfrage

Damit ich mir keinen Wolf parametrisiere, habe ich einfach auf die eben gezeigten Rohdaten (die Abfrage heisst auch kategorien_rohdaten) eine zweite Abfrage aufgesetzt, die ist schon übersichtlicher:

SELECT Count(kategorien_rohdaten.[ID]) AS AnzahlvonID, kategorien_rohdaten.[name]
FROM kategorien_rohdaten
GROUP BY kategorien_rohdaten.[name];

Auf Deutsch: ich zähle nur die Beitrags-IDs zu jeder genannten Kategorie, und fasse pro Kategorie die Summe zusammen. Das Ergebnis:

screenshot_kategorien_endergebnis

screenshot_kategorien_endergebnis

Na bitte, geht doch 🙂

Nur noch ein kleiner Glitch ist drin: die Summe beim Backwerk stimmt nicht. Das kommt daher, dass ich bei den Backwerken drei Unterkategorien angelegt habe, nämlich „Kuchen und Torten“, „Weihnachtsbäckerei“ und „Pikante Bäckereien“. Allerdings erlaubt es einem WordPress beim Erstellen oder Bearbeiten eines Beitrags, eine Unterkategorie anzugeben ohne auch die übergeordnete Hauptkategorie anzukreuzen, das habe ich offensichtlich einige Male gemacht, und daher stammt der Zählfehler. Die Korrektur ist einfach: ich entferne die Kategorie Backwerk und behandle die drei Unterkategorien wie Kategorien erster Ordnung, mein Excel für das Tortendiagramm kann mit Unterkategorien eh nix anfangen 🙂

Ich überlasse es jedem, der mit mehr als einer Kategorieebene gearbeitet hat selber, da die Logik entsprechend rauszupfriemeln, da muss man in der wp_terms_taxonomy den parent berücksichtigen, das ist mir jetzt hier zuviel Gedöns. Das hier langt jetzt nämlich echt für einen Beitrag, der hier ist lang genug – schließlich ist ja schon fast Feiertag!

 

 

 

 

 

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Kategorien im Inselfisch-Kochbuch, statistisch aufbereitet (kleine Schummelei)

Der einfache Weg – ich schummle ein bißchen

Ich lass mir ja die Beitrags-Kategorien im Inselfisch-Kochbuch in der Sidebar anzeigen, mit der Anzahl der jeweiligen Beiträge, das sieht so aus:

screenshot_kategorien

screenshot_kategorien

Und weil ich manchmal ein bißchen ein Faulpelz bin, kopier ich mir den ganzen Schamott als unformatierten Text in eine Spalte ins Excel rein, hacke mir in der zweiten Spalte die Anzahlen manuell rein und bastel mir mein erstes Tortendiagramm:

Rezeptkategorien-Diagramm

kategorien_torte

kategorien_torte

Nanü, ich hab also am allermeisten vegetarische Rezepte eingestellt? Darüber liesse sich debattieren, schließlich habe ich auch alle Kuchen, Torten und Süßspeisen als „vegetarisch“ kategorisiert. Kann ich aber damit leben, darunter fallen nämlich auch alle Salate und Gemüsezubereitungen, und sowas esse ich täglich, das hat schon seine Richtigkeit.

Rang zwei mit 99 Rezepten hat die Kategorie „Für Kinder“, und auch das hat seine Richtigkeit, denn schließlich stelle ich auch viele Rezepte aus meiner Kinderzeit aus Omas Küche ein, die werden von den Kiddies heute auch noch geliebt!

Der Rest spiegelt getreulich wieder was ich selber oft und gerne esse. Mir sind gute Saucen genauso wichtig wie das Stückchen Fleisch auf dem Teller, und meine ganz große Liebe gehört der Mittelmeerküche. Ausserdem esse ich viel Gemüse, und Kuchen gebacken wird bei mir auch regelmäßig.

Fazit: Ins Inselfisch-Kochbuch kommen nur Rezepte, die garantiert ausgetestet sind und die bei mir selber oft auf den Tisch kommen. Deshalb sind auch die Zubereitungsbeschreibungen sehr genau und gut nachzuvollziehen, so daß die Rezepte leicht und gelingsicher nachzukochen sind. Mein Publikum mag es so – Rezepte für jeden Tag sind gefragt, keine ausgefallenen Exoten! Ich bleibe bei dieser Philosophie, und schreibe weiter nur das hinein, was ich auch selber gern koche und esse.

Ja, aber das war doch geschummelt!

Klar wars geschummelt – aber die Kategorien zu den Beiträgen aus der WordPress-Datenbank zu holen ist ein Späßchen für sich, und dazu gibt es einen neuen Beitrag.

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Beitragsstatistik: weil mir das Dashboard da nicht reicht

Da waren die WordPress-Programmierer ein bißchen sparsam

Zugegeben, eine rudimentäre Beitragsstatistik läßt sich auch im Dashboard unter „alle Beiträge“ ablesen. Lesen, wohlgemerkt, wenn man da aussagekräftige Auswertungen fahren will, steht man ganz schön auf dem Schlauch, da kann man sich die Zahlen nur abschreiben, und das ist ein mühselig Spiel. Schon die allereinfachsten Statistiken wie z.B. Anzahl der Beiträge über die Tage gerechnet kann man sich zwar am Bildschirm angucken, aber wie zum Geier kriegt man die Daten da raus und rein ins Excel? Pfiffkas, da braucht man schon wieder Plugins dafür… ähem, Spaß muss sein, wir machen das natürlich anders 🙂

Ran an die Datenbank

Die meisten Daten von Interesse, wenn es um die Beiträge geht, stecken in der WordPress-Haupttabelle, der wp_posts. Die kennen wir ja schon recht gut, und die klemmen wir uns jetzt mal und schubsen sie aus MySQL raus und rein ins Access, da lässt es sich besser werken. Ich nehme wieder die Daten aus dem Inselfisch-Kochbuch, da war am meisten los.

Anmerkung am Rande: eine Access-2010-Lizenz gibts ab um die 30 €, wer öfter mal ein handliches Datenbankerl braucht sollte über diese Investition nachdenken!

Da hat sich ganz schön was angesammelt übers Jahr

Auf gehts, raus aus MySQL via CSV für Excel, Zeichensatz Windows 1250, Erste Zeile enthält Feldnamen anhaken und Schuß! Rein in Access, darauf gucken dass das Feld post_content den Datentyp Memo kriegt, und jetzt fangen wir richtig an.

1543 Datensätze bei 316 Rezepten – ganz schön viel Holz, aber das filtern wir uns gleich mal zurecht. Das ist jetzt alles Wiederholung, ich schalt mal den Schnellgang ein.

  • unser Erfassungszeitraum startet am 29.10.2016. Das Inselfisch-Kochbuch gibts zwar schon länger, aber da habe ich es nach einem katastrophigen Providerwechsel neu aufgebaut.
  • Ende-Datum ist gestern, 21.12.2017.
  • Uns interessieren eigentlich nur die veröffentlichten Rezepte, die erkennt man am post_type = post und post_status = publish.

Daraus stricken wir unsere erste Abfrage, wir nehmen erstmal nur wenige Felder mit, für den Anfang reichen uns das Erstellungsdatum (post_date) und der Titel (post_title). Im Access-Abfrageassistenten sieht das ganz bequem so aus:

Datum und Titel

Datum und Titel

Und hier kommt noch für alle Hardcorer das SQL:
SELECT wp_posts.post_date, wp_posts.post_title
FROM wp_posts
WHERE (((wp_posts.post_status)=“publish“) AND ((wp_posts.post_type)=“post“));

Das Ergebnis hat die erwarteten 316 Datensätze und sieht doch schon mal sehr hübsch aus:

liste_datum_titel

liste_datum_titel

Und wo ist der Rest geblieben?

Immerhin 1227 Datensätze sind bei unserer Abfrage auf der Strecke geblieben, wer oder was sind die? Access zu Hilf!

  • 1192 Datensätze sind vom post_status „inherit“, davon wiederum 1120 vom post_type „revision“. Das sind die Revisionen, die man sich im Beitragseditor zurückholen kann, wenn man mal einen Beitrag verschlimmbessert hat und eine frühere Version wieder herstellen möchte.
  • 16 mal post_type = page, das sind Seiten, keine Beiträge.
  • 72 mal post_type = attachment, das sind die hochgeladenen Bilder
  • und noch ein bißchen Kleinkram, ein paar drafts vom post_type = nav_menu_item und ein Contact-Form-Seven-Formular, das wars dann aber auch.

Wir bleiben jetzt mal bei unseren 316 veröffentlichten Beiträgen = Rezepten. Hier kommt die erste Statistik, die:

Anzahl der veröffentlichten Rezepte pro Tag über den ganzen Erfassungszeitraum

rezepte_pro_tag

rezepte_pro_tag

Was sagt uns dieses zackige Diagramm? Ich habe von Ende Oktober 2016 bis Ende Januar 2017 Rezepte eingehackt wie der Weltmeister, das war erstens die Wiederherstellung aus dem Datenbankbackup und zweitens die gleichzeitige Überarbeitung aller Rezepte im Hinblick auf Barrierefreiheit.  Von April bis Juli hab ich dann noch die Nachzügler aus dem Backup eingehackt, und ab August läuft dann der Normalbetrieb, mit ein bis zwei Rezepten an einem Tag. Dazu nehmen wir mal zum Vergleich die:

Besucherentwicklung über den gleichen Zeitraum

Man kann ganz deutlich sehen, dass die Anzahl der eingestellten Rezepte und die Anzahl der Besucher über den gleichen Zeitraum nahezu nix miteinender zu tun haben.

ifkb_besucher_pro_tag

ifkb_besucher_pro_tag

Ich mach hier mal einen kleinen Kunstgriff (wen es interessiert: mit dem GIMP) und mache eine

Kombination beider Diagramme

Jetzt stimmt natürlich die Y-Achsenbeschriftung nicht mehr, aber das kann ich verschmerzen. Die blaue Linie ist die Anzahl der von mir eingestellten Rezepte, die grüne Linie zeigt den Besucherverlauf.

besucher_gegen_rezepte

besucher_gegen_rezepte

Fazit: meinen Besuchern ist es nicht so wichtig, dass ständig neue Rezepte eingestellt werden. Die kommen, weil sie ein bestimmtes Rezept über Google gefunden haben, und dann kommen sie wieder und wieder zum Schmökern und zum Nachschlagen. Zur Erinnerung: ich habe 2819 Stammkunden (erkenntlich an den individuellen IP-Adressen), die so oft hereinschauen, dass sie den Löwenanteil meiner über 50.000 Hits auf dem Inselfisch-Kochbuch ausmachen.

Ich lerne daraus

Ja, was eigentlich? Dass ich mit dem Inselfisch-Kochbuch auf einem guten Weg bin, ein treues Stammpublikum habe und mir keinen Streß machen muss, weil ich nicht täglich neue Rezepte einstelle. Das läuft prima so wie es ist, die Besucherzahlen haben insgesamt eine leicht steigende Tendenz, das ist ein gesundes Wachstum und sehr erfreulich.

Und damit lass ich es für heute mal gut sein. Morgen gibts noch mehr WordPress-Zahlenschubserei,versprochen!

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Ein dicker, fetter WordPress-Bug: die Sache mit den Alt-Texten

Warum sind Alt-Texte so wichtig?

Wenn man Bilder in seine Webseite einfügt, kann man viel falsch machen. Zum Beispiel (was in WordPress leicht passiert) keinen Alt-Text einfügen, oder nur einen kryptischen Dateinamen wie DSC73635.JPG, so wie es aus der Digicam kommt, verwenden. Dabei ist der Alt-Text immens wichtig, wenn man barrierefreie Webseiten gestalten will, weil er für User von Screenreadern und anderen Hilfsmitteln die einzige Möglichkeit ist, Informationen über Bilder  zu erhalten. Und auch für nicht barierrefreie Seiten gilt: der Alt-Text ist nach W3C ein „required“ Attribut, also eine Pflichtangabe.

Bilder einfügen in WordPress: schnell mal drübergeklickt

WordPress bietet zwar beim Hochladen über die Mediathek die Möglichkeit, einen Alternativtext zum Bild einzugeben, aber es meckert auch nichts an wenn man dieses Feld leer läßt und ein Bild ohne Alt-Text hochlädt. Hier gehört eine Prüfung hin, die den Anwender auf den Fehler hinweist!

Wenn sie übrigens beim Bilder hochladen vergessen haben,  alt-Texte anzugeben, wird der jeweilige Dateiname dafür verwendet. Das ist gängige Praxis, aber nicht schön, weil der Screenreader dann eben -zig mal DSC01648 oder sowas vorliest, und das bringt natürlich überhaupt nichts.

Und sogar wenn man brav seinen Alt-Text eingibt, hat WordPress so seine Schwierigkeiten mit der Verwaltung. Das hatte ich in einem Beitrag über die Bildausgabe schon einmal erwähnt, aber es ist ein derart kapitaler Bug, daß ich ihn jetzt nochmal ausführlich beschreibe. Ich muß jetzt mal ein bißchen ausholen, um das näher zu erklären.

Wo landet der Alt-Text auf der Datenbank?

Zur Erinnerung: das Bild als solches landet in der wp_posts mit dem Post Type attachement. In der wp_postmeta  gibt es dann tatsächlich noch  einen Datensatz mit einem Fremdschlüssel, der die ID unseres Bild-Datensatzes aus der wp_posts enthält. Da wo im Feld meta_key das Schlüsselwort _wp_attachment_image_alt steht, da steckt daneben im Feld meta_value der alt-Text.

Das klingt soweit ja noch ganz gut, aber was, wenn man Alt-Texte nachträglich ändern will oder muß?

Dann passiert folgender blühende Unsinn:

Wenn sie jetzt im visuellen Editor hingehen und das jeweilige Bild bearbeiten, können sie zwar einen neuen, besseren alt-Text eingeben, aber der wird mitnichten in der Datenbank im Feld meta_value gespeichert! Der landet nur im img-src-Tag im post_content, und die Datenbank kriegt nichts mit davon. Wenn sie das Pferd jetzt andersherum aufzäumen und in der Mediathek das richtige Bild raussuchen, hier auf Bearbeiten gehen und da einen neuen alt-Text eingeben, landet der zwar in der Tabelle wp_postmeta (beim Metakey _wp_attachment_image_alt) aber nicht im Beitrag. Man müßte erst das betreffende Bild aus dem Beitrag löschen und aus der Mediathek wieder neu hereinnehmen, dann dürfte wieder das Datenbankfeld für den alt-Text herangezogen werden.

Übrigens: wenn sie den Alt-Text im visuellen Editor geändert haben und jetzt eine programmgesteuerte Ausgabe der alt-Texte via get_image_attribute() oder Ähnlichem probieren, kriegen sie natürlich die falschen Alt-Texte angezeigt, nämlich die aus der wp_postmeta, und nicht die aus dem img-src-Tag. Schöner Sch…, nicht wahr?

Konsequenzen dringend nötig

Das ist ein richtiger dicker, fetter Bug, da gibts kein Schönreden. Und es ist besonders ärgerlich, weil eben die Alternativtexte für die Barrierefreiheit so wichtig sind! Da dürfen sich die WordPress-Entwickler in Bälde etwas einfallen lassen, das Thema „Accessibility“, wie die Barrierefreiheit im Englischen heißt, ist auch in USA aktuell und taucht dort immer öfter in den Medien auf. Es gab auch schon spektakuläre Gerichtsurteile gegen Firmen, die ihre Webseiten nicht nach den Regeln der Barrierefreiheit gestaltet haben. Da darf man gespannt sein, wie der Gesetzgeber reagiert! Accessibility oder Zugänglichkeit von Webseiten ist eben ein brandaktuelles Thema, nicht nur bei uns.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Noch mehr postmeta: benutzerdefinierte Felder in wooCommerce

Falls ihnen die 48 vordefinierten Felder in wooCommerce noch nicht reichen, haben sie auch die Möglichkeit, zusätzliche Felder anzulegen. Diese laufen unter dem Stichwort „benutzerdefinierte Felder“ und können im Produkt-Editor angelegt werden.

Ein Feld für Material

Zu dem in meinem Online-Lädchen verkauften Glasperlenschmuck lege ich jetzt mal ein benutzerdefiniertes Feld „Material“ an.  Das kriegt dann zum Beispiel den Wert „Böhmische Glasperlen“, das sieht im Editor so aus:

benutzerdefinierte_felder

benutzerdefinierte_felder

Keine Hexerei, und was auf der Datenbank passiert kann man leicht erraten:

material_postmeta

material_postmeta

Es wird ein neuer Datensatz mit dem meta_key „Material“ angelegt, der kriegt den meta_value „Böhnmische Glasschliffperlen“. Das war’s schon, mehr ist nicht passiert.

Wie verwendet man nun diese Felder?

wooCommerce weist einen da höflich auf den Codex zum Thema Custom Fields hin. Das ist zwar gut gemeint, aber nicht besonders hilfreich. Deswegen gibts bei Tante Google auch jede Menge Einträge, wenn man nach „woocommerce show custom fields“ sucht, hier ist ein besonders netter von Theme Location

Der Knackpunkt ist: man muss die wooCommerce-Templates editieren, wenn man seine benutzerdefinierten Felder auch beim Produkt angezeigt kriegen will. Wir versuchen uns mal an einem einfachen Beispiel. Da sollen wir eine Zeile im Template content-single-product.php ergänzen:

<?php echo get_post_meta( get_the_ID(), ‘Material’, true ); ?>

Edit die content-single-product.php – ja, wie?

Also, erstmal muss man das richtige Template finden, und das ist bei der endlosen Latte von wooCommerce-Templates gar nicht so einfach. Schauen sie mal rein unter Plugins/wooCommerce/Bearbeiten, das ist alles andere als übersichtlich. Die content-single-product.php steht in der langen Liste ziemlich weit unten.

„At the appropriate place“ soll diese Zeile rein, heißt es im Tutorial, und das ist eine Runde Trial and Error. Ich habs jetzt im ersten Anlauf noch nicht hingekriegt, da muss ich nochmal ne Runde googlen. So richtig Spaß macht das nicht, die wooCommerce-templates sind viel zu schlecht dokumentiert, das ist eine einzige Raterei.

Anderer Ansatz: wooCommerce Hooks

Ich hatte jetzt relativ schnell die Schn… voll von der Rumprobiererei und bin auf einen anderen Lösungsansatz gestossen, um unser benutzerdefiniertes Feld auch anzeigen zu lassen. WooCommerce bietet eine lange Latte von vordefinierten Hooks, in die man sich einklinken kann, das ist hier bei BusinessBloomer recht ausführlich dokumentiert, man muss sich allerdings anmelden, um das Tutorial anschauen zu können, und dazu hatte ich keine Lust. Ein andermal vielleicht…

Prinzipiell sollte es so funktionieren: man editiert die functions.php und fügt den entsprechenden Hook hinzu, in dem ruft man die zugehörige selbstdefinierte Funktion auf, und die Funktion letztendlich sollte unser Custom Field dann auch anzeigen. Ich habs nicht hingekriegt, jedenfalls nicht in unter einer Stunde, und da hatte ich dann einfach keinen Bock mehr. Ist vielleicht nicht mein Tag zum Rumprobieren heute.

Noch ein Versuch: vielleicht mit einem Plugin?

Das hier sieht ganz gut aus:

WooCommerce Custom Product Data Fields

Das schau ich mir mal an, aber ich glaube, ich brauch erstmal ’ne Pause. Ja kruzitürken, kann das denn so schwer sein, so ein lumpiges Custom Field auch anzeigen zu lassen?

Ist echt nicht mein Tag heute, die Doku zu dem Plugin ist gerade nicht erreichbar.

acf_nicht_ereichbar

acf_nicht_ereichbar

Hab ich noch ein anderes Plugin probiert, ACF for WooCommerce.

ACF  = Advanced Custom Fields. Aber zu früh gefreut: auch kein Glück, da muß ich mal direkt die Support-Seite zitieren:

  • It seems only to work on Checkout Page. How do I show field on the Product Page?

    Any answer is most welcome, thank you.

Viewing 6 replies – 1 through 6 (of 6 total)

Tscha, Pech gehabt. Die Anzeige der Custom Fields in der Single Product Ansicht geht hier nur mit der kostenpflichtigen Pro-Version des Plugins, und die kostet 29 $. No way, José.

Jetzt reichts mit der Probiererei – noch einmal mit System.

Also, wir fangen nochmal sauber von vorne an. Wo soll unser benutzerdefiniertes Feld „Material“ erscheinen? In der Startseite des Shops, jedenfalls reicht mir das für’s erste. Direkt nach dem Titel, vor dem Warenkorb-Button.

Dafür editieren wir die woocommerce/templates/content-product.php.

Durch schlichtes Ausprobieren und Raten habe ich schließlich die richtige Position gefunden: nach der Zeile:

do_action( ‚woocommerce_shop_loop_item_title‘ );

Das hat nicht auf Anhieb funktioniert, da WordPress im Template anscheinend die get_post_meta()-Funktion nur mit ein bißchen Überredungskunst akzeptiert. Ich habe dann folgendes Snippet gefunden, damit kriegen wir endlich den meta_value unseres Custom Fields „Material“ angezeigt :

global $wp_query;
$postid = $wp_query->post->ID;
echo get_post_meta($postid, ‚Material‚, true);
wp_reset_query();

Ergebnis- meine benutzerdefinierten Felder werden jetzt direkt unter dem Titel jedes Produkts angezeigt:

shop_mit_cf

shop_mit_cf

Na bitte, geht doch. Aber ein Gfrett war das jetzt schon!

Wie gehts jetzt weiter?

Wenn man das benutzerdefinierte Feld noch woanders anzeigen möchte: tscha, das wird jetzt ein Exempel in Trial&Error. Für jede Seite im Shop herausfinden, welches Template für die Anzeige verwendet wird, dort die Stelle suchen an welcher das Custom Field erscheinen soll, da das obige Code Snippet einfügen und hoffen dass es funkioniert. Viel Spaß mit Tante Google und der wooCommerce-Doku…

Ich finde das Thema Custom Fields in wooCommerce insgesamt wahnsinnig unübersichtlich und lausig schlecht dokumentiert. Anscheinend gibt es einige Plugins, die einem da das Leben leichter machen sollen, aber ich hab bislang nur kostenpflichtige Exemplare gefunden, die das auch können was wir brauchen. Und ich zahle nicht für Plugins, Punktum. OpenSource, sie wissen schon. So, und das ist ein schöner Schlußsatz für diesen Beitrag, lassen wir es mal gut sein.

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

In eigener Sache: Let’s talk about SEO, baby!

An diesem Wochenende hat mein Besucherzähler auf dieser Seite die 5.000er-Marke geknackt, und das ist eine respektable Zahl für einen sehr spezialisierten kleinen Blog wie den schwarzen Pinguin. Gezählt wird hier seit Februar diesen Jahres (2017), also hab ich hier rund gerechnet 5.000 Besucher in einem halben Jahr gehabt. Das freut mich persönlich sehr und ermutigt mich, mit meiner lockeren Plauderei über IT am Feierabend und WordPress im Speziellen weiterzumachen. Mir geht auch so schnell der Stoff nicht aus, keine Bange, nächste Woche gibts dann wieder Spaß auf der Datenbank!

Barrierefreiheit als SEO-Booster

Da wir gerade beim Thema sind: der Renner auf evileu.de ist nach wie vor das Inselfisch-Kochbuch mit aktuell 33.648 Besuchern, und da sind die Besucherzahlen nach einem eh schon guten Start nochmal kräftig in die Höhe gegangen, seit ich das Kochbuch in Sachen Barrierefreiheit  komplett umgebaut habe. Auch nicht schlecht läuft meine Oddballs-Handarbeitsseite, hier sind es immerhin auch schon 11.297 Besucher in einem halben Jahr. Das ist wirklich nicht übel für eine rein private Webseite, und ich werde oft gefragt, wie ich das denn gemacht habe.

Meine SEO-Tricks

Da muß ich euch leider enttäuschen. Ich nutze kein SEO-all-in-one Pack, ich jongliere nicht mit Keywords, mir ist mein Google Ranking egal, ich schalte keine Werbung, ich mach das hier alles zu Fuß.

Was ich allerdings schon mache: ich blogge wie der Weltmeister. Im Inselfisch-Kochbuch gibts mindestens einmal die Woche ein neues Rezept, hier quassel ich auch ungefähr ebenso oft aus dem Nähkästchen der alten Programmiererin, und auf den Handarbeitsseiten gibts regelmäßig Fotos meiner aktuellen Socken, Schals und Pullover und gelegentlich auch mal eine neue Anleitung zum Download als PDF. Das heißt, auf meinen Blogseiten ist regelmäßig Neues geboten, und das lieben nicht nur die Suchmaschinen, das lieben anscheinend auch menschliche Besucher.

Beiträge mit Hand und Fuß

Und ich erzähle halt nicht nur irgendeinen Keyword-gespickten Quark, meine Beiträge haben (meistens) Hand und Fuß. Nach meinen Kochrezepten kann auch ein Anfänger kochen, wenn man einen Schal nach meiner Handarbeitsanleitung strickt, dann wird das auch was, und wenn man meinen Code hier nachprogrammiert, dann funzt das auch. Das ist mein ganzes Geheimnis.

Wiederholungstäter und Mundpropaganda

Das sind meine wichtigsten Werbemittel. Meine streng wissenschaftlichen Analysen (ich hab einfach viele Leute gefragt) haben ergeben, dass gerade das Inselfisch-Kochbuch durch Mundpropaganda immer mehr Besucher bekommt, besonders das mit der Barrierefreiheit spricht sich hübsch herum. Und dann kommen meine Besucher auch wieder, sie benutzen das Kochbuch als Nachschlagewerk. Ich hab jetzt schon von vielen weiblichen Fans gehört, dass sie im Supermarkt mit dem Smartphone schnell mal ein Rezept im Inselfisch-Kochbuch nachschlagen und schauen, was sie dafür einkaufen müssen. Da hilft es natürlich, dass ein sauber umgesetztes WordPress-Theme im Regelfall fully responsive ist und auch auf dem Smartphone vernünftig dargestellt wird.

Spezialisierung: ein Blog, ein Thema

Das mit der Spezialisierung war bei mir dringend notwendig, weil ich so breitgefächerte Interessen habe. Ich male, ich programmiere, ich koche für mein Leben gern, ich schreibe Bücher für Kinder und für Erwachsene und produziere Handarbeiten am laufenden Band, und das ist noch lang nicht alles.

Ich habe in früheren Jahren schon mehrere vergebliche Anläufe gemacht, alle meine Interessensgebiete auf einer einzigen Webseite unterzubringen, und bin jedesmal  an dieser Sysiphosarbeit gescheitert. Letztendlich war  Wordpress der Schlüssel für die erfolgreiche Realisierung des Gemischtwarenladens evileu.de.

Ich habe jedem meiner vielen Hobbies einen eigenen Blog gegönnt, in dem ich jeweils nur über ein einziges Thema blogge. Es sind jetzt insgesamt etwas mehr als 10 Blogs, nicht alle sehr aktiv, aber doch eine stolze Anzahl für eine private Homepage. Wenn man nur mal auf die Seiten über meine Malerei schaut, das Thema ist jetzt aufgesplittet in meine Biographie als Malerin, meine Aquarelle, die Serie mit den blauen Planeten und dazu noch die Computergrafiken mit GIMP. Das macht 4 Kunst-Blogs, und die sind alle proppevoll mit Bildern und meinen Texten dazu. Aber eben sauber nach Themen getrennt, sonst verzettelt man sich. Und auch die Besucher verzetteln sich wenn eine Webseite zu viele verschiedene Topics anbietet, da werden die Menüs und Untermenüs und Unter-Untermenüs so verschachtelt, dass kein Schwein mehr durchblickt, und die Besucher nicht wiederkommen, weil sie nichts wiederfinden.

Jetzt fahre ich da eine ganz klare Linie, und das hat für mich als viel-Bloggerin den Vorteil, dass ich sofort weiß wohin damit, wenn mir eine Idee zu einem neuen Beitrag kommt. Und meine Besucher kennen sich auch aus, da jeder Themenblog einen unverwechselbarenb Look&Feel hat, und man sofort weiß ob man auf der Handarbeitsseite oder im Inselfisch-Kochbuch gelandet ist. Ich bin ein Buchhalterkind, ich liebe strukturierte Ablagesysteme!

Damit sind wir ganz wunderbar beim nächsten Stichwort gelandet:

Strukturierung: h1, h2 und Co.: eigentlich HTML für Anfänger

Ob sie es glauben oder nicht, Textverarbeitung am Computer gab es schon lange vor Windows und WYSIWYG. Ich erinnere nur an TeX/LaTeX oder an Word für DOS, wo man mitnichten auf dem Bildschirm angezeigt bekam, was dann auf dem Drucker herauskam. Damals lernten wir alles über die Verwendung von sog. Textauszeichnungen, in Word für Windows heißen sie Formatvorlagen. Und da HTML nichts anderes als eine Textauszeichnungssprache ist, gibt es sie  hier genauso. Jeder kennt sie, kaum jemand wendet sie richtig an.  Für Überschriften sind h1..h6 vorgesehen, eine Tabelle formatiert man mit Hilfe des <table>-Tags, es gibt nummerierte Listen, es gibt Image-Tags für die Bilder… das sind viele, aber doch nicht endlos viele. Eine hübsche komplette Liste aller HTML5-Tags findet ihr hier bei MDN Web Docs

Trennung von Text und Formatierung

Die Idee dabei ist, Text und Formatierung sauber zu trennen. Ein einfaches Beispiel: eine Hauptüberschrift soll fett, in Arial und in 30 Punkt Größe angezeigt werden. Was macht der WYSIWYG-Anwender? Er markiert den betreffenden Textabschnitt, drückt auf das Icon für „fett“, wählt in der Dropdownliste für die Schriftart „Arial“ und scrollt in der Schriftgrößen-Zahleneingabe rauf bis 30. Das erzielt zwar den gewünschten Effekt, aber es ist textverarbeitungstechnisch nicht sauber. Wie gehts richtig? Die Überschrift kriegt die Tags <h1>…</h1>, und wenn man es nicht dem Browser überlassen will wie eine Überschrift erster Ordnung dargestellt wird, legt man es in seiner CSS-Datei fest. Hierhin kommen unsere Textattribute, wenn man es richtig machen will.

Saubere Gliederung

Das habe ich bei der Umarbeitung meiner Webseiten auf barrierefrei neu lernen müssen, bei mir hatte sich da über die Jahre auch eine gewisse Schlamperei eingeschlichen. Ich schreibe ja sehr viel Text, und lange Textwüsten auf einer Webseite sind absolutes Bildschirmgift, die liest kein Schwein. Also, umdenken, Text in kürzere logische Einheiten unterteilen, Zwischenüberschriften einfügen, wo es Sinn macht, Listen und Tabellen verwenden. Das erhöht die Lesbarkeit und hält den Besucher bei der Stange, weil er nicht von unstrukturierten Endlostexten gelangweilt wird.

Einfaches Beispiel: Rezepte mit Struktur

Ich hätte da wieder ein einfaches Beispiel: alle meine Rezepte im Inselfisch-Kochbuch haben die selbe logische Gliederung:

  • Einleitung
  • Zutaten
  • Zubereitung
  • Tipps

Diese Elemente sind als h2-Überschriften formatiert. H1 ist der Titel des jeweiligen Rezepts, das ist unser post_title aus WordPress. Der Text dazwischen ist einfach <p> wie Absatz. That’s all, nach diesem Muster schreibe ich alle meine Rezepte. Ich muß nicht drüber nachdenken wie ich es mache, und es hat bei meinem Publikum einen hohen Wiedererkennungswert und dient der allgemeinen Übersichtlichkeit und Verständlichkeit. Mehr ist nicht dran an der Strukturierung – machen muß man es halt!

Übrigens: Suchmaschinen lieben klar strukturierte HTML-Dokumente. Benutzer mit Handicap (Screenreader & Co.) lieben sie auch, weil sie so klar durch das Dokument navigieren können. Deswegen ist eine gute Textstrukturierung auch eine der wichtigsten Voraussetzungen der Barrierefreiheit nach WCAG.

Mehr ist nicht dran an meinem SEO-Programm

Mit dieser Strategie bin ich zu meinen stolzen Besucherzahlen gekommen, über alle Blogs gerechnet sind das jetzt insgesamt fast 50.000 seit Anfang des Jahres. Genug aus dem Nähkästchen geplaudert, ich mach hier mal die Kiste zu. Ich hab mir nämlich gerade ein neues Projekt in Sachen Barrierefreiheit angelacht, da hat der schwarze Pinguin jetzt ein bißchen Sendepause. Bis die Tage!

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Exkurs über unsere Kundendaten

Ich wollte ja eigentlich als nächstes den Bestellvorgang beleuchten, aber rein logisch kommen erstmal unsere Kunden an die Reihe, deswegen zieh ich das hier mal kurz vor.

Anmelden oder nicht anmelden?

WooCommerce bietet den Kunden die Möglichkeit, auch ohne das Anmelden eines Kundenkontos mit Password und allem drum und dran in unserem Shop als „Gast“ einzukaufen. Und soll ich ihnen sagen, was ich bevorzuge, wenn mir ein Shop da die Wahl läßt? Ich werde auf jeden Fall die Option ohne Anmeldung wählen. Weil ich mir nicht noch ein Paßwort merken will, weil ich keinen Bock auf Newsletter und Werbesendungen habe, weil ich meine persönlichen Daten im Internet nur hergebe, wenn es unbedingt sein muß. Ehrlich, sie können darauf zählen daß ein hoher Prozentsatz ihrer Kunden genauso denkt und auch ohne Erstellung eines „offiziellen“ Kundenkontos bei ihnen einkauft.

Kundendaten sind Unternehmenskapital

Wir wollen aber an unsere Kundendaten rankommen, die Adressen, Telefonnummern und E-Mail-Adressen sind so gut wie bares Kapital für unsere Firma.

Wenn sich ein Kunde brav bei uns anmeldet, wird in der WordPress Benutzerverwaltung ein neuer User mit der Rolle „Kunde“ für ihn angelegt, das ist recht gut dokumentiert. Die Benutzer Kunden werden in der wp_users verwaltet, in der wp_usermeta findet man dann die zugehörigen Adressdaten, die sind über die User-ID verknüpft.

Aber wo stecken unsere nicht angemeldeten Kunden?

Da haben sich die wooCommerce-Programmierer eine ganz besonders pikante Lösung einfallen lassen. Die haben sie nämlich schamhaft in der wp_postmeta versteckt:

nicht_angemeldeter_kunde

nicht_angemeldeter_kunde

Als ein Feld, alle Adressdaten in einem einzigen matschigen Klumpen. Zur Bestellung über die post_id zugeordnet, kenntlich am Meta Key _billing_adress_index.

Da soll doch der Dunnerlittchen…. sorry, aber bei sowas werde ich echt sauer. Das ist richtige Stümperei auf der Datenbank, aus so einem Feld krieg ich nie und nimmer (oder nur mit hohem Programmieraufwand) meine Kundendaten sauber wieder raus. Ja klar kann man mit PHP und einem „explode“ in ein Array und dann zeilenweise auslesen… ja hört’s mir aber auf. Das ist Pfusch, richtiger Pfusch, da beißt die Maus kein Faden ab.

So, jetzt langts aber, genug gestänkert. Wir machen uns mal an die Bestellungen, im nächsten Artikel.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Kleiner Nachtrag zu den Produkten: wo steckt die Artikelnummer?

Da hab ich doch glatt noch was vergessen. Wir haben ja unsere CSV-Datei inklusive der Artikelnummern eingelesen, und die Feldzuordnung beim Import ging hier auf _sku. Das Feld _sku steckt in der wp_postmeta, und hier ist auch die post_id hinterlegt, die regelt zu welchem Produkt die betreffende Artikelnummer gehört.

Aber was ist, wenn man ein Produkt manuell eingibt – wo kommt da die Artikelnummer hin? Davon ist nämlich erst mal weit und breit nichts zu sehen.

Des Rätsels Lösung: man muß beim neu Eingeben eines Produkts den Reiter „Lager“ aktivieren, dann kann man eine Artikelnummer eingeben.

lager_sku

lager_sku

Falls sie übrigens in Versuchung kommen sollten, die Lagerverwaltung hier tatsächlich wooCommerce anzuvertrauen: tun sie’s nicht. Für sowas gibts professionelle ERP-Software (auch als Shareware), damit sind sie wesentlich besser bedient. Das aber nur mal so als kleiner Tipp am Rande.

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend

Schuster, bleib bei deinem Leisten: die Stärken von wooCommerce

Also, mir machen jetzt mal eine kurze Erholungspause von der Datenbankschinderei und schauen uns unseren nagelneuen Online-Shop mal genauer an. Tun Waren in den Warenkorb, schauen uns den an und bearbeiten ihn gegebenenfalls, und dann gehen wir mal zur Kasse.

Halt stopp! Da fehlt noch eine Zahlungsart

WooCommerce kommt eigentlich mit sehr funktionalen Grundeinstallungen daher, der Bestellvorgang läuft so professionell wie man ihn sich nur wünschen kann, aber zum Austesten fehlt noch (mindestens) eine Zahlungsart. Die hinterlegen wir unter wooCommerce/Einstellungen/Kasse, hier ganz nach unten scrollen. Für Testzwecke aktivieren wir hier mal nur die Scheckzahlung und hinterlegen unsere Firmenadresse, das sieht so aus:

scheckzahlung

scheckzahlung

Mehr brauchts nicht, jetzt können wir Einkaufen gehen.

Der Einkaufs- und Bestellvorgang

Da muß ich nicht groß ausholen und erklären, das ist alles absolut professionell und funktioniert mit den Default-Einstellungen schon ganz hervorragend, Der Bestell- und Bezahlvorgang ist einleuchtend und leicht verständlich und ganz so wie man es von „grossen“ Shopsystemen gewohnt ist. Man kann den Warenkorb füllen und bearbeiten, man kann zur Kasse gehen und seine Kundendaten hinterlegen, es gibt E-Mail-Benachrichtigungen über den Bestellstatus usw usf., Ich möchte es jedem selber überlassen,  hier in die Feinheiten einzusteigen, probiert es einfach aus und schaut euch in den wooCommerce-Einstellungen mal um. Viel Spaß dabei, das ist ein sehr erfreuliches Kapitel!

Kunde hat bestellt – und nun?

Kann man die offenen Bestellungen unter wooCommerce/Bestellungen einsehen und bearbeiten. Aber was ist im Underground passiert? Wir werfen mal einen kurzen Blick auf die Datenbank. Relevant für die Bestellungen sind eigentlich nur drei Tabellen, die wp_woocommerce_order_itemmetaVerstecken und dieAuf-/ZuklappenStrukturwp_woocommerce_order_items sowie die wp_posts. Ja, das habt ihr schon richtig gelesen, die Bestellungen landen ebenfalls in der wp_posts, mit dem post_type shop_order. Wir schauen uns das jetzt mal der Reihe nach an, aber dazu gönnen wir uns einen neuen Beitrag.

 

 

 

 

Ihre Meinung interessiert mich!

Wie hat Ihnen dieser Artikel gefallen?

sehr gutgutbefriedigendausreichendmangelhaftungenügend