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
TYPO3 scheduler tasks always have a value for console commands.
Region uid will be an empty string if omitted within scheduler task.
We reflect that in our tests and adapt code to not break.
Furthermore tests call only with strings, as that's what TYPO3 does.
Adjust existing code base to not use hardcoded file path.
Instead use info from database and check all files which have references
to event objects.
Also add test to cover feature.
This allows 3rd party to alter the query of dates when demand is used.
E.g. allow more complex filters specific for some situations like CEs.
Relates: #9505
Move to a dedicated factory for easier re use.
Add dependencies and apply stdWrap to properties.
That allows to dynamically set values like dates by using stdWrap
features.
E.g.:
settings {
end {
strtotime = midnight +1 day
}
}
Relates: #9505
Using a FlexForm results in stored Unixtimestamps.
Adding 00:00 and using strtotime will result in false, resulting in
null.
We now just keep the provided value as integer.
That way underlying code works as expected and delivers events from
given start date.
Relates: #9352, #8581
Most of the time dates are fetched and shown.
They need the event to show info like title.
But they nearly never need further dates, except in detail view.
Turning this property lazy will save a lot of data fetching and mapping
and provides a huge performance impact.
Properly cleanup system.
Delete further records when deleting everything.
Also respect further records when purging old entries.
Respect:
* sys_category_record_mm
* sys_file_reference
* sys_file_metadata
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
Extbase Category repository was used, while custom Category instances
were expected.
The repository didn't inherit from Extbase Repository and therefore
didn't provide expected findByUid method.
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.
Some sites do not use postponed_date at all.
It would be a massive performance issue to still search for them for
each and every date instance that is created.
This small addition will solve the issue for those pages.
It will still once at least one internal reference is added.
We could then try to add proxies which are build and added, but don't
use the DB. That way the performance would still be okay, and data will
only be fetched when used.
The process will not call __construct, the object storages might not be
initialized. Therefore initializeObject is now implemented which is
calling the existing method to initialize object storages.
Adjust cache name to match TYPO3 v10 convention without "cache_" prefix.
Add default configuration to prevent issue if integrator does not
configure cache.
Extbase will properly use mm sorting.
But categories can't be sorted within the TCA tree component.
Therefore it makes more sense to use actual sys_category sorting.
In order to do so, we add our own model and pass the sorting.
That way PHP can do the sorting.
That's the easiest approach.
Also events shouldn't contain to many categories. A performance impact
should not be high.
Relates: #8459
Respect start and end when creating demand from settings.
That way integrator can configure it via TypoScript, or provide an
FlexForm.
Also the query was adjusted. It now respects a single value and doesn't
need start and end.
That way upcoming events can be created.
Relates: #8581
