Zum Inhalt
Gegen eine laufende Instanz geprüft, mit Matomo 5.12.0 und Connect Matomo 1.1.12, LibrePIM und Akeneo Connector 1.21, Activepieces 0.82.0 und Mollie Payments 8.1.10 im Testmodus. Nextcloud nicht geprüft

Randsysteme anbindenLink zu diesem Abschnitt

Zuletzt geändert am

Randsysteme laufen in eigenen Containern neben dem Shop. Die Verbindung entsteht in der Anwendung: über ein Plugin im Shop, einen Konnektor oder die REST-API. Diese Seite beschreibt, wie das bei WooCommerce aussieht und wo es hakt.

Basic-Auth und Server-zu-Server-Verkehr

Liegt eine Instanz hinter HTTP-Basic-Auth, scheitern alle Aufrufe, die nicht aus einem Browser mit Zugangsdaten kommen, mit 401. Ein 401 als reiner Text statt als JSON-Fehler ist das Indiz: Dann blockiert der Proxy, nicht die Anwendung. Abhilfe ist ein eigener Router mit höherer Priorität und ohne Auth für genau diese Pfade. Die eigene Authentifizierung der API bleibt die eigentliche Zugriffskontrolle.

MatomoLink zu diesem Abschnitt

Selbst gehostete Web-Analyse (GPLv3). Eine zentrale Instanz kann mehrere Shops bedienen, jeder bekommt eine eigene Site-ID.

Plugin: „Connect Matomo" (Slug wp-piwik). Nicht „Matomo Analytics" (Slug matomo): Das bettet eine eigene Matomo-Kopie in WordPress ein, mit eigenen Tabellen, und spricht keine vorhandene Instanz an.

Einrichtung per WP-CLI. wp-piwik speichert jede Einstellung als eigene Option (wp-piwik_global-<schlüssel> bzw. wp-piwik-<schlüssel>), nicht als gemeinsames Objekt. Ein JSON-Objekt in eine Option wp-piwik_global zu schreiben, wirkt deshalb nicht.

wp option update wp-piwik_global-piwik_mode http
wp option update wp-piwik_global-piwik_url "http://matomo/"     # mit Schrägstrich am Ende
wp option update wp-piwik_global-piwik_token "$MATOMO_AUTH_TOKEN"
wp option update wp-piwik-site_id "$MATOMO_SITE_ID"
wp option update wp-piwik_global-track_mode default            # sonst bleibt das Tracking aus
  • piwik_mode muss http sein. Andere Werte schicken das Plugin zur Matomo-Cloud.
  • track_mode steht ab Werk auf disabled. Ob das Tracking eingeschaltet wird, ist auch eine Frage der Einwilligung, siehe Complianz.
  • Die URL darf die interne Adresse sein. Das Plugin holt den Tracking-Code über die API, und die Adresse darin bestimmt Matomo selbst aus seiner öffentlichen URL (var u="//matomo.example.org/").
  • Den Auth-Token legt man in Matomo unter Administration → Persönlich → Sicherheit an, also erst nach dem ersten Start. Im Paket des Konfigurations-Assistenten erledigt das die Einrichtung, dort gibt es auch keinen Installationsassistenten.

Zählen über den Shop. Mit track_mode default steht im Tracking-Code die Adresse, die Matomo für sich selbst kennt. Ist das die interne Adresse wie http://matomo, kennt sie kein Browser. Der Modus proxy umgeht das: Der Browser schickt die Besuche an den Shop, WordPress reicht sie intern an Matomo weiter. Matomo muss dann für Besucher nicht öffentlich erreichbar sein, und dieselbe Einstellung gilt auf dem eigenen Rechner wie auf dem Server. So richtet es der Konfigurations-Assistent ein, ohne Cookies:

wp option update wp-piwik_global-track_mode proxy
wp option update wp-piwik_global-disable_cookies 1
# Tracking-Code beim nächsten Seitenaufruf neu holen, etwa nach einer geänderten Adresse
wp option update wp-piwik_global-last_settings_update "$(date +%s)"

Hinter Basic-Auth brauchen zwei Pfadgruppen eine Ausnahme, im Modus proxy nur noch die API: der Tracker (/matomo.php, /matomo.js, /piwik.php, /piwik.js), den die Browser der Besucher aufrufen, und die API (/index.php?module=API sowie POST /), die das Plugin serverseitig nutzt.

Andere Shopsysteme: Für Shopware 6 und Mage-OS sind freie Konnektoren gefunden, aber noch nicht erprobt: tinect/matomo (MIT) für Shopware 6 ist installiert, aber noch nicht eingerichtet, mit fnogatz/magento2-matomo (AGPL-3.0) für Mage-OS ist noch nicht begonnen.

LibrePIMLink zu diesem Abschnitt

LibrePIM ist der aktiv gepflegte Fork von Akeneo Community Edition (OSL-3.0). Angebunden über das WordPress-Plugin akeneo-connector (GPLv3).

