Geprüft am 08.10.2026 Gegen eine laufende Instanz geprüft, mit dem Konfigurator-Stand 175fc24 und einem WooCommerce-Paket auf PHP 8.4

Seite kopieren

Konfigurations-Assistent

Zuletzt geändert am 19. Oktober 2026

Der Konfigurations-Assistent führt in elf Schritten zu einem startfertigen Shop-Paket: einem ZIP-Archiv mit Docker-Compose-Datei, vorbereiteter Umgebung und einem Einrichtungsskript. Wer das Paket auf einem Rechner mit Docker auspackt und zwei Befehle ausführt, hat einen eingerichteten Shop samt der gewählten Randsysteme.

Der Assistent öffnet sich auf dem E-Commerce Hub unter https://ecommerce-hub.sh/konfigurations-assistent/ im Modal. Der Quellcode liegt in GitLab unter splendidinternet/ospo/konfigurator (Symfony).

Was der Assistent nicht speichert

Auf dem Server wird nichts abgelegt und es wird kein Cookie gesetzt. Die Auswahl liegt nur im Browser (localStorage) und wird nach dem Download, bei „Neu beginnen" oder beim nächsten Aufruf der Startseite gelöscht, spätestens nach 24 Stunden. Zugangsdaten fragt der Assistent grundsätzlich nicht ab.

Die Schritte

Geschäftsmodell

B2C, B2B oder beides. Die Auswahl bestimmt, welche Shopsysteme im nächsten Schritt wählbar sind. WooCommerce wird nur für B2C angeboten: Im freien Standard fehlen Staffelpreise, Kundengruppen und ein Feld für die Umsatzsteuer-ID, die Voraussetzung für Reverse Charge ist.

Shopsystem

WooCommerce, Shopware 6 oder Mage-OS. Ein System, das noch nicht ausgeliefert werden kann, steht mit „Bald verfügbar" in der Liste, lässt sich aber noch nicht wählen. Der Grund steht sichtbar auf der Karte. Derzeit ist auf ecommerce-hub.sh nur WooCommerce wählbar: Mage-OS lässt sich noch nicht ausliefern, und Shopware 6 ist nur in unserer internen Testumgebung wählbar, solange die Auslieferung entsteht.

Aussehen und Inhalte

• Theme: bei WooCommerce Storefront, das offizielle Shop-Theme, oder das mitgelieferte WordPress-Theme.
• Sortimentsgröße: bis 100, bis 1.000, bis 10.000 oder mehr als 10.000 Produkte. Davon hängt ab, welche Erweiterungen im nächsten Schritt empfohlen werden.
• Beispielprodukte: auf Wunsch werden Demo-Produkte importiert, um den Shop auszuprobieren. Der Import läuft nur, solange der Shop noch leer ist.

Erweiterungen

Die rechtlich nötigen Grundbausteine sind immer dabei, bei WooCommerce sind das WooCommerce selbst, Germanized und die eigene Erweiterung „Gewährleistungshinweis“ (ospo-gewaehrleistung). setup.sh schaltet in Germanized den seit 27.09.2026 vorgeschriebenen EU-Gewährleistungshinweis ein, ab Werk ist er aus. Die Erweiterung macht ihn mit jedem Theme barrierefrei und zeigt ihn auch auf Kategorie- und Suchseiten, Einzelheiten unter Rechtliches mit Germanized. Dazu kommen wählbare Erweiterungen, die empfohlenen sind vorausgewählt:

Erweiterung	Zweck	Empfohlen
Yoast SEO	Suchmaschinenoptimierung	ja
Complianz	Cookie-Einwilligung, DSGVO	ja
WP Mail SMTP	zuverlässiger Mailversand über einen SMTP-Dienst	ja
EU-Captcha	Spamschutz, Hosting in Deutschland	ja
Two Factor	Zwei-Faktor-Anmeldung	ja
Contact Form 7	Kontaktformulare
EWWW Image Optimizer	lokale Bildoptimierung
ElasticPress	schnelle Suche über Elasticsearch	ab 10.000 Produkten
KI-Produkttexte	Produkttexte per KI

Wer bei einem großen Sortiment die Suche abwählt, bekommt auf der Abschlussseite einen Hinweis, mit dem sie sich per Klick nachtragen lässt. Begründungen zu den einzelnen Erweiterungen stehen unter WooCommerce: Erweiterungen.

