Pimcore Workflow-Design für Enterprise: Die Architektur hinter 20 Redakteuren

Das Problem, über das niemand spricht

Jede Pimcore-Installation fängt gleich an. Ein paar Produkte, ein Content-Team von drei Leuten, alles über die Admin-UI verwaltet. Veröffentlichen heißt Button klicken. Das Leben ist einfach.

Dann wächst das System. Zwanzig Redakteure über mehrere Abteilungen. Ein ERP, das täglich Tausende Produktupdates pusht. Background Worker, die Thumbnails, PDFs und Suchindex-Updates generieren. Mehrere Output-Kanäle, die Produkte für unterschiedliche Zielgruppen ziehen. Eine Suchmaschine, die jede Änderung synchronisiert.

Und plötzlich bricht alles auf eine Weise, die niemand vorhergesehen hat.

Wir haben das hautnah bei einem Enterprise-PIM-Projekt für einen B2B-Hersteller in der DACH-Region erlebt. Das System hatte mehrere Event Subscriber, diverse Async Worker, eine ERP-Integration mit täglichen Importen und mehrere Output-Kanäle für verschiedene Geschäftsanforderungen. Das Team war auf 20+ Redakteure gewachsen, und die ursprüngliche Architektur brach unter ihrem eigenen Gewicht zusammen.

Das Kernproblem: Pimcores save() ist für menschliche Redakteure designt, nicht für Enterprise-Systeme mit mehreren automatisierten Prozessen, die um dieselben Daten konkurrieren.

Dieser Artikel beschreibt, wie wir die Workflow-Architektur von Grund auf neu designt haben. Die Patterns hier gelten für jede Pimcore-Installation, die über die Basics hinauswächst. Für breiteren Kontext, wie wir Systemarchitektur und PIM-Implementierungen angehen, liefern diese Guides nützlichen Hintergrund.

Warum Pimcores Default-Modell bei Skalierung versagt

Pimcores Object-Persistenz läuft über einen einzigen Einstiegspunkt:

$product->save();

Das löst eine implizite Verhaltenskette aus:

save()
  -> PRE_UPDATE Event feuert (alle Subscriber, synchron)
  -> update() persistiert VOLLSTÄNDIGEN Objektzustand in Published-Tabellen
  -> saveVersion() erstellt einen Versions-Snapshot
  -> POST_UPDATE Event feuert (alle Subscriber, synchron)
  -> Jeder Subscriber kann Async Messages dispatchen
  -> Jeder Message Handler kann save() erneut aufrufen
  -> Schleife bis Supervisor oder Error sie unterbricht

Jedes save() persistiert das gesamte Objekt. Nicht das Feld, das sich geändert hat. Das gesamte Objekt. Dieses Design funktioniert gut für menschliche Redakteure, die gelegentlich Änderungen machen. Es versagt, wenn du folgendes hast:

Bevor wir diese Probleme gelöst haben, dauerte ein Produktimport Stunden und erzeugte massive Message Queues. Nach dem Architektur-Redesign verarbeitet derselbe Import in Minuten mit kontrollierten, vorhersagbaren Side Effects.

Das Drei-Schichten-State-Modell

Die zentrale Architekturentscheidung: drei Concerns separieren, die Pimcore in einen zusammenwirft.

