CMS to Commerce Hub ist eine Symfony-Plattform, die Produktdaten aus CMS-, PIM-, ERP- und Datei-Quellen übernimmt und daraus marktplatzfähige Produktseiten für Amazon und Shopware vorbereitet.
Start: Live-Demo · Architektur · Quality Report · Portfolio
Quality: 54 PHPUnit tests, PHPStan Level 3 and Symfony CI gates.
Sectionscode-Import: gleiche Nummer, gleiches Produkt.
1.1.txt -> Produktdaten
1.1.png -> Hauptbild
1.1.1.png -> Detailbild
Nach dem Import werden Kanal-Entwürfe vorbereitet.
$product = $intakeManager->createFromInput($formData, $uploadedFiles);
foreach (ChannelType::cases() as $channel) {
$publicationOrchestrator->prepare($product, $channel);
}Die fertigen Kanalstrukturen bleiben als kleine JSON-Preview abrufbar.
GET /products/{id}/export/amazon
GET /products/{id}/export/shopware
| Frage | Einstieg |
|---|---|
| Was macht das Produkt? | Live-Demo |
| Welche Engineering-Entscheidungen stecken dahinter? | Architektur |
| Wie sieht das Projekt für Recruiter aus? | Recruiter-Überblick |
| Welche Praxis ist belegbar? | Production Evidence |
| Wie werden Betrieb, Datenbank und Secrets behandelt? | OPERATIONS.md |
| Wie argumentiere ich das im Gespräch? | Interview-Pitch |
| Welche Audits gibt es? | Audit Report · Quality Report |
| Wie werden externe Systeme erweitert? | Integrations-Roadmap |
Senior-Signale im Projekt:
- fachliche Logik liegt in Services statt in Controllern
- externe Systeme werden über Adapter, Normalizer und Preview-/Publish-Gates getrennt
- Live-Schreibvorgänge sind per Default deaktiviert und brauchen explizite Serverfreigaben
- CI prüft Composer, Container, Twig, PHPStan und PHPUnit
- produktive Secrets bleiben außerhalb des Repositories
- die Production Evidence dokumentiert echte Betriebsfälle: 500er-Analyse, Migrationen, Cache/Assets, Secrets und Integrationsgrenzen
Eine kompakte, GitHub-taugliche Projektvorstellung mit Screenshots, Tech-Stack, Architektur-Highlights und Integrationen liegt hier:
- Admin-Login
- Produkt-Intake per Webformular
- Listenimport mit TXT-Dateien und separaten Produktbildern
- Intake-API (
POST /api/intake) mit Token-Schutz - Produktstamm mit Quellen, Assets, Varianten und Channel-Entwürfen
- Amazon-A-Listing-Drafts mit Qualitätsprüfung
- Shopware Admin API inklusive Produkt- und Medienzuordnung
- vorbereitete Amazon-SP-API-Anbindung ohne Live-Testzwang
- JTL-, plentymarkets-, Xentral-, SAP-R/3-, Pimcore- und Shopify-Vorbereitung mit Sync-/Write-back-Flows
- zeitgesteuerte externe Sync-Jobs
- Zugangsdaten-Portal pro Channel/System mit maskierten Secrets
- reduzierte Portal-UX mit maximal drei sichtbaren Hauptaktionen pro Bereich
- Export-Vorschau als JSON pro Channel
composer install && php bin/console doctrine:migrations:migrate && symfony server:startFür lokale Entwicklung nutzt die committed .env nur Dummy-/Defaultwerte.
Produktive Zugangsdaten gehören nicht ins Repository. CTC lädt sensible Werte in dieser Reihenfolge:
- globale Server-/Umgebungsvariablen, zum Beispiel Hosting-Panel, Apache
SetEnvoder PHP-FPM-Environment - private Dateien außerhalb des Projektordners unter
../private-config/ctc*.env - harmlose Defaults aus der committed
.env
Im Portal koennen Admins die channel-spezifischen Zugangsdaten unter /credentials pflegen.
Die Formulare schreiben in ../private-config/ctc-shopware.env, ctc-amazon.env,
ctc-shopify.env usw.; geheime Werte werden maskiert angezeigt und beim Leerlassen
nicht ueberschrieben.
Wichtige Variablen:
APP_SECRETAPP_ADMIN_PASSWORD_HASHAPP_IMPORT_API_TOKENDATABASE_URLSHOPWARE_*AMAZON_*JTL_*PLENTY_*XENTRAL_*SAP_R3_*PIMCORE_*SHOPIFY_*
Beispiele liegen in:
Nach Deployments muss die produktive Datenbank auf dem aktuellen Migrationsstand sein:
php bin/console doctrine:migrations:migrate --env=prod --no-interaction
php bin/console doctrine:schema:validate --env=prodWenn im Dashboard "Datenbank noch nicht bereit" erscheint, ist die Datenbankverbindung oder das Schema nicht synchron. Details und Checkliste: