PHPackages                             kaliop/ezworkflowenginebundle - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Utility &amp; Helpers](/categories/utility)
4. /
5. kaliop/ezworkflowenginebundle

ActiveSymfony-bundle[Utility &amp; Helpers](/categories/utility)

kaliop/ezworkflowenginebundle
=============================

Kaliop eZ-Workflow-Engine Bundle

2.1.0(3y ago)73.4k3[3 issues](https://github.com/kaliop-uk/ezworkflowenginebundle/issues)GPL-2.0PHPPHP &gt;=5.6

Since Jun 8Pushed 3y ago4 watchersCompare

[ Source](https://github.com/kaliop-uk/ezworkflowenginebundle)[ Packagist](https://packagist.org/packages/kaliop/ezworkflowenginebundle)[ GitHub Sponsors](https://github.com/sponsors/tanoconsulting)[ RSS](/packages/kaliop-ezworkflowenginebundle/feed)WikiDiscussions main Synced 1mo ago

READMEChangelog (7)Dependencies (3)Versions (11)Used By (0)

Kaliop eZWorkflowEngine Bundle
==============================

[](#kaliop-ezworkflowengine-bundle)

A workflow engine for eZPublish5 / eZPlatform 1 and 2.

How it works, in 10 lines of configuration
------------------------------------------

[](#how-it-works-in-10-lines-of-configuration)

Example workflow definition:

```
-
    type: workflow
    signal: LocationService\HideLocationSignal
    run_as: admin

-
    type: content
    mode: update
    new_remote_id: pippo
    match:
        content_id: workflow:signal:content_id

```

In plain words, this means: when any content is hidden, set its 'remote\_id' value to 'pippo'.

More examples of how "real-life" workflows do look like:

- [Add a screenshot automatically when a video file is uploaded](Resources/doc/Examples/AddScreenshot.yml)
- [Fill contents with 'lorem ipsum' text using an online service](Resources/doc/Examples/FillComments.yml)
- [Fire a mail alert if an editor moves content that he's not supposed to alter](Resources/doc/Examples/MailOnMove.yml)

Getting started
---------------

[](#getting-started)

1. Install the bundle using Composer, enable `EzWorkflowEngineBundle` in your application Kernel (if you had not previously installed the eZMigrationBundle, you should enable as well `EzMigrationBundle` - Composer will have downloaded it automatically for you, but not enabled it)
2. Create a workflow definition in any bundle you want by using the dedicated command

    ```
     php bin/console kaliop:workflows:generate myBundle

    ```
3. Edit the workflow definition

    - change the value for the 'signal' element to the name of an existing eZPublish Signal (see )
    - add the required steps to your workflow (see the docs from the kaliop migration bundle for possible steps definitions)
4. test that the workflow is listed as available

    ```
     php bin/console kaliop:workflows:debug

    ```
5. connect to the Administration Interface, execute the desired content modification action. (Note: if you are using the Legacy Admin interface, you will need to execute extra work. Read the dedicated chapter below)
6. check that the workflow you defined did execute

    ```
     php bin/console kaliop:workflows:status

    ```

    Also, if you have enabled 'debug' level logging for Symfony, you will find that any time an eZPublish signal is emitted, the workflow engine add to the log 1 or 2 lines with information about its actions.
7. set up a cron job that will pick up and restart any suspended workflow by executing, fe. every 5 minutes, the following:

    ```
     php bin/console kaliop:workflows:resume -n

    ```
8. set up a cron job that will clean up the workflow table in the database by executing, fe. daily, the following:

    ```
     php bin/console kaliop:workflows:cleanup

    ```
9. once your workflow is debugged and tested, don't forget to commit the workflow definition file as part of your source code ;-)

Frequently asked questions
--------------------------

[](#frequently-asked-questions)

Q: how can I find out which content/location the current workflow is dealing with?

A: the workflow engine makes available as references the parameters found in the Signal which triggers the workflow. Ex: `workflow:signal:content_id`. Once you have a content or location id, you can use the steps 'content/load' and 'location/load' to get hold of the whole thing, and set new references to its other attributes, eg:

```
    -
        type: content
        mode: load
        match:
            content_id: workflow:signal:content_id
        references:
            -
                identifier: the_object_name
                attribute: name

```

Q: how can I make a workflow act only on some specific content(s)?

A: use a workflow/cancel step with an 'unless' condition

Q: are there steps which are specific to workflows, besides those found in the migrations bundle?

A: yes. Take a look at [the docs](Resources/doc/DSL/Workflow.yml)

Q: how can I troubleshoot workflows?

A: by default workflow execution steps and triggers are logged in detail as part of the Symfony log, at DEBUG level. If you want to have a separate log file dedicated to troubleshoot only workflow events, you can add to your config.yml something similar to fe.

```
    monolog:
        handlers:
            workflow_log:
                type: stream
                path: "%kernel.logs_dir%/%kernel.environment%.workflow.log"
                level: debug
                channels: [ ez_workflow ]

```

Q: can I suspend a workflow and restart it later?

A: yes, just as you would with a migration (see the doc in the migrationbundle for details). NB: when a workflow is restarted, all the reference values that it had originally will be restored, however it might be that the contents that they refer to have changed in the meantime.

Q: does the workflow engine emit Symfony Events when workflows are run?

A: yes. Currently, the following events are emitted:

- ez\_workflow.before\_execution
- ez\_workflow.step\_executed
- ez\_workflow.workflow\_aborted
- ez\_workflow.workflow\_suspended

Q: can the workflow engine be used for scenarios where user interaction is required (eg. Content Approval ?)

A: not yet, and possibly never in a "good enough" way. The main reason for this is that all the eZPublish Signals are triggered 'after' an action takes place. As such, it is hard to keep a content in 'for approval' state after it has already been published. The 2nd reason is that at the moment there is no way to allow GUI interactions with existing workflows (but this could be easily worked around with dedicated steps)

Q: can I manage the workflows and triggers via a GUI, just like I used to do in eZPublish 4?

A: no, but you have command line tools to help with debugging and troubleshooting

Q: why are you storing the workflow definitions in configuration files instead of using the database?

A: this makes it much easier to have consistent workflows definitions across development/test/production environments, as well as Continuous Integration scenarios

Q: are workflow definitions cached ?

A: yes. For speed of execution, the bundle caches the parsed workflow definitions attached to each signal. This means that, if you are running Symfony in non-dev mode, you will have to clear the Symfony cache each time that you modify the definition of an existing workflow or add/remove workflows (using f.e. the `cache:clear` command)

Integration with the Legacy Administration Interface
----------------------------------------------------

[](#integration-with-the-legacy-administration-interface)

By default, editing actions carried out in the Legacy Administration Interface do not trigger execution of the workflows defined in your yml files. It is however possible to do so, with just a little bit of configuration work:

- enable the extension `ezworkflowenginebridge` in settings.ini.override.php
- clear caches
- in the Administration Interface, create custom Legacy Workflows and hook them up to Triggers as per the documentation that you will find in the [readme](ezpublish_legacy/ezworkflowenginebridge/README.md)

Running tests
-------------

[](#running-tests)

The bundle uses PHPUnit to run functional tests.

#### Running tests in a working eZPublish / eZPlatform installation

[](#running-tests-in-a-working-ezpublish--ezplatform-installation)

To run the tests:

```
export KERNEL_DIR=app (or 'ezpublish' for ezpublish 5.4/cp setups)
export SYMFONY_ENV=behat (or whatever your environment is)

bin/phpunit --stderr -c vendor/kaliop/ezworkflowenginebundle/phpunit.xml.dist

```

*NB* the tests do *not* mock interaction with the database, but create/modify/delete many types of data in it. As such, there are good chances that running tests will leave stale/broken data. It is recommended to run the tests suite using a dedicated eZPublish installation or at least a dedicated database.

#### Setting up a dedicated test environment for the bundle

[](#setting-up-a-dedicated-test-environment-for-the-bundle)

A safer choice to run the tests of the bundle is to set up a dedicated environment, similar to the one used when the test suite is run on GitHub Actions. The advantages are multiple: on one hand you can start with any version of eZPublish you want; on the other you will be more confident that any tests you add or modify will also pass on GitHub. The disadvantages are that you will need Docker and Docker-compose, and that the environment you will use will look quite unlike a standard eZPublish setup! Also, it will take a considerable amount of disk space and time to build.

Steps to set up a dedicated test environment and run the tests in it:

```
git clone --depth 1 https://github.com/tanoconsulting/euts.git teststack
# if you have a github auth token, it is a good idea to copy it now to teststack/docker/data/.composer/auth.json

# this config sets up a test environment with eZPlatform 2.5 running on php 7.4 / ubuntu jammy
export TESTSTACK_CONFIG_FILE=Tests/environment/.euts.2.5.env

./teststack/teststack build
./teststack/teststack runtests
./teststack/teststack stop

```

You can also run a single test case:

```
./teststack/teststack runtests ./Tests/phpunit/01_CommandsTest.php

```

Note: this will take some time the 1st time your run it, but it will be quicker on subsequent runs. Note: make sure to have enough disk space available.

In case you want to run manually commands, such as the symfony console:

```
./teststack/teststack console cache:clear

```

Or easily get to a database shell prompt:

```
./teststack/teststack dbconsole

```

Or command-line shell prompt to the Docker container where tests are run:

```
./teststack/teststack shell

```

The tests in the Docker container run using the version of debian/php/mysql/eZPlatform kernel specified in the file `Tests/environment/.euts.2.5.env`, as specified in env var `TESTSTACK_CONFIG_FILE`. If no value is set for that environment variable, a file named `.euts.env` is looked for. If no such file is present, some defaults are used, you can check the documentation in ./teststack/README.md to find out what they are. If you want to test against a different version of eZ/php/debian, feel free to:

- create the `.euts.env` file, if it does not exist
- add to it any required var (see file `teststack/.euts.env.example` as guidance)
- rebuild the test stack
- run tests the usual way

You can even keep multiple test stacks available in parallel, by using different env files, eg:

- create a file `.euts.env.local` and add to it any required env var, starting with a unique `COMPOSE_PROJECT_NAME`
- build the new test stack via `./teststack/teststack. -e .euts.env.local build`
- run the tests via: `./teststack/teststack -e .euts.env.local runtests`

[![License](https://camo.githubusercontent.com/cdc33f78bddd7dc4267f3006ecacd2c6fca9af04cc6a83fdb297017a5d9838f2/68747470733a2f2f706f7365722e707567782e6f72672f6b616c696f702f657a776f726b666c6f77656e67696e6562756e646c652f6c6963656e7365)](https://packagist.org/packages/kaliop/ezworkflowenginebundle)[![Latest Stable Version](https://camo.githubusercontent.com/592bd69849863a8be9e7253da6519bd05a916e22d333d8a46b2b0689ad17b4b6/68747470733a2f2f706f7365722e707567782e6f72672f6b616c696f702f657a776f726b666c6f77656e67696e6562756e646c652f762f737461626c65)](https://packagist.org/packages/kaliop/ezworkflowenginebundle)[![Total Downloads](https://camo.githubusercontent.com/0954b5852999102a49f2309e1ca0aeba47adf26ff4f39e37673ab553dd867e89/68747470733a2f2f706f7365722e707567782e6f72672f6b616c696f702f657a776f726b666c6f77656e67696e6562756e646c652f646f776e6c6f616473)](https://packagist.org/packages/kaliop/ezworkflowenginebundle)

[![Build Status](https://github.com/kaliop-uk/ezworkflowenginebundle/actions/workflows/ci.yml/badge.svg)](https://github.com/kaliop-uk/ezmigrationbundle/actions/workflows/ci.yml)[![Scrutinizer Code Quality](https://camo.githubusercontent.com/516ae33469e18111009a74f4c5a5d7ce7e18bbcccdb31530b4fff314e7ff458d/68747470733a2f2f7363727574696e697a65722d63692e636f6d2f672f6b616c696f702d756b2f657a776f726b666c6f77656e67696e6562756e646c652f6261646765732f7175616c6974792d73636f72652e706e673f623d6d61696e)](https://scrutinizer-ci.com/g/kaliop-uk/ezworkflowenginebundle/?branch=main)[![Code Coverage](https://camo.githubusercontent.com/6da8372a423bf6b6ee4e0a134a0d6a98442f0a7e06cedd8f807410187283bc7a/68747470733a2f2f636f6465636f762e696f2f67682f6b616c696f702d756b2f657a776f726b666c6f77656e67696e6562756e646c652f6272616e63682f6d61696e2f67726170682f62616467652e737667)](https://codecov.io/gh/kaliop-uk/ezworkflowenginebundle/tree/main)

###  Health Score

31

—

LowBetter than 68% of packages

Maintenance11

Infrequent updates — may be unmaintained

Popularity25

Limited adoption so far

Community11

Small or concentrated contributor base

Maturity64

Established project with proven stability

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Every ~284 days

Recently: every ~413 days

Total

8

Last Release

1273d ago

Major Versions

1.1.4 → 2.0.02022-10-19

### Community

Maintainers

![](https://www.gravatar.com/avatar/f641f7d6edabf83c56f6c4998b04e6c59a00b46bf51ca6699c31b09f9c948677?d=identicon)[gggeek](/maintainers/gggeek)

---

Top Contributors

[![gggeek](https://avatars.githubusercontent.com/u/308634?v=4)](https://github.com/gggeek "gggeek (1 commits)")

---

Tags

ezplatformezpublishworkflowworkflowezpublishezplatform

###  Code Quality

TestsPHPUnit

### Embed Badge

![Health badge](/badges/kaliop-ezworkflowenginebundle/health.svg)

```
[![Health](https://phpackages.com/badges/kaliop-ezworkflowenginebundle/health.svg)](https://phpackages.com/packages/kaliop-ezworkflowenginebundle)
```

###  Alternatives

[symfony/workflow

Provides tools for managing a workflow or finite state machine

62942.3M170](/packages/symfony-workflow)[yohang/finite

A simple PHP Finite State Machine

1.3k3.5M10](/packages/yohang-finite)[franzl/studio

Develop your Composer libraries with style

1.1k634.5k15](/packages/franzl-studio)[zerodahero/laravel-workflow

Integerate Symfony Workflow component into Laravel.

204815.2k4](/packages/zerodahero-laravel-workflow)[phpmentors/workflower

A BPMN 2.0 workflow engine for PHP

70652.9k4](/packages/phpmentors-workflower)[symbiote/silverstripe-advancedworkflow

Adds configurable workflow support to the CMS, with a GUI for creating custom workflow definitions.

46295.2k7](/packages/symbiote-silverstripe-advancedworkflow)

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)