Aktualisierung. Unter den Erweiterungen steht die Karte „Automatisch aktualisieren“, vorausgewählt und als empfohlen markiert. Sie erscheint nur bei Shopsystemen, deren Katalog dafür Befehle mitbringt, derzeit bei WooCommerce. Mit Haken schaltet setup.sh ganz am Ende, wenn auch die Erweiterungen der Randsysteme installiert sind, die automatischen Updates für WordPress, alle Erweiterungen und alle Themes ein. Ohne Haken setzt es auto_update_core_major ausdrücklich auf disabled, denn WordPress schaltet das bei der Installation selbst ein. Dann kommen nur die Sicherheitsupdates des Kerns automatisch, alles andere aktualisiert der Händler im Backend. Die Wahl steht als automatische_updates in der konfiguration.json; fehlt der Schlüssel, etwa in älteren Dateien, gilt der Haken als gesetzt.

Erweiterungen, die nicht aus dem WordPress-Verzeichnis kommen. Zwei Erweiterungen installiert setup.sh aus einer Datei statt aus dem Verzeichnis: EU-Captcha, das dort nicht steht, und die eigene Pflicht-Erweiterung „Gewährleistungshinweis“ (ospo-gewaehrleistung). EU-Captcha holt setup.sh beim Einrichten direkt bei Myra Security, aus dem fertigen ZIP im GitHub-Repository des Herstellers (Myra-Security-GmbH/eu-captcha-wordpress, Zweig main). Jeder neue Shop bekommt damit die neueste Fassung. Das ist bewusst so gewählt: immer aktuell, dafür ohne Prüfung durch uns. Scheitert der Download, etwa ohne Netz, installiert setup.sh die Fassung, die im Paket unter plugins/ liegt. Der Gewährleistungshinweis kommt immer aus dem Paket.

Für beide kennt WordPress keine Update-Quelle. Sie melden nie eine neue Fassung und aktualisieren sich auch mit Haken bei „Automatisch aktualisieren“ nicht. Die Karte sagt das, die README.md im Paket nennt beide mit der Anleitung: neue Fassung als ZIP-Datei im Backend unter Plugins → Neues Plugin hinzufügen → Plugin hochladen einspielen. Die AGENTS.md nennt den Befehl dafür, mit einer ZIP-Datei oder einer URL:

wp plugin install https://raw.githubusercontent.com/Myra-Security-GmbH/eu-captcha-wordpress/main/eu-captcha.zip --force

Zahlungsanbieter

Mollie wird an der Kasse eingebunden. Die API-Schlüssel trägt der Händler selbst in die .env ein.

Newsletter

Das Newsletter-Plugin läuft im Shop selbst. Für eine verlässliche Zustellung sollte der Shop über einen SMTP-Dienst versenden (WP Mail SMTP).

Ihr Shop

Öffentliche Angaben, wie sie später im Impressum stehen: Shopname, Domain, Firma, Anschrift, Land (derzeit nur Deutschland), Währung (Euro), Kleinunternehmerregelung nach § 19 UStG, Teilnahme an Verbraucherstreitbeilegung und die Preisauszeichnung. Bei der Preisauszeichnung gibt es zwei Vorlagen statt Einzelfragen: „Standard" zeigt alle Pflichtangaben, „Minimal" nur das gesetzliche Minimum. Germanized kennt rund 280 Einzeloptionen dafür, siehe Rechtliches mit Germanized.

Aus der Domain schlägt der Assistent in den folgenden Schritten die Adressen der Randsysteme vor, deshalb kommt „Ihr Shop“ vor ihnen. Wer keine weiteren Randsysteme braucht, nimmt statt „Weiter“ den zweiten Knopf „Ohne weitere Randsysteme fertigstellen“. Er prüft die Angaben wie „Weiter“, verwirft eine Auswahl in den späteren Schritten Produktdaten, Web-Analyse, Automatisierung und Zusammenarbeit und führt direkt zum Abschluss. Zahlungsanbieter und Newsletter kommen davor und bleiben erhalten. Mit der Eingabetaste geht es weiter wie bisher.

Produktdaten

