Recycle Bin, Timing and Activities in the SuluEventBundle

On 24 September, the Recycle Bin was introduced. Deleted events and venues are moved to Sulu’s Recycle Bin and can be restored from there. To do this, the bundle writes its own handler. When an item is deleted, it saves the title, text, image, URL and additional data (SEO and excerpt), and uses this to reconstruct the event when it is restored. The URL is also recreated in the process; otherwise, the event would be restored but could not be accessed via its address.

A bug fix for the restoration process followed on the same day.

Sulu keeps a log of who created, edited or deleted what content and when. Your own content only appears there if you report these actions to the log. The bundle does this for nine actions: created, modified, published, withdrawn, deleted, restored, copied into another language, and the two time-controlled variants of publishing and withdrawing.

For editors, this is a benefit that you only realise you need when the time comes: if you’re wondering why an event has suddenly disappeared or who published it, you’ll find the answer in the log.

With Sulu’s Automation Bundle, processes can be triggered at a specific time. The SuluEventBundle provides two handlers for this purpose: Publish and Withdraw. Within the event, there is an ‘Automation’ tab where you can set the time and action. When the specified time is reached, the handler changes the event’s status and logs the action in the activity log.

In Sulu 3, I re-implemented the timing control in September 2026.

On a website, you often only want to display upcoming events in one place and an archive of past events elsewhere. My initial solution on 5 October involved two additional Smart Content Providers, one for past events and one for upcoming events, each with its own repository class.

Three days later, I removed them again. Smart Content recognises filter types natively, and these can be defined within a single provider. Since then, editors have been able to choose between upcoming and past events in the Smart Content field, and there is now just one provider class and one query. This reduced the code by a good 60 lines.

It’s from detours like this that I learn the most: before I build something new, it’s worth checking whether Sulu already has a solution ready for it.

In addition, a number of smaller features were developed during this period:

• A link provider that allows editors to link to an event within the text editor.
• A Twig extension that resolves events and returns lists of events.
• Image and URL per language: since 26 September, these have been included in the event’s translation.
• A sample template for the single view of an event.
• Indexing for MassiveSearch, with corrections in October and November.

Since 24 September, tests have no longer been run via Travis, but via GitHub Actions.

In 2024, the focus remained on maintenance: In January, the system was updated to Symfony 6.4, and in August to Symfony 7. Also in August, a pull request was submitted by davidgorges, which made the queries compatible with PostgreSQL. The calendar followed in autumn 2025. This is the subject of the next post.

Previously: The first few weeks of the SuluEventBundle.

Repository: manuxi/SuluEventBundle on GitHub