┌─────────────────────────────────────────────────────────┐
│                                                         │
│  Layer 1: OPERATIONAL WORKFLOW (human process)          │
│  ┌─────┐  ┌───────────┐  ┌──────────┐  ┌──────────┐  │
│  │ NEW │─▶│IN_PROGRESS│─▶│IN_REVIEW │─▶│ APPROVED │  │
│  └─────┘  └───────────┘  └──────────┘  └────┬─────┘  │
│                  ▲            │               │        │
│                  └────────────┘               │        │
│                (feedback loop)                ▼        │
│                                        ┌───────────┐  │
│                                        │ PUBLISHED  │  │
│                                        └─────┬─────┘  │
│                                                        │
├────────────────────────────────────────────────────────┤
│                                                        │
│  Layer 2: PUBLICATION STATE (Pimcore built-in)         │
│  published = true  → product is live on website        │
│  published = false → not visible on any channel        │
│  Draft versions → edits saved without publishing       │
│                                                        │
├────────────────────────────────────────────────────────┤
│                                                        │
│  Layer 3: CHANNEL ELIGIBILITY (computed, NOT stored)   │
│  isChannelReady = published=true                       │
│                   AND workflow=PUBLISHED                │
│                   AND ChannelValidator.passes()         │
│                   AND not archived                      │
│                                                        │
└─────────────────────────────────────────────────────────┘

Layer 1: Operativer Workflow

Ein Workflow auf der Product-Klasse über Pimcores Symfony-Workflow-Integration. Typ: state_machine (ein Place gleichzeitig).

Dieser Workflow beantwortet: Wem gehört das Produkt gerade? In welcher Phase ist es? Wer handelt als nächstes?

pimcore:
    workflows:
        product_lifecycle:
            enabled: true
            label: 'Product Lifecycle'
            type: 'state_machine'
            supports:
                - 'Pimcore\Model\DataObject\Product'
            initial_markings:
                - 'new'
            marking_store:
                type: state_table

            places:
                new:
                    label: 'New'
                    color: '#90CAF9'
                    permissions:
                        - save: true
                          publish: false
                in_progress:
                    label: 'In Progress'
                    color: '#FFE082'
                    permissions:
                        - save: true
                          publish: false
                in_review:
                    label: 'In Review'
                    color: '#FFAB91'
                approved:
                    label: 'Approved'
                    color: '#A5D6A7'
                published:
                    label: 'Published'
                    color: '#4CAF50'
                archived:
                    label: 'Archived'
                    color: '#BDBDBD'

Die Unterscheidung, die die meisten Teams übersehen: Es gibt keinen REJECTED-State. Ablehnung ist eine Transition zurück zu IN_PROGRESS mit einem Pflichtkommentar, der in Notes & Events gespeichert wird. Das hält den Workflow sauber und den Review-Prozess als Schleife, nicht als Sackgasse.

Layer 2: Publikationsstatus

Das ist KEIN Workflow. Das nutzt Pimcores bestehende Mechanismen:

• published = true steuert die Website-Sichtbarkeit
• Pimcore-Versionierung erstellt Snapshots bei jedem Save
• Draft-Versionen lassen Redakteure arbeiten, ohne die Live-Seite zu beeinflussen
• Veröffentlichen promoted eine bestimmte Version als Live-Version

Das ergibt Git-ähnliches Verhalten:

Wenn ein Redakteur speichert ohne zu veröffentlichen, wird nur eine Draft-Version erstellt. Die Published-Tabellen bleiben unverändert. Die Live-Website sieht niemals halbfertige Arbeit.

Layer 3: Channel Eligibility (berechnet, nicht gespeichert)

Das ist die Entscheidung, die eine ganze Klasse von Bugs eliminiert hat. Channel Readiness (ob ein Produkt für einen bestimmten Output-Kanal wie einen Marketplace-Feed, eine Export-Pipeline oder eine Partner-API berechtigt ist) ist KEIN gespeichertes Feld auf dem Produkt. Sie wird aus dem aktuellen Zustand berechnet.

class ProductOutputEligibility
{
    public function isChannelReady(Product $product, string $channel): bool
    {
        return $product->isPublished()
            && $this->workflowState->getCurrentState($product) === 'published'
            && !$this->workflowState->isArchived($product)
            && $this->channelValidator->isValid($product, $channel);
    }

    public function getBlockingErrors(Product $product, string $channel): array
    {
        $errors = [];
        if (!$product->isPublished()) {
            $errors[] = 'Product must be published';
        }
        // ... Workflow-State, Archiviert prüfen
        return array_merge($errors, $this->channelValidator->getErrors($product, $channel));
    }
}

