Strip off seconds from strings.
Prepare code to easily provide a structured data to allow integrators to
format timing differently.
Provide a method to easily check if an opening hour is only valid for a
single day.
Relates: #10185
Opening hours are filtered. Opening hours from the past are no longer
available.
Opening hours are sorted. Newer opening hours are shown last.
Relates: #10185
The import resulted in an exception if there was an array of types
instead of a string.
Both situations are now handled and API of models is kept.
Existing imported data is also kept.
* Support generation of code coverage generation
* Remove useless caching within GitHub
* Add TYPO3 11.5 within CI
* Update phpstan
Replace friendsoftypo3/phpstan-typo3 with saschaegerer/phpstan.
The friendsoftypo3 is intended for TYPO3 itself, while saschaegerer is
intended for community.
Also update all related packages.
Fix some new findings and update baseline.
* Run composer none interactive in CI
* Remove dependency checker
* Migrate tests to no longer use legacy dependencies
* https://forge.typo3.org/issues/97479
* Fix phpstan findings
DayOfWeek is an enum as defined at https://schema.org/DayOfWeek
We missed the PublicHolidays enum value when building
`getDaysOfWeekWithMondayFirstWeekDay()` which is used in templates to
get ordered result.
Opening hours for public holidays were not rendered, which is now fixed.
That ensures grouped output of related offers.
Offers are not sorted in any way and might end up in entry, parking,
entry, etc. Sorting ensures all of same type are rendered one after the
other, entry, entry, parking.
Sorting is done by alphabet on the technical enum value.
Catch the exception and return null.
That is already a possible return type which should be handled by
callers.
Add test case with referenced 404 image.
- Removed individual converters for TYPO3.
Conversion is now handled in a single converter.
- The new converter will import necessary dependencies upfront, e.g.
town or organisation.
- Move import state into extra class.
Relates: #34
Use Symfony components to map incoming JSON onto objects.
Those provide a mapping. They can then be used to fetch the data in a
common way and insert it into the system.
- Handle languages within JsonDecode
(normalize incoming data based on language)
- Handle Single Value and List of Values within Entities. They will map
incoming Data to proper Objects. (We now generally transform during
serialization process if target is array but we got single entity)
- Add missing tests for existing data.
- Finish migration of all existing data, this includes next step
- Provide discriminator to ObjectNormalizer to auto detect target class
based on "type" property. (Done for now by own registry)
- Combine generated object with current structure for import -> generate
data array out of it.
- Resolve foreign references to existing entities,
(images, contentresponsible, etc.)
This should ensure rendering works as expected.
Most important: This ensures data is available in frontend templates.
Add dev dependency to fluid_styled_content. This is necessary to test
our rendering integration with fluid_styled_content defaults.
Relates: #34
