phil / scheduled-transitions-bundle

0.1.0-alpha 2026-11-12 14:43 UTC

Requires

• php: >=8.5
• ext-mbstring: *
• doctrine/orm: ^3.7
• phil/resource: ^0.1@dev
• psr/clock: ^1.0
• symfony/config: ^8.2
• symfony/dependency-injection: ^8.2
• symfony/uid: ^8.2

Requires (Dev)

• doctrine/dbal: ^4.5
• doctrine/doctrine-bundle: ^3.3
• doctrine/persistence: ^4.1
• phpunit/phpunit: ^13.4
• psr/log: ^3.0
• symfony/clock: ^8.2
• symfony/console: ^8.2
• symfony/event-dispatcher: ^8.2
• symfony/framework-bundle: ^8.2
• symfony/http-kernel: ^8.2
• symfony/messenger: ^8.2
• symfony/scheduler: ^8.2
• symfony/workflow: ^8.2

Suggests

• symfony/console: For phil:scheduled-transitions:run
• symfony/scheduler: To apply the transitions from Symfony Scheduler
• symfony/workflow: To apply the transitions through a workflow

MIT

• Philippe Gamache

• workflow
• publish
• scheduler
• symfony-bundle

Published on Packagist.org on 2026-11-12 23:52 UTC

README

Publish a page on Monday at nine, unpublish it a month later, without anyone online.

phil/scheduled-transitions-bundle plans transitions for a moment in a Symfony application. A transition is a name, such as publish, unpublish or archive, applied to a resource at a given time. It is kept in Doctrine until it is due, then applied by a TransitionHandler the application writes, or through symfony/workflow with its guards and events. A handler that throws is a failed attempt: the transition stays pending and is tried again at the next run, until its attempts are spent. Planning the same transition twice for a resource moves it instead of doubling it.

It is for an application where editors prepare content ahead of time: an announcement that goes live at a set hour, a promotion that ends on its own, a page that is archived after an event. The bundle knows nothing of what publishing means for a page; the handler or the workflow does.

The bundle runs from Symfony Scheduler, which consumes a message every minute by default, or from phil:scheduled-transitions:run in a cron job when there is no worker. Resources are named through phil/resource. The design keeps the planning, the attempts and the running in the bundle, and leaves the effect of each transition to a port, so one schedule serves every kind of resource.

Status

Part	State
ScheduledTransition, TransitionStatus, the repository port	Implemented and tested
Scheduler: schedule, move, cancel, run what is due; TransitionHandler, RunReport	Implemented and tested
DoctrineScheduledTransitionRepository	Implemented and tested
WorkflowTransitionHandler, SubjectResolver	Implemented and tested
Symfony Scheduler: the phil_transitions schedule; phil:scheduled-transitions:run	Implemented and tested

Documentation

Document	What it covers
Installation	Requirements, registering, configuration, the table.
Scheduling	Scheduling, moving, cancelling, runs and retries.
Handlers	A handler of the application's own; the workflow handler.
Running	Symfony Scheduler, or the command from cron; runs that overlap; a handler that breaks the entity manager.
Extension points	What an application implements, configures, replaces or relies on.
Testing	How the bundle is tested.
Reference	Every type of the bundle.

Quick start

$scheduler->schedule(ResourceReference::of('page', $page->id), 'publish', new DateTimeImmutable('2026-11-09 09:00'));

bin/console messenger:consume scheduler_phil_transitions

Requirements

PHP 8.5 or later with ext-mbstring; Doctrine ORM 3.7; PSR-20; Symfony 8.2's dependency injection, config and UID; phil/resource 0.1 for resource references. Symfony Scheduler and Messenger, Workflow and Console are optional.

Contributing

Contributions are welcome on the PHIL monorepo: read the contribution guide and the code of conduct. Report a vulnerability privately, as the security policy explains, never in a public issue.

License

MIT, © Philippe Gamache, doing business as Le Gnome Archiviste; a Parler Haut Interagir Librement project. See LICENSE.