Warum berechnet besser ist als ein gespeichertes Status-Feld:

Das alte System nutzte Hacks, bei denen Produkte unveröffentlicht werden mussten, um sie für bestimmte Kanäle vorzubereiten. Das brach die Website-Sichtbarkeit jedes Mal. Der berechnete Ansatz eliminiert dieses Pattern komplett.

Mehr darüber, wie wir Data-Engineering-Pipelines und kanalspezifischen Output denken, findest du auf dieser Service-Seite.

Field Ownership: Wer darf was schreiben

Die zweite kritische Architekturentscheidung: Nicht alle Felder sind gleich. Manche gehören Redakteuren, manche Maschinen, manche beiden mit Regeln.

pimtx:
    field_ownership:
        Product:
            editor_owned:
                - name
                - description
                - shortDescription
                - images
            system_owned:
                - thumbnail
                - searchIndex
                - checksum
                - lastSyncTimestamp
            shared:
                - categories
                - price
                - availability
                - status

Field Ownership bestimmt:

• Welche Felder Change Detection für welche Operationen auslösen
• Welche Konfliktlösungsstrategien gelten
• Ob Partial Update für ein gegebenes Feld sicher ist
• Was in der Business- vs. Technical-Audit-Ansicht erscheint

Ohne Field Ownership kann ein ERP-Import manuell kuratierten Content überschreiben. Mit Field Ownership berührt der Import nur die Felder, die ihm gehören. Shared Fields nutzen eine konfigurierte Konfliktstrategie (Retry, Skip, Fail oder Merge-if-Safe).

Dieses Pattern ist zentral dafür, wie wir PimTx gebaut haben, unseren Open-Source Pimcore Transaction und Concurrency Layer. Das Consulting-Team hat mehreren Enterprise-Pimcore-Kunden geholfen, genau dieses Pattern zu implementieren.

Event-Subscriber-Steuerung: Die Kaskade stoppen

Das gefährlichste Pattern in Pimcore-Enterprise-Systemen ist die Save-Kaskade. Ein Save triggert 13 Event Subscriber. Jeder dispatcht Async Messages. Jeder Message Handler lädt das Produkt, ändert ein Feld und speichert. Jeder Save triggert wieder 13 Subscriber.

Der EventSubscriberSupervisor ist ein process-scoped Singleton, der steuert, welche Subscriber aktiv sind:

// Alle App-Level Event Subscriber vor Worker-Save deaktivieren
$this->eventSubscriberSupervisor->disableAll();

try {
    $product->setQrCode($generatedAsset);
    $product->save();
} finally {
    $this->eventSubscriberSupervisor->enableAll();
}

Die Reihenfolge der Operationen ist entscheidend. Wenn du sie falsch machst, erzeugst du genau die Schleife, die du verhindern willst:

// FALSCH: Events werden VOR dem Save reaktiviert
$this->eventSubscriberSupervisor->disableAll();
try {
    // Arbeit erledigen...
} finally {
    $this->eventSubscriberSupervisor->enableAll(); // hier reaktiviert
}
$product->save(); // Save feuert Events, Schleife startet

// RICHTIG: Save passiert INNERHALB des deaktivierten Scopes
$this->eventSubscriberSupervisor->disableAll();
try {
    $product->setQrCode($generatedAsset);
    $product->save(); // Save hier, Events unterdrückt
} finally {
    $this->eventSubscriberSupervisor->enableAll();
}

Das ist process-scoped. Es deaktiviert Subscriber nur innerhalb desselben PHP-Prozesses. Andere Worker-Pods haben eigene Supervisor-Instanzen. Aber da der Save keine neuen Messages dispatcht (Subscriber sind deaktiviert), erreichen keine neuen Messages andere Worker.

Versionsverwaltung: Die Explosion verhindern

