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.
Do not check for models, but actual file.
They might be missing, e.g. cause not downloaded from production into
dev environment.
The new checks ensure the page will not break with an exception, but
show default images.
The old identifier had a trailing comma.
Old installations would break if we do not keep the command under this
identifier.
Updating scheduler tasks is a bad thing, so we keep compatibility.
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
Given: Website uses copy / free mode of localization.
and Editor selects specific events to display.
Then: Those events should be displayed as selected.
Before this change the sorting was applied on uid of objects,
which is the uid of default lanugage record. But editors might select
localized uids. Therefore a fallback is added in case no object was
found.
Relates: #8557
That has no effect, the info is just available from model.
This can be used to display a canceled date in a different way, or
render a notice.
Relates: #8092
Make controller smaller, remove unused code.
Move creation of demand object into its own factory.
Reduce npath complexity in repository and move parts into named methods.
Allow editors to select specific events to display.
Therefore add new necessary demand and setting for events and respect
them within repository.
Relates: #8092
