A new class is added which will add meta tags for dates and events.
The class has an interface which allows it to be replaced via DI to
alter behaviour.
Refactor import regarding data handler. We now also need to add a new
column "keywords". We use the new DataHandler approach.
But that approach only covered relations so far. We therefore refactor
that area to be more generic and use that one for new keywords column.
Relates: #10642
We migrated the part of the import to use DataHandler.
We didn't invest too much time as budgets are low.
Still the bugs are covered with tests and fixed.
Relates: #10782
A new PSR-14 event is added that allows to modify the categories to be
assigned to an event.
The event itself (including already existing categories) as well as the
list of categories to be used after import are available.
It is possible to change the categories to be assigned, e.g. keep some
of the existing categories.
That way it is possible for installations to add custom categories to
events.
Relates: #10623
Destination Data One provides an source info explaining where the data
originally came from.
This is now added to event records and exposed in TYPO3 backend.
That allows editors to check the source and contact corresponding
sources in order to fix broken data.
Relates: #10630
A new PSR-14 event is added that allows to modify the event right before
it is persisted within Destination Data One import.
This for example allows to alter dates, prices, etc.
Improve handling of missing end time in dates.
The pages now receive proper cache tags.
The import now properly clears those cache tags.
That way all corresponding pages will show updated content after import
finished.
We need one test that executes frontend requests and import command.
The separation is therefore removed and tests are streamlined to have a
single parent providing all necessary information and setup.
Dates are vanished and re created during import.
Slugs for dates were generate after whole import was finished.
This is now changed to generate slugs for dates after saving each single
event.
The existing code didn't work with the provided data.
We added a new test case to cover the situation.
We adjusted the existing code to check on the actual rel value instead
of the keys.
It is now possible to create "Import" records in TYPO3 system.
Those records can then be imported via two new commands.
There is no need to configure everything within the command itself.
That allows:
* To allow editors to maintain import configuration.
* Have proper labels, description, csh and UI to create import.
It no longer is necessary to copy UIDs,
instead proper wizards from TCA are available to select pages.
Relates: #9649
The import already worked without category, but triggered a warning.
Tests were extended to always work with category, except in new test
case.
All tests were extended to check for empty logs in the end.
The import now checks whether category should be imported and ignores
further processing if not configured.
Relates: #9542
Destination data provides an attribute "DETAILS_ABGESAGT" to mark an
event as canceled.
We now fetch that info and mark all dates of that event as canceled.
This also contains refactoring of creation of dates within import.
All dates had the same info, and are now created at a single place.
Relates: #9280
The properties should always be ObjectStorage instances.
We streamline the annotation and initialization to ensure exactly that.
Also import needs small adjustment as it still expected null as possible
return type.