Im ursprünglichen System erstellte jeder Worker-Save eine Version. Mit 6 Workern, die jede Produktänderung verarbeiten, erzeugte ein einzelner menschlicher Edit 6+ Versionen, die niemand brauchte. Über die Zeit sammelten Produkte Tausende Versionen an, verbrauchten Speicher und machten die Versionshistorie für tatsächliches Auditing unbrauchbar.

Die Lösung: ein Scoped Version Guard, der unnötige Versionen während System-Operationen unterdrückt.

// PimTx Scoped Version Guard (referenzgezählt)
$versionGuard = $this->versionGuardFactory->create();
$versionGuard->suppress();

try {
    // Mehrere System-Operationen, keine Versionen erstellt
    $product->setThumbnail($thumbnailAsset);
    $product->save();

    $product->setChecksum($newChecksum);
    $product->save();
} finally {
    $versionGuard->restore();
}

Anders als Pimcores globales Version::disable() ist dieser Guard referenzgezählt und scoped. Verschachtelte Operationen funktionieren korrekt. Ein Guard, der restored, aktiviert nicht versehentlich Versionen für eine übergeordnete Operation, die sie noch unterdrückt braucht.

Das Ergebnis: Editor-Saves erstellen Versionen (Audit Trail bleibt erhalten). Worker-Saves erstellen stattdessen Operation-Log-Einträge (volle Observability ohne Version-Bloat). Du kannst genau sehen, was jeder Worker wann und an welchen Feldern getan hat, ohne durch 4.000 nutzlose Versionseinträge zu scrollen.

ERP-Import-Sicherheit

Der politisch sensibelste Teil jeder PIM-Architektur: Was passiert, wenn das ERP Daten pusht.

Im ursprünglichen System überschrieb der ERP-Import alles. Manuell kuratierte Beschreibungen, sorgfältig gesetzte Kategorien, redaktionellen Status. Alles weg nach einem nächtlichen Import.

Die Architekturlösung kombiniert Field Ownership mit importspezifischen Regeln:

# ERP-Import Field Mapping
# GESCHÜTZTE Felder (nicht im Mapping, Import kann sie nicht anfassen):
#   - description (editor-owned)
#   - shortDescription (editor-owned)
#   - images (editor-owned)
#   - workflow state (prozessgesteuert)

# IMPORTIERTE Felder (ERP-owned):
#   - erpId (Resolver Key)
#   - sku
#   - dimensions
#   - weight
#   - ean

# GETEILTE Felder (Import aktualisiert, aber Change Detection greift):
#   - categories (Merge-Strategie)
#   - price (Überschreiben mit Benachrichtigung)
#   - availability (Überschreiben mit Change-Impact-Check)

Wenn ein ERP-Import ein geschäftskritisches Feld bei einem veröffentlichten Produkt ändert, flaggt die Change-Impact-Detection es automatisch zur Überprüfung. Der Import muss nichts über redaktionelle Workflows wissen. Das Field-Ownership-System kümmert sich darum.

Kritische Sicherungen:

1. Channel Eligibility wird automatisch neu berechnet (berechnet, nicht gespeichert)
2. Workflow-State wird niemals durch Importe zurückgesetzt
3. Editor-owned Felder sind nicht im Import-Mapping
4. Shared Fields nutzen Konfliktstrategien mit Benachrichtigung
5. Der EventSubscriberSupervisor verhindert import-getriggerte Kaskaden

Was passiert, wenn ein Live-Produkt bearbeitet wird

Das ist der kritischste benutzerseitige Flow. Ein Redakteur muss ein Live-Produkt aktualisieren, ohne die Website oder einen Output-Kanal zu beschädigen.

1. Produkt ist im PUBLISHED-State, published=true, live auf der Website
2. Redakteur öffnet Produkt, ändert Beschreibung
3. Redakteur klickt "Speichern" (nicht "Veröffentlichen")
4. Pimcore erstellt NUR eine DRAFT-VERSION
5. Published-Tabellen bleiben unverändert
6. Website liefert weiterhin die aktuelle veröffentlichte Version
7. Change-Impact-Detection läuft:
   - Wenn geschäftskritische Felder geändert: zuständige Teams benachrichtigt
   - Wenn nur interne/SEO-Felder geändert: keine Benachrichtigung
