Prullenbak, timing en activiteiten in de SuluEventBundle

Op 24 september werd de Prullenbak geïntroduceerd. Verwijderde evenementen en locaties worden naar de prullenbak van Sulu verplaatst en kunnen van daaruit worden hersteld. Hiervoor schrijft de bundel een eigen handler. Wanneer een item wordt verwijderd, worden de titel, tekst, afbeelding, URL en aanvullende gegevens (SEO en uittreksel) opgeslagen, en deze worden gebruikt om het evenement te reconstrueren wanneer het wordt hersteld. Ook de URL wordt daarbij opnieuw aangemaakt; anders zou het evenement weliswaar worden hersteld, maar niet via het adres toegankelijk zijn.

Op dezelfde dag volgde een bugfix voor het herstelproces.

Sulu houdt een logboek bij van wie welke inhoud wanneer heeft aangemaakt, bewerkt of verwijderd. Je eigen inhoud verschijnt daar alleen als je deze acties aan het logboek doorgeeft. De bundel doet dit voor negen acties: aangemaakt, gewijzigd, gepubliceerd, ingetrokken, verwijderd, hersteld, gekopieerd naar een andere taal, en de twee tijdgestuurde varianten van publiceren en intrekken.

Voor redacteuren is dit een voordeel waarvan je pas beseft dat je het nodig hebt als het moment daar is: als je je afvraagt waarom een gebeurtenis plotseling is verdwenen of wie deze heeft gepubliceerd, vind je het antwoord in het logboek.

Met de Sulu Automation Bundle kunnen processen op een bepaald tijdstip worden geactiveerd. De SuluEventBundle biedt hiervoor twee handlers: Publish en Withdraw. Binnen de gebeurtenis is er een tabblad ‘Automation’ waar je het tijdstip en de actie kunt instellen. Zodra het opgegeven tijdstip is bereikt, wijzigt de handler de status van de gebeurtenis en registreert de actie in het activiteitenlogboek.

In Sulu 3 heb ik de tijdregeling in september 2026 opnieuw geïmplementeerd.

Op een website wil je vaak alleen aankomende evenementen op één plek weergeven en een archief met eerdere evenementen op een andere plek. Mijn eerste oplossing op 5 oktober bestond uit twee extra Smart Content Providers: één voor eerdere evenementen en één voor aankomende evenementen, elk met een eigen repository-klasse.

Drie dagen later heb ik ze weer verwijderd. Smart Content herkent filtertypes standaard, en deze kunnen binnen één enkele provider worden gedefinieerd. Sindsdien kunnen redacteuren in het Smart Content-veld kiezen tussen aankomende en eerdere evenementen, en is er nu slechts één providerklasse en één query. Dit heeft de code met ruim 60 regels verkort.

Het zijn juist dit soort omwegen waar ik het meest van leer: voordat ik iets nieuws bouw, is het de moeite waard om te controleren of Sulu daar al een oplossing voor klaar heeft.

Daarnaast zijn er in deze periode een aantal kleinere functies ontwikkeld:

• Een linkprovider waarmee redacteuren vanuit de teksteditor naar een gebeurtenis kunnen linken.
• Een Twig-uitbreiding die gebeurtenissen omzet en lijsten met gebeurtenissen retourneert.
• Afbeelding en URL per taal: sinds 26 september zijn deze opgenomen in de vertaling van het evenement.
• Een voorbeeldsjabloon voor de afzonderlijke weergave van een evenement.
• Indexering voor MassiveSearch, met correcties in oktober en november.

Sinds 24 september worden tests niet langer via Travis uitgevoerd, maar via GitHub Actions.

In 2024 lag de nadruk nog steeds op onderhoud: in januari werd het systeem geüpdatet naar Symfony 6.4 en in augustus naar Symfony 7. Ook in augustus werd er een pull-verzoek ingediend door davidgorges, waardoor de query's compatibel werden met PostgreSQL. De kalender volgde in het najaar van 2025. Dit is het onderwerp van het volgende bericht.

Eerder: De eerste paar weken van de SuluEventBundle.

Repository: manuxi/SuluEventBundle op GitHub