Richtung: Nur PIM → Shop. Der Connector kennt ausschließlich Import-Befehle. Bestand oder Preise aus dem Shop zurück ins PIM wären eine eigene Entwicklung.

Import per WP-CLI, keine automatische Synchronisation. Die Reihenfolge ist wichtig:

wp akeneo attributes import
wp akeneo options import
wp akeneo categories import
wp akeneo models import
wp akeneo products import

Unveränderte Produkte überspringt der Import anhand des Postmeta _akeneo_hash. Wer nur auf WordPress-Seite etwas ändert, etwa ein neues Mapping, muss dieses Meta löschen, damit das Produkt neu verarbeitet wird.

Zugang: Für den Shop einen eigenen OAuth-Client und einen eigenen API-Benutzer in LibrePIM anlegen, nicht den Admin-Account verwenden:

bin/console pim:oauth-server:create-client "WooCommerce"
bin/console pim:user:create ...

Eigener Kanal und Kategoriebaum. Teilen sich mehrere Shops eine LibrePIM-Instanz, bekommt jeder Shop einen eigenen Kanal mit eigenem Kategoriebaum. Ein Import über einen fremden Kanal zieht dessen komplette Kategorien in den Shop.

Felder erweitern. Welche Felder im Produktformular erscheinen, bestimmt die Produktfamilie, nicht der Kanal. Das Muster für jedes weitere WooCommerce-Feld: Attribut in LibrePIM anlegen, der Familie zuordnen, im Connector auf das WooCommerce-Feld mappen (akeneo_settings_synchronization → attribute_mapping). So lassen sich Preis, Angebotspreis, Bestand, Maße, Gewicht und Sichtbarkeit aus dem PIM pflegen. Einige Eigenheiten:

  • Zahlen-Attribute brauchen das Feld negative_allowed, sonst antwortet die API mit 422.
  • Bestand wirkt nur mit manage_stock = true und bei nicht virtuellen Produkten.
  • Auswahl-Optionen am besten genau so benennen wie die WooCommerce-Werte (instock, outofstock, onbackorder).

Bilder. Der Connector verarbeitet keine Bildattribute und könnte die Mediendateien ohne Token auch nicht laden. Gelöst über ein Must-Use-Plugin, das sich an ak/a/product/single/after_save hängt, das Bild per REST-API mit Bearer-Token holt, als Anhang anlegt und Duplikate über ein eigenes Meta erkennt. Eine Bildergalerie kennt die Community Edition nicht, der übliche Ausweg sind mehrere einzelne Bildattribute.

Hinter einem Reverse Proxy erzeugte LibrePIM in der API-Pagination http://-Links. Der Akeneo-PHP-Client folgt dem Redirect nicht und bricht ab. Drei Stellen waren nötig:

  1. TRUSTED_PROXY_IPS setzen, damit Symfony X-Forwarded-Proto auswertet.
  2. Im PHP-FPM-Pool clear_env = no, sonst kommt die Variable in den FPM-Workern nicht an. docker exec … env zeigt sie trotzdem, weil es einen eigenen Prozess startet.
  3. In der nginx-Konfiguration fastcgi_param HTTP_X_FORWARDED_PROTO $http_x_forwarded_proto; ergänzen.

Docker-Image

webkul/librepim-php-dev ist ein Entwicklungsimage. Es enthält nur PHP und erwartet den LibrePIM-Quellcode als eingehängtes Verzeichnis sowie einen eigenen Webserver davor. Ohne beides startet der Container nicht. Deshalb lässt sich LibrePIM im Konfigurations-Assistenten derzeit nur anbinden, nicht mitinstallieren.

Nebenwirkung: Der Connector legt Produkte über die normalen WooCommerce-Hooks an. Ein Import löst deshalb dieselben Webhooks aus wie ein im Backend angelegtes Produkt, etwa einen Activepieces-Flow.

ActivepiecesLink zu diesem Abschnitt

Selbst gehostete Workflow-Automatisierung (MIT), gewählt statt n8n, das unter der nicht OSI-anerkannten Sustainable Use License steht.

Anbindung ohne Plugin. Das offizielle WooCommerce-Piece nutzt die REST-API und die Webhooks von WooCommerce. Den Schlüssel legt man unter WooCommerce → Einstellungen → Erweitert → REST-API an.

Öffentliche Adresse. Activepieces baut Webhook-URLs aus AP_FRONTEND_URL. Steht dort localhost, sind alle Webhooks von außen unerreichbar. Im Paket des Konfigurations-Assistenten kommt die Adresse aus dem Adressfeld des Schritts Automatisierung. Nur beim Ausprobieren auf dem eigenen Rechner setzt die .env.local localhost, dann erreichen Webhooks von außen Activepieces erwartungsgemäß nicht.

