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.
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
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
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
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.
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.
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.
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
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
Add new record type partner.
This can be something like a media partner or something else.
Allow an event to have zero or more partner.
Add necessary files and models with relations.
Relates: #8092
Allow editor to reference TYPO3 page records from events.
E.g. used to provide further internal information links.
Also those pages are resolved via DataProcessing.
That allows integrators to be 100% flexible to resolve those page info.
By default a menu is generated and media is resolved.
Also validation is ignored, as this improves performance and allows to
use the new class as injected property without validation fails.
Models are not managed via frontend and therefore don't need validation.
Relates: #8092