LibrePIM als zentrale Quelle für Produktdaten. Sinnvoll, sobald Produkte in mehreren Kanälen oder Sprachen gepflegt werden. Wählbar ist derzeit nur, eine bestehende Instanz anzubinden, mit einer vorgeschlagenen Adresse wie bei den übrigen Randsystemen (siehe unten). „Mitinstallieren“ steht als „Bald verfügbar“ da, weil es noch kein Docker-Image gibt, das den Code von LibrePIM enthält. Das verfügbare Image ist eine reine Entwicklungsumgebung, im Paket startete der Container ohne Code immer wieder neu. Hintergründe zur Anbindung unter Randsysteme anbinden.

Web-Analyse

Matomo, selbst gehostet, als Ersatz für Google Analytics. Siehe Randsysteme anbinden.

Mitinstalliert kommt Matomo fertig eingerichtet, ohne Installationsassistent. Der Einmal-Dienst matomo-einrichtung läuft vor setup.sh und legt den Administrator aus MATOMO_ADMIN_USER und MATOMO_ADMIN_PASSWORD an, den Shop als E-Commerce-Website und den Token, mit dem sich der Shop anmeldet. Man meldet sich also direkt mit den Angaben aus der .env an. Das Image steht fest auf matomo:5, weil die Einrichtung Matomos interne Klassen nutzt wie der Installationsassistent.

Gezählt wird über den Shop selbst: Der Browser schickt die Besuche an den Shop, WordPress reicht sie intern an Matomo weiter, ohne Cookies. Matomo muss dafür für Besucher nicht öffentlich erreichbar sein. MATOMO_URL_OEFFENTLICH ist nur die Adresse, unter der man Matomo selbst im Browser aufruft. Sie kommt aus dem Adressfeld des Schritts.

Anbinden fragt die Adresse und die Website-ID ab. Den Token legt man in der vorhandenen Instanz an und trägt ihn in die .env ein.

Automatisierung

Activepieces verbindet Shop und Randsysteme ohne Programmierung, als selbst gehostete Alternative zu Zapier oder n8n. Siehe Randsysteme anbinden.

Mitinstalliert legt setup.sh den ersten Benutzer an. Man meldet sich mit ADMIN_EMAIL und ACTIVEPIECES_ADMIN_PASSWORD aus der .env an, eine Registrierung entfällt. Danach lässt Activepieces neue Benutzer nur noch per Einladung zu. Den Schlüssel für die REST-API des Shops legt man weiter selbst an, damit er nicht im Klartext in der Konfiguration landet.

Zusammenarbeit

Nextcloud als Plattform für Dateien, Kalender und Teamarbeit. Nextcloud ist nicht mit dem Shop gekoppelt, sondern steht dem Team als Arbeitsumgebung zur Verfügung.

Mitinstalliert richtet sich Nextcloud beim ersten Start selbst ein, ohne Assistenten. Man meldet sich mit NEXTCLOUD_ADMIN_USER und NEXTCLOUD_ADMIN_PASSWORD aus der .env an. NEXTCLOUD_TRUSTED_DOMAINS bekommt den Hostnamen aus dem Adressfeld des Schritts. Die Liste wirkt nur beim ersten Start, danach lässt sie sich nur noch in Nextcloud selbst ändern.

Abschluss und Download

Die Abschlussseite fasst die Auswahl zusammen, nennt die nötige Hardware und listet die Dateien im Paket. Von hier aus gibt es das ZIP und die Datei konfiguration.json.

Randsysteme: mitinstallieren oder verbinden

Für jedes Randsystem gibt es bis zu drei Möglichkeiten:

Modus	Was passiert
Installieren	Das System kommt als eigene Container ins Paket, die Zugangsdaten werden beim Download frisch erzeugt. Matomo, Activepieces und Nextcloud sind nach der Einrichtung fertig eingerichtet, ohne Installationsassistent und ohne Registrierung.
Verbinden	Ein vorhandenes System wird angebunden. Abgefragt werden nur nicht geheime Angaben wie die URL, Geheimnisse trägt man selbst in die .env ein.
Keines	Das System taucht im Paket nicht auf, auch kein Plugin im Shop.

Ein Modus, der noch nicht funktioniert, steht ausgegraut mit „Bald verfügbar“ da und lässt sich nicht wählen, derzeit „Mitinstallieren“ bei LibrePIM.

Adressen der Randsysteme

