6.0.0 

Breaking 

  • Remove support for TYPO3 v12.

Features 

  • Add support for TYPO3 v14.

Fixes 

  • Wrong date creation based on destination.one repeatUntil. Respect the last day, if we import on that day.

    A new test is added to reflect that situation. The workaround for missing DatePeriod::INCLUDE_END_DATE is extended to cover that situation.

  • Fix wrong determination of repeat minutes

    The used value was for month instead of minutes. We now use the correct identifier for minutes.

    This revealed that tests only passed because of the issue. We therefore fix the code to still pass correct tests by working around PHP < 8.2 limitation.

  • A day name that cannot be resolved to a date no longer aborts date creation.

    \Service\DestinationDataImportService\DatesFactory fed every configured day straight to DateTimeImmutable::modify() and used the result unchecked. A value that names no date — schema.org allows entries such as PublicHolidays alongside the weekdays — made modify() fail, and the following setTime() call raised, so the whole import of that event was lost.

    Such a day is now skipped and logged at warning. The remaining days of the same schedule still expand, so one unusable value no longer costs an event its other dates. Schedules built from weekday names behave exactly as before.

    The expression is validated with date_parse() before it reaches modify() , because modify() reports failure differently across the supported PHP versions — a warning plus false up to 8.2, a DateMalformedStringException from 8.3.

  • tx_events_domain_model_date supports soft delete.

    The table's TCA had no delete column configured, so records were removed outright. Importers that reconcile existing dates against a changed schedule could not mark an obsolete date as deleted.

Tasks 

Nothing

Deprecation 

Nothing