8. Redakteur arbeitet weiter am Draft
9. Wenn bereit: zur Überprüfung einreichen (IN_REVIEW)
10. Reviewer genehmigt: Transition zu APPROVED
11. Release Manager veröffentlicht: Draft wird zu Live promoted
12. Workflow kehrt zu PUBLISHED zurück
13. Channel Eligibility wird automatisch neu berechnet

Die Website sieht niemals halbfertige Arbeit. Kein Output-Kanal wird durch Work-in-Progress-Änderungen beschädigt. Alles ist versionskontrolliert, auditierbar und rückgängig machbar.

Das ist genau die Art von Custom-Software-Architektur, die wir für Enterprise-Kunden bauen. Wenn du Hilfe bei der Planung eines Workflow-Redesigns brauchst, fordere ein Angebot an oder sprich mit unserem Consulting-Team.

Change-Impact-Detection

Nicht alle Änderungen sind gleich. Ein Redakteur, der einen Tippfehler im SEO-Text korrigiert, sollte kein Channel-Review auslösen. Ein Redakteur, der das Hauptproduktbild austauscht, schon.

Das Change-Detection-System klassifiziert Änderungen nach Impact:

class ChangeImpactClassifier
{
    private const BUSINESS_CRITICAL_FIELDS = [
        'description',
        'shortDescription',
        'images',
        'technicalAttributes', // Classification Store
        'price',
        'availability',
        'categories',
    ];

    private const NON_IMPACTFUL_FIELDS = [
        'seoText',
        'searchKeywords',
        'internalTags',
        'lastSyncTimestamp',
    ];

    public function classify(Product $product, array $changedFields): ChangeImpact
    {
        $critical = array_intersect($changedFields, self::BUSINESS_CRITICAL_FIELDS);

        if (count($critical) > 0) {
            return ChangeImpact::BUSINESS_CRITICAL;
        }

        $nonImpactful = array_intersect($changedFields, self::NON_IMPACTFUL_FIELDS);
        if (count($nonImpactful) === count($changedFields)) {
            return ChangeImpact::NON_IMPACTFUL;
        }

        return ChangeImpact::STANDARD;
    }
}

Implementierung: Ein PRE_UPDATE Subscriber lädt die vorherigen Versionsdaten, vergleicht Feld für Feld mit dem aktuellen Zustand, klassifiziert Änderungen nach Business Impact und speichert die Änderungszusammenfassung als Note auf dem Objekt.

Validierungsregeln für Channel Readiness

Da Channel Eligibility berechnet wird, definiert der Validator, was "bereit" pro Kanal bedeutet:

class ChannelValidator
{
    public function isValid(Product $product, string $channel): bool
    {
        return count($this->getErrors($product, $channel)) === 0;
    }

    public function getErrors(Product $product, string $channel): array
    {
        $errors = [];

        // Allgemeine Anforderungen für alle Kanäle
        if (!$product->getMainImage()) {
            $errors[] = 'At least one product image required';
        }

        if (empty($product->getDescription())) {
            $errors[] = 'Description text required in at least one locale';
        }

        // Kanalspezifische Anforderungen
        if ($channel === 'marketplace') {
            if (empty($product->getPrice())) {
                $errors[] = 'Price is required for marketplace export';
            }
            if (empty($product->getCategories())) {
                $errors[] = 'At least one category required for marketplace';
            }
        }

        return $errors;
    }
}

Die UI zeigt genau, was die Eligibility pro Kanal blockiert. Kein Raten, kein "frag den Channel-Manager." Das Produkt besteht die Validierung oder das System sagt dir, warum nicht.