Jedes Randsystem, das mitinstalliert oder angebunden wird, hat ein Adressfeld. Darunter steht ein Vorschlag aus der Domain des Schritts „Ihr Shop“, den man mit „Übernehmen“ einträgt oder im Feld ändert:

System	Vorschlag
LibrePIM	https://librepim.example.org, nur beim Anbinden
Matomo	https://matomo.example.org
Activepieces	https://activepieces.example.org
Nextcloud	https://nextcloud.example.org

Steht vor der Domain www. oder shop., fällt das für den Vorschlag weg: Aus shop.example.org wird https://matomo.example.org. Der Server prüft jede Adresse, beim Schritt und noch einmal beim Download. Feste localhost-Adressen gibt es im Assistenten und in der .env nicht mehr.

Erprobt ist bisher nur WooCommerce

Der Assistent bietet die Randsysteme auch für Shopware 6 und Mage-OS an. Aufgebaut und getestet ist die Anbindung aber bisher nur mit WooCommerce. Für die beiden anderen Shopsysteme läuft die Evaluierung noch, siehe Architektur und Grundsätze.

Das Paket

Datei	Inhalt
docker-compose.yml	alle Dienste: Shop, Datenbank, gewählte Randsysteme, Einrichtungsdienst
.env	Ports, Adressen für den Server und Zugangsdaten. Was sich erzeugen lässt, ist bereits erzeugt; was nur der Händler kennt, bleibt leer und ist beschriftet.
.env.local	nur die Adressen auf localhost mit den Ports aus der .env, zum Ausprobieren auf dem eigenen Rechner
setup.sh	richtet den Shop ein: Installation, Sprache, Erweiterungen, Rechtsseiten, Stammdaten, Anbindung der Randsysteme. Lässt sich gefahrlos wiederholen.
README.md	Anleitung für Menschen
AGENTS.md	Anleitung für KI-Werkzeuge, die das Paket selbstständig aufsetzen sollen
konfiguration.json	die Auswahl selbst, maschinenlesbar
plugins/	Erweiterungen, die es nicht im WordPress-Verzeichnis gibt
Beilagen	Skripte, mit denen sich mitinstallierte Randsysteme einrichten, etwa matomo-einrichten.php und activepieces-einrichten.php

Paket starten

Ein Paket lässt sich auf zwei Wegen starten, ohne etwas umzuschreiben: auf dem eigenen Rechner zum Ausprobieren oder auf dem Server. Die .env enthält die Adressen für den Server, abgeleitet aus der Domain und den Adressfeldern im Assistenten. Die .env.local ersetzt beim Ausprobieren nur diese Adressen durch http://localhost mit den Ports aus der .env. Zugangsdaten stehen nur in der .env, die beiden Dateien können also nicht auseinanderlaufen.

In beiden Fällen zuerst das Archiv auspacken und in der .env mindestens ADMIN_EMAIL eintragen.

Auf dem eigenen Rechner ausprobieren. Beide Dateien laden und einen eigenen Projektnamen setzen. Der Name besteht aus dem Shopnamen und -test, im README des Pakets steht er fertig im Befehl:

docker compose --env-file .env --env-file .env.local -p meinshop-test up -d
docker compose --env-file .env --env-file .env.local -p meinshop-test --profile setup run --rm wpcli

Der eigene Projektname ist Pflicht. WordPress und Matomo schreiben ihre Adresse bei der Einrichtung in die Datenbank, ein Test unter localhost wäre sonst im Betrieb nicht mehr loszuwerden. So bekommt er eigene Volumes und ist hinterher spurlos weg:

docker compose -p meinshop-test down -v

Damit auch die Einrichtungsdienste die lokale Datei lesen, steht in der docker-compose.yml bei ihnen env_file: [.env, '${ENV_LOCAL:-.env}'], und die .env.local setzt ENV_LOCAL. Ein solcher Test gehört nicht ins offene Netz: Es gibt keine Verschlüsselung, und die Rechtstexte sind Platzhalter.

Auf dem Server betreiben. Ohne .env.local:

1. Für die Shop-Adresse (SITE_URL) und jede Adresse eines Randsystems einen DNS-Eintrag auf den Server setzen. Das README des Pakets listet sie einzeln auf.
2. HTTP_PORT und die übrigen Ports auf freie Werte setzen.

3. Starten und einmalig einrichten:

   docker compose up -d
   docker compose --profile setup run --rm wpcli
   

