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.
The code used native date functions, this made tests not robust.
We switch to TYPO3 API to fetch the current date and time.
Test is adjusted to define the date and time to verify code works as
expected.
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.
Entering the continue part would end in an endless loop.
We never add anything to $i and therefore would end up here.
Existing tests ensure we don't break something.
The new test ensures we do not hit endless loop anymore.
The property will always be set in the future.
We no longer can use it as an indicator.
We switch to freq as new indicator.
We also ensure that start has to be given for a single date.
Relates: #9892
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