Erster Benutzer. Ohne Benutzer landet jeder Aufruf bei /sign-up. Im Paket des Konfigurations-Assistenten legt setup.sh ihn deshalb über die Sign-up-API an, mit ADMIN_EMAIL und ACTIVEPIECES_ADMIN_PASSWORD. Er ist Administrator der Plattform, danach lässt Activepieces Registrierungen nur noch mit Einladung zu. Ein zweiter Aufruf meldet INVITATION_ONLY_SIGN_UP, die Einrichtung lässt sich also gefahrlos wiederholen.

Nicht hinter Basic-Auth. Activepieces hält Socket.IO-Verbindungen und mehrere Abfragen im Hintergrund offen, mit Basic-Auth gerät der Browser in eine Anmeldeschleife. Den Zugriffsschutz übernimmt das eigene Login.

Verzögerung bei Webhooks. WooCommerce stellt Webhooks über den Action Scheduler zu, also über WP-Cron. Mit einem System-Cron im Fünf-Minuten-Takt kommt ein Ereignis bis zu fünf Minuten später an. Das ist kein Fehler.

Fallstricke im Flow-Editor:

  • Variablen nur über den Data Selector einfügen. Von Hand getippte {{schritt.feld}}-Ausdrücke werden nicht als Bindung erkannt und lösen still zu einem Leerstring auf.
  • Die interne Zählung beginnt nach dem Trigger: Der dritte Schritt im UI heißt in Ausdrücken step_2.
  • Der Code-Editor ergänzt beim Tippen Klammern. Überzählige Klammern fallen erst beim Lauf als Compilation Error auf.
  • Wer Flows direkt in der Datenbank ändert, muss die Container neu erstellen (docker compose down && docker compose up -d). Ein Neustart reicht nicht.

Marken lassen sich über die REST-API nicht schreiben. WC_REST_Products_Controller speichert beim Schreiben nur categories und tags, ein mitgeschicktes brands wird still ignoriert. Gelöst mit einem eigenen kleinen Endpunkt als Must-Use-Plugin, abgesichert über ein gemeinsames Geheimnis im Header. Vereinfacht:

<?php
// wp-content/mu-plugins/ospo-brand-api.php
add_action( 'rest_api_init', function () {
    register_rest_route( 'ospo/v1', '/set-brand', [
        'methods'             => 'POST',
        'permission_callback' => function ( WP_REST_Request $request ) {
            return hash_equals( OSPO_BRAND_SECRET, (string) $request->get_header( 'X-OSPO-Secret' ) );
        },
        'callback'            => function ( WP_REST_Request $request ) {
            wp_set_object_terms( (int) $request['product_id'], $request['brand_name'], 'product_brand', false );
            return [ 'ok' => true ];
        },
    ] );
} );

OSPO_BRAND_SECRET steht als Konstante außerhalb der Versionskontrolle, siehe Betrieb.

meta_data lässt sich dagegen frei schreiben, auch mit Unterstrich-Präfix. Darüber setzt der Flow etwa die KI-Kennzeichnung (_wtofe_ai_generated).

Beispiel-Flows, die KI-Texte erzeugen, stehen unter KI-Produkttexte.

NextcloudLink zu diesem Abschnitt

Nextcloud ist nicht mit dem Shop gekoppelt, sondern Arbeitsumgebung fürs Team. Hinter einem Reverse Proxy erzeugt das offizielle Image ohne weitere Angaben http://-Adressen und Cookies ohne Secure-Flag. Zwei Umgebungsvariablen beheben das:

environment:
  OVERWRITEPROTOCOL: https
  OVERWRITECLIURL: https://cloud.example.org

Die Domain landet bei der Installation über den Browser automatisch in trusted_domains, wenn man die Installation über die endgültige Adresse aufruft.

Ohne Browser installiert sich das offizielle Image beim ersten Start selbst, wenn NEXTCLOUD_ADMIN_USER, NEXTCLOUD_ADMIN_PASSWORD und NEXTCLOUD_TRUSTED_DOMAINS gesetzt sind. So macht es das Paket des Konfigurations-Assistenten, den Hostnamen nimmt es aus dem Adressfeld des Schritts Zusammenarbeit. NEXTCLOUD_TRUSTED_DOMAINS (mehrere Namen mit Leerzeichen getrennt) wirkt nur beim ersten Start, danach ändert man die Liste in Nextcloud selbst (occ config:system:set trusted_domains).

MollieLink zu diesem Abschnitt

Zahlungsabwicklung über das Plugin „Mollie Payments for WooCommerce" (GPLv2). PayOne wäre technisch ebenso geeignet, steht aber unter MIT. Mollie passt mit der GPL besser zum übrigen Stack. Die API-Schlüssel für Test- und Livebetrieb gehören zu den Geheimnissen, die der Händler selbst einträgt.

NewsletterLink zu diesem Abschnitt

Das Plugin „Newsletter" von Stefano Lissa (GPLv2+) läuft im Shop selbst, ohne externen Dienst. Es hat MailPoet abgelöst. Für eine verlässliche Zustellung sollte der Shop über einen SMTP-Dienst versenden, siehe Betrieb.