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.
They sometimes use a different separator.
The code is adjusted to always use same separator and precision.
That will prevent the same location from showing up multiple times due
to different latitude and longitude values.
* Set ``alternative`` to the ``description`` if available.
* Set ``creator_tool`` to the "destination.one".
* Set ``source`` to the URL of the fetched image.
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.
The usual use cases right now would involve a new file with a new URL.
That way we don't need to download existing files again.
That reduced network traffic, execution time and resource usage.
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.
A new TypoScript option upcoming is added.
The option can be set to 0 (default) or 1.
0 behaves the same way as in the past.
1 turns off the option useMidnight, start and end.
Only dates with a start date in the future will be shown.
Relates: #10507
There might be access to TSFE get_cache_timeout() prior rendering
events.
TYPO3 has a cache for timeout and won't re calculate again.
We therefore need to clear the cache if timeout would change.
That will lead to inconsistent cache information throughout a single
request. But the final cache timeout of the page will be correct. Other
parts might be longer, which probably is fine until they relate to the
events.
Relates: #10500
The clean up task had an issue to clean up to many files.
It didn't check if a file that could be deleted
because one event got deleted, was still in use by another event.
Relates: #10499
We didn't adjust the location name when using searchwords.
We now properly search within new locations name, instead of old no
longer existing column.
Relates: #10349
Normal updates are executed:
./vendor/bin/typo3cms upgrade:prepare
./vendor/bin/typo3cms upgrade:run all --no-interaction
./vendor/bin/typo3cms database:updateschema '*'
./vendor/bin/typo3cms database:updateschema '*'
The first one will execute an database:updateschema which will run safe
which only adds and doesn't rename or remove columns.
Then our update wizard can use the existing columns and new columns and
tables.
The last step will actually rename and remove.
