WooCommerceLink zu diesem Abschnitt
Zuletzt geändert am
Der WooCommerce-Stack ist im OSPO-Projekt am weitesten ausgebaut. Er dient als Referenzinstanz: Hier wurden Plugins und Randsysteme ausprobiert, angebunden und bewertet, bevor sie in den Konfigurations-Assistenten übernommen wurden.
StackLink zu diesem Abschnitt
| Komponente | Version | Woher die Version kommt | Zweck |
|---|---|---|---|
| WordPress | jeweils aktuell | automatische Updates auf der Sandbox, Aktualisierung beim Einrichten eines Pakets, danach nach Wahl im Assistenten | CMS |
| WooCommerce und Erweiterungen | jeweils aktuell | ebenso; Sprünge über eine Hauptversion lässt WooCommerce nicht automatisch zu, siehe Betrieb | Shopfunktionen |
| PHP | 8.4.x | fest über den Image-Tag php8.4, Patches kommen mit dem Image. 8.4 ist die neueste Version, gegen die WooCommerce getestet ist |
Laufzeit, mit Apache |
| MariaDB | 11.x | Image mariadb:11, immer die neueste 11er-Version |
Datenbank |
| Elasticsearch | 7.17.24 | exakt festgelegt | Suche über ElasticPress |
| Storefront | jeweils aktuell | wie die Erweiterungen; auf der Sandbox ergänzt um das Child Theme ospo-storefront |
Theme |
Pakete aus dem Konfigurations-Assistenten
Beim Einrichten holt setup.sh die neuesten Versionen von WordPress, WooCommerce, allen Erweiterungen, Themes und Übersetzungen. Ob das Paket danach weiter von selbst aktualisiert, entscheidet der Interessent im Schritt Erweiterungen mit der Karte „Automatisch aktualisieren“, die vorausgewählt ist. Mit Haken schaltet setup.sh am Ende die automatischen Updates für WordPress, Erweiterungen und Themes ein, ohne Haken laufen nur die Sicherheitsupdates des Kerns. Was dafür auf dem Server nötig ist, steht unter Betrieb. Ausnahmen sind EU-Captcha und der Gewährleistungshinweis: Sie stehen nicht im WordPress-Verzeichnis. EU-Captcha holt setup.sh beim Einrichten in der neuesten Fassung direkt bei Myra, der Gewährleistungshinweis kommt aus dem Paket. Automatisch aktualisieren sich beide danach nicht, siehe Erweiterungen.
Alles läuft als Docker-Container hinter einem Reverse Proxy, der TLS terminiert. Das eigene Image erweitert wordpress:php8.4-apache nur um WP-CLI und die Werkzeuge für die lokale Bildoptimierung (jpegoptim, optipng, gifsicle, pngquant, webp).
| Container | Image | Aufgabe |
|---|---|---|
web |
eigenes Image auf Basis wordpress:php8.4-apache |
WordPress, PHP, Apache |
db |
mariadb:11 |
Datenbank |
elasticsearch |
docker.elastic.co/elasticsearch/elasticsearch:7.17.24 |
Suchindex |
ThemenLink zu diesem Abschnitt
| Seite | Worum es geht |
|---|---|
| Erweiterungen | welche Plugins im Einsatz sind, mit Lizenz und Begründung, und welche verworfen wurden |
| Rechtliches mit Germanized | Rechtstexte, Checkboxen, Widerrufsbutton, Einstellungs-Referenz |
| Randsysteme anbinden | Matomo, LibrePIM, Activepieces, Mollie, Newsletter |
| KI-Produkttexte | KI-Texte mit lokalem Sprachmodell statt Cloud |
| Theme und Frontend | Child Theme, Storefront-Hooks, CSS-Fallstricke, Ladeverhalten |
| Barrierefreiheit | BFSG, WCAG 2.1 AA, geprüfte und behobene Punkte |
| Betrieb | Zugangsdaten, Docker-Fallstricke, Cron und automatische Updates, Mailversand |
| Fehlersuche | was schiefgehen kann, nach Symptom sortiert, mit Ursache und Abhilfe |
In Kürze: was wir gelernt habenLink zu diesem Abschnitt
- Ohne Germanized ist WooCommerce in Deutschland nicht betreibbar. Rechtstexte, Pflicht-Checkboxen und Grundpreise fehlen im Kern.
- B2B geht mit freiem WooCommerce nicht sinnvoll. Staffelpreise, Kundengruppen und ein Feld für die Umsatzsteuer-ID fehlen im Standard und sind nur über kostenpflichtige Erweiterungen zu haben.
- Plugin-Beschreibungen prüfen. Mehrere Plugins verhielten sich im Code anders als beworben.
- Eigene Anpassungen gehören in Must-Use-Plugins unter
wp-content/mu-plugins/, nicht in fremden Plugin-Code. - WP-Cron braucht einen System-Cron, sobald
DISABLE_WP_CRONgesetzt ist. Sonst laufen weder automatische Updates noch Webhooks.