Ezworkflowenginebundle Laravel Package

Product Decisions This Supports

• Editorial governance and approval workflows on eZ Platform. This bundle adds a configurable workflow layer (states, transitions, guards, events) over eZ Publish 5 / eZ Platform content objects. It directly supports decisions like "do we ship multi-step review/approval before publish?" without commissioning a bespoke state machine.
• Build vs. buy for content lifecycle. It is a thin integration over the Symfony Workflow component plus eZ content model glue. The PM decision it informs is whether to assemble this ourselves (weeks of engineering) or adopt a small OSS bundle (days of integration, with maintenance risk).
• Compliance and regulated publishing use cases. Four-eyes approval, staged publishing, translation/localization review chains, and audit trails of transitions — relevant for healthcare, finance, public sector, and agency/multi-brand editorial teams where "who approved what, when" is a product requirement, not a nice-to-have.
• Roadmap scoping. It clarifies that workflow here means content lifecycle, not feature flags, marketing automation, or BPMN-grade process orchestration. Useful for pushing back on stakeholders who expect a general-purpose workflow engine.
• Platform strategy. Its scope (eZ Platform, not Laravel) is itself a decision input: adopting it signals commitment to the eZ/Ibexa content stack rather than a generic PHP framework path. Worth flagging that this is a Symfony/eZ bundle — any "Laravel package" framing in intake should be corrected before it reaches a roadmap.
• CI/automation and ops ergonomics. Release 2.1.0 adds a --fail action to the kaliop:workflows:workflow command and a --show-path option to kaliop:workflows:debug. These are small but product-relevant: transition-driven workflows can now fail builds/jobs deterministically, and support/ops can inspect the reachable path between states without reading config by hand. Minor input to "can we operate this without a dedicated engineer?"

When to Consider This Package

Consider it when:

• You are already running eZ Publish 5 or eZ Platform (Symfony-based PHP) and need editorial approval chains on content.
• Your workflow can be expressed as a state machine with guards and transitions — review → approve → publish, with role/permission gating.
• You can accept GPL-2.0 (fine for internal/self-hosted use; a real consideration if you distribute a derivative product).
• Your team is comfortable vendoring or forking a low-activity dependency, and you are willing to own patches.
• You want scriptable/CI-friendly workflow operation — the 2.1.0 --fail and --show-path options make it easier to wire transitions into pipelines and to debug stuck content without custom tooling.

Look elsewhere when:

• You are on Laravel — this is not the right fit; use the Symfony Workflow component directly or a Laravel-native alternative. This package will not integrate without significant work, and nothing in 2.1.0 changes that.
• You need vendor support, SLAs, or security patching guarantees. Activity is low and the maintainer base is thin: small star count, effectively no dependents, and a multi-year release gap before this 2.1.0. The release is a positive signal that the project is not abandoned, but it is a handful of CLI improvements, not evidence of a support commitment. Treat it as a reference implementation with occasional maintenance, not a supported product.
• You are on modern Ibexa DXP — verify compatibility explicitly, as the bundle targets legacy eZ versions. 2.1.0 makes no compatibility claims either way.
• You need BPMN-style orchestration, human task inboxes, or cross-system process automation — this is content-scoped and will underdeliver.

Recommended posture: unchanged in substance — adopt only behind a spike that proves compatibility with your exact eZ version; budget for a fork; otherwise use the underlying Symfony Workflow component and build the eZ glue yourself. 2.1.0 slightly lowers the cost of that spike (better debug visibility, CI-friendly transition execution), but it introduces a backward-compatibility change for extenders: WorflowServiceInner::executeMigration / executeMigrationInner now use a new signature, with the old one deprecated but still working. Any fork that subclasses or calls these methods must budget for a follow-up refactor before the deprecated path is removed — a concrete line item in the "cost of ownership" estimate.

How to Pitch It (Stakeholders)

To executives: A small open-source component that lets editors route content through configurable review and approval steps before it goes live — supporting compliance and brand-safety requirements without custom development spend. It has just shipped a minor update (better diagnostics and scriptable transition commands), which tells us the project is still alive, though the maintainer base is thin and there is no vendor support or security-patching guarantee. Low cost, low vendor confidence — appropriate as an accelerator, not a strategic dependency, and we should assume we own it.

To engineering: It is a Symfony Workflow integration for eZ content, giving you states, transitions, guards, and events out of the box and removing bespoke state-machine code from our backlog. Release 2.1.0 is modest: kaliop:workflows:workflow --fail for CI/pipeline use and kaliop:workflows:debug --show-path for tracing reachable transitions. The one thing to note is a BC change for extenders — WorflowServiceInner::executeMigration/executeMigrationInner have a new signature; the old one still works but is deprecated. If we fork, which we should plan on, factor that refactor in with the rest of the GPL-2.0 vendoring work. If we are not on eZ Platform, the honest answer is still to skip it and use Symfony Workflow directly.