4. Einen Reverse Proxy mit TLS davorsetzen, etwa Traefik, Caddy oder nginx. Er leitet jede Adresse auf den Port ihres Dienstes auf 127.0.0.1 weiter, die Zuordnung steht ebenfalls im README des Pakets.

Der Name des Einrichtungsdienstes (wpcli bei WooCommerce) steht im README des Pakets. Die AGENTS.md beschreibt dieselben zwei Wege für KI-Werkzeuge und fragt zuerst, welcher gemeint ist.

Danach ist die Verwaltung unter der Shop-Adresse plus /wp-admin erreichbar, Benutzer admin, das Passwort steht in der .env. Dort stehen auch die Zugänge der mitinstallierten Randsysteme. Der Shop ist zunächst für Besucher gesperrt. Das ist Absicht: Impressum, AGB, Datenschutzerklärung und Widerrufsbelehrung sind als Entwürfe mit Platzhaltern angelegt und müssen vor dem Livegang ergänzt und rechtlich geprüft werden.

Randsysteme erreichen

Auf dem Server sind die Randsysteme unter ihren Adressen aus der .env erreichbar, sobald DNS und Reverse Proxy stehen. Beim Ausprobieren gelten die Ports, die Voreinstellungen stehen in der .env:

System	Port beim Ausprobieren
Shop	8090 (HTTP_PORT)
Matomo	8081 (MATOMO_PORT)
Activepieces	8083 (ACTIVEPIECES_PORT)
Nextcloud	8084 (NEXTCLOUD_PORT)

Ändert man einen Port in der .env, zieht die .env.local mit, weil sie die Adressen aus den Port-Werten bildet. Die Adressen fürs Ausprobieren stehen im README des Pakets.

Ports nicht direkt ins Netz

Docker veröffentlicht Ports standardmäßig auf allen Schnittstellen und umgeht dabei Firewalls wie ufw. Auf einem Server die Ports per Firewall vor dem Rechner sperren oder in der docker-compose.yml an 127.0.0.1 binden (127.0.0.1:8081:80), damit nur der Reverse Proxy sie erreicht.

Eine Konfiguration weitergeben

Die konfiguration.json aus einem früheren Download lässt sich am Anfang des Assistenten oder auf der Abschlussseite wieder hochladen. Übernommen wird nur, was der Katalog kennt. Unbekannte Systeme, Erweiterungen oder Felder fallen stillschweigend weg, eingelesene Werte landen nie ungeprüft in einem Shell-Befehl.

Den Assistenten erweitern

Die Auswahl steckt nicht im PHP-Code, sondern in einem Katalog: eine YAML-Datei je System unter config/katalog/. Eine Datei beschreibt, was das System im Paket ausmacht:

• Bezeichnung, Beschreibung, Kategorie und für welche Shopsysteme es passt,
• je Modus die Container (compose), die Umgebungsvariablen (env, erzeugt, vorgegeben oder geheim) und die abgefragten Felder,
• die Einrichtungsbefehle je Shopsystem (setup), die in die setup.sh übernommen werden,
• Beilagen, die mit ins Paket gehen (beilagen), und Dienste, auf die setup.sh warten muss (einrichtung_wartet_auf), etwa der Einmal-Dienst von Matomo,
• Adressen: vorschlag gibt den Namen der vorgeschlagenen Subdomain vor, lokal den Wert für die .env.local, nur_host macht aus der Adresse einen reinen Hostnamen wie bei NEXTCLOUD_TRUSTED_DOMAINS,
• Sperren: gesperrt an einem Modus zeigt ihn als „Bald verfügbar“, nur_sandbox an einem Shopsystem lässt es nur in der internen Testumgebung wählen. Beides prüft auch der Server, bis zum Download.

Ein neues Randsystem heißt also: eine neue YAML-Datei. Nur eine neue Kategorie braucht zusätzlich eine Zeile in src/Configurator/StepRegistry.php.

Barrierefreiheit

Der Assistent folgt dem BFSG, also WCAG 2.1 AA: vollständig per Tastatur bedienbar, Auswahlkarten mit sichtbarem Fokus, Hinweise nicht nur beim Überfahren mit der Maus. Das Repository enthält dafür eine automatische Prüfung (tests/barrierefrei_pruefen.py).