Wie wir ähnliche Validierungs-Patterns in AI-Workflow-Design und AI Governance handhaben, behandeln diese Guides.

Der Transaction Layer (PimTx)

All diese Patterns kommen in PimTx zusammen, dem Transaction und Concurrency Layer, den wir als Symfony Bundle gebaut haben. Jeder System-Write wird zu einer expliziten Operation:

// Statt rohem $product->save()
$result = $this->transactionManager->execute(
    OperationContext::for($product)
        ->name('qr_code_generation')
        ->systemField('qrCode')
        ->lock(LockType::OPERATION)
        ->version(VersionPolicy::SUPPRESS_PIMCORE_VERSION)
        ->events(EventPolicy::SUPPRESS)
        ->conflict(ConflictStrategy::RETRY)
        ->maxRetries(3)
        ->idempotencyKey("qr:{$product->getId()}:{$locale}")
        ->mutate(function (Product $p) use ($qrAsset) {
            $p->setQrCode($qrAsset);
        })
);

if ($result->wasSkipped()) {
    // Idempotent: gleiche Operation bereits ausgeführt
    $this->logger->info('QR generation skipped', [
        'reason' => $result->skipReason,
        'product_id' => $product->getId(),
    ]);
}

Was diese Deklaration bewirkt:

• Erwirbt einen operation-scoped Lock (verhindert parallele QR-Generierung für dasselbe Produkt)
• Prüft Idempotenz (gleiche Operation mit gleichem Key läuft nicht zweimal)
• Unterdrückt Versionserstellung (Operation wird im PimTx Audit geloggt, nicht in Pimcore-Versionen)
• Unterdrückt Event Subscriber (verhindert kaskadierende Saves)
• Retry bei Konflikt (wenn ein anderer Worker das Produkt zwischen Load und Save geändert hat)
• Gibt ein strukturiertes Ergebnis zurück (Erfolg, übersprungen, Konflikt gelöst oder fehlgeschlagen)

Die Governance-Regel: Jede Nicht-Editor-Mutation, die Pimcore über unmanaged save() erreicht, gilt als out of policy. System-Code muss durch den Transaction Layer gehen. Ohne diese Regel umgehen Teams den Layer langsam und reproduzieren dieselben Incidents.

Mehr darüber, wie wir Systeme wie dieses in Produktion überwachen und monitoren, findest du in unserem AI-Observability-Guide, der ähnliche Patterns für strukturiertes Logging und Tracing behandelt.

Benachrichtigungsarchitektur

Pimcores Workflow unterstützt Benachrichtigungen bei Transitions:

Benachrichtigungen tragen Kontext: Was hat sich geändert, wer hat es geändert, welche Felder waren betroffen und der Business-Impact-Level. Nicht einfach nur "Produkt 12345 wurde aktualisiert."

Häufige Fallstricke

1. Mehrere Workflows verwenden. Ein Workflow pro Product-Klasse. Mehrere Workflows erzeugen State-Konflikte und Permission-Verwirrung. Channel Readiness wird über berechnete Eligibility gehandhabt, nicht über separate Workflows.

2. Channel-Status als Feld speichern. Jedes gespeicherte Status-Feld veraltet in dem Moment, in dem jemand ein Bild löscht oder ein Pflichtattribut ändert. Berechne Eligibility aus dem aktuellen Zustand.

3. Field Ownership überspringen. Ohne Field Ownership konkurriert jeder Import, Worker und Redakteur um dieselben Felder über denselben save()-Pfad. Definiere, wem was gehört, bevor die erste Codezeile geschrieben wird.

4. Version::disable() global verwenden. Dieses globale statische Flag funktioniert nicht, wenn mehrere Operationen gleichzeitig laufen. Nutze referenzgezählte, scoped Version Guards.

5. Imports den Workflow-State ändern lassen. ERP-Imports sollten Datenfelder aktualisieren, nicht Prozess-States. Workflow-State wird durch menschliche Transitions und automatische Change Detection gesteuert.

6. Review bei jeder Änderung auslösen. Klassifiziere Änderungen nach Impact. SEO-Text-Updates sollten keine Business-Reviews auslösen. Nur geschäftskritische Feldänderungen sollten das tun.

7. Redaktionelles Speichern nicht vom System-Speichern trennen. Die größte Quelle von Event Storms. Worker-Saves und Editor-Saves brauchen unterschiedliche Pfade mit unterschiedlichen Side-Effect-Policies.

8. Die Save-Schleife ignorieren. Ein unkontrollierter Subscriber kann einen Produktimport in ein mehrstündiges Desaster verwandeln. Der EventSubscriberSupervisor ist nicht optional.

Implementierungs-Roadmap

Phase 1: Fundament (Workflow + Channel Eligibility)

• Workflow-States und Transitions in YAML definieren
• Berechnete Channel Eligibility implementieren (gespeicherte Status-Felder ersetzen)
• Workflow-Permissions pro State konfigurieren
• Basis-Change-Impact-Detection (geschäftskritisch vs. nicht-impactful)

Phase 2: Governance (Field Ownership + Event-Steuerung)

• Field-Ownership-Registry definieren (Editor/System/Shared pro Feld)
• EventSubscriberSupervisor implementieren
• Scoped Version Guards für Worker-Operationen hinzufügen
• ERP-Import-Feldschutz konfigurieren

Phase 3: Volle Produktion (Transaction Layer + Benachrichtigungen)

• PimTx Transaction Layer deployen
• Idempotenz für alle Worker-Operationen hinzufügen
• Benachrichtigungsarchitektur implementieren
• Vollständiges Audit-Logging mit Business- und Technical-Views
• Regressionstests über alle Worker und Integrationen

Unsere Trust- und Compliance-Übersicht beschreibt, wie wir Systemgarantien für Enterprise-Kunden dokumentieren.

Wichtigste Erkenntnisse

• Drei Concerns in drei Layers separieren. Workflow steuert den Prozess. Das Published-Flag steuert Web-Sichtbarkeit. Channel Eligibility wird aus dem aktuellen Zustand berechnet. Sie zu vermischen erzeugt Hacks, die alles kaputt machen.

• Field Ownership ist bei Skalierung nicht optional. Ohne sie überschreibt jeder Worker, Import und Redakteur die Arbeit der anderen über denselben save()-Pfad. Definiere, wem welche Felder gehören, bevor die erste Workflow-Transition geschrieben wird.

• Event-Subscriber-Steuerung verhindert kaskadierende Desaster. Ein unkontrollierter Save kann Tausende Messages auslösen. Der EventSubscriberSupervisor ist der einzelne wirkungsvollste Fix für Pimcore-Performance bei Skalierung.

• Berechne, speichere nicht die Channel Readiness. Jedes gespeicherte Status-Feld veraltet. Berechne Eligibility aus dem aktuellen Published-State, Workflow-State und den Validierungsregeln. Keine Synchronisation erforderlich, keine veralteten Daten möglich.

• Version Guards bewahren Audit Trails ohne die Explosion. Editor-Saves erstellen Versionen. Worker-Saves erstellen Operation Logs. Gleiche Observability, ein Hundertstel des Speichers.

• Pimcore wrappen, nicht forken. PimTx steuert alle System-Writes über ein explizites Operation-Modell. Es wrapped $object->save() mit Guards. Es ersetzt oder überschreibt Pimcore Core nicht. Upgrades bleiben sauber.

Wir haben PimTx als Open-Source Symfony Bundle für genau diese Patterns gebaut. Wenn du eine Enterprise-Pimcore-Installation betreibst und auf diese Skalierungsprobleme stößt, decken unsere AI- und Data-Engineering-Services den gesamten Stack ab, vom Architecture Review bis zum Production Deployment.

Bereit, deine Pimcore-Workflow-Architektur neu zu designen? Sprich mit unserem Team oder fordere ein Angebot an.