Table of Contents 

Import 

Import of specific resources via static URLs. This allows import of specific tourist attractions and towns.

• The following data types can be imported (not all properties are supported):

  • Organisations (responsible for content)
  • Towns
  • Tourist information
  • Tourist attraction

Backend module 

Allows to create new import configurations.

Allows to inspect:

• Current existing organisations and their towns and tourist information
• Existing import configuration
• past imports and possible errors, as well as number of affected records.

Frontend 

A dedicated content element is provided to display tourist attraction.

A dedicated Page Type is provided to reference tourist attraction.

API Key 

Some API requests are only possible by providing an API Key. This key can be configured via "Extension Configuration".

Storage Pids 

The configuration of imports is stored within TYPO3 records. Those records can be created via backend module. Each new record is stored on a default page. The default is 0. That would prevent editors from creating and editing records. This page uid can be configured via TypoScript:

module {
    tx_thuecat {
        settings {
            newRecordPid {
                tx_thuecat_import_configuration = 10
            }
        }
    }
}

Import configuration 

Each import is defined via a special import configuration record. This record can be created via TYPO3 backend module.

There are different configurations available:

Static list of URLs

Allows to define a list of URLs which should be imported. These URLs should reference a single resource to import without any given parameters like a format.

Synchronization area

Allows to import a so called "Synchronisationsbereich". Find out more at https://cms.thuecat.org/developer. Add the given syncScopeId to the configuration to update the given resources for that specific sync scope. This requires an configured API Key.

All configurations also provide an input to define the page where records should be stored and updated. This page uid is also used to fetch accordingly site configuration. The related languages are used during the import.

Menu with tourist attractions 

The extension provides a custom page type which references tourist attraction. This can be used in conjunction with TYPO3 menus if generated via data processing, see

An concrete example would be to extend the content element menu_subpages:

tt_content.menu_subpages {
    dataProcessing {
        10 {
            dataProcessing {
                20 = WerkraumMedia\ThueCat\Frontend\DataProcessing\ResolveEntities
                20 {
                    as = touristAttraction
                    if {
                        isInList.data = field:doktype
                        value = 950
                    }
                    table = tx_thuecat_tourist_attraction
                    uids.data = flexform:tx_thuecat_flexform:touristAttraction
                }
            }
        }
    }
}

This will add the additional data processor delivered by the extension. It will extend each page of the menu with the model of the referenced tourist attraction.

Plugins and templates 

The extension name is ThueCat. Five content elements are intended, built from four plugins (the filtered list is the list plugin with an editor preset). Each plugin renders one template:

The plain and filtered list are the same TouristAttractionList plugin and therefore share the List template; the filtered variant only adds an editor preset in its FlexForm (see Filtered list). The search element is a combined search and filter form.

Required pages 

Set up these pages once and configure their ids (see Site settings):

• Storage folder -- a sysfolder holding the tourist attraction records.
• Detail page -- carries the detail content element; target for links to a single attraction.
• List / search page -- carries both the list content element and the search-and-filter content element.

On the list / search page neither plugin is optional: the search-and-filter form submits into the list, and the list renders the result. A page with only one of the two does not work.

Content elements 

Register one content element per plugin in your own extension or sitepackage, for example with Content Blocks. Each content element wires its CType to a plugin via the ThueCat extension name:

tt_content.myvendor_attractionlist =< lib.contentBlock
tt_content.myvendor_attractionlist {
    20 =< lib.contentBlock.20
    20 {
        pluginName = TouristAttractionList
    }
}

The list content element points at the storage folder through its pages field.

A full, ready-to-use content element definition is shown in ContentElementExample.

Templates 

The shipped stubs under EXT:thuecat/Resources/Private/Templates/ are registered at templateRootPaths.10. Override them by adding a higher index:

plugin.tx_thuecat.view {
    templateRootPaths.20 = EXT:my_extension/Resources/Private/Templates/
    partialRootPaths.20 = EXT:my_extension/Resources/Private/Partials/
    layoutRootPaths.20 = EXT:my_extension/Resources/Private/Layouts/
}

The templates are

• TouristAttraction/List
• TouristAttraction/SelectedList
• TouristAttraction/SearchForm
• TouristAttraction/Show

Field-specific output 

Some fields carry richer data than a single value and have their own model accessors and partials. They are covered on their own pages:

Site settings 

Provide a site set that maps site settings onto the plugin configuration and include it in your site. Fill in the page ids under Settings in the site configuration.

Settings definition (Configuration/Sets/<YourSet>/settings.definitions.yaml):

settings:
  page.pid.thuecat_attraction_show:
    label: 'Detail Page for Tourist Attractions'
    description: 'The page providing the detail pages for tourist attractions'
    category: 'page.pids'
    type: 'int'
    default: 0
  page.pid.thuecat_attraction_search:
    label: 'Search Result Page for Tourist Attractions'
    description: 'The page providing the list of tourist attractions, used as target for search form submissions'
    category: 'page.pids'
    type: 'int'
    default: 0
  list.itemsPerPage:
    label: 'Tourist Attractions per Page'
    description: 'Number of tourist attractions shown per page in the list view'
    category: 'list'
    type: 'int'
    default: 20

Mapping (Configuration/Sets/<YourSet>/setup.typoscript):

plugin.tx_thuecat.settings {
    page.pid {
        thuecat_attraction_show = {$page.pid.thuecat_attraction_show}
        thuecat_attraction_search = {$page.pid.thuecat_attraction_search}
    }
    itemsPerPage = {$page.settings.itemsPerPage}
}

Search and list on one page 

The search-and-filter form adapts to what shares its page:

• With a list (plain or filtered) on the page the form posts to the same page and the list re-renders with the result.
• Without a list on the page the form targets the configured list / search page (page.pid.thuecat_attraction_search).
• On a filtered list the preset fields are not shown in the search form, but rendered as hidden fields to preserve the pre-selection. The visitor refines the remaining fields but cannot widen past the preset.

After a search the form re-populates with the submitted values, so the visitor keeps their input.

Filtered list 

A filtered list carries an editor preset in its FlexForm (for example a fixed set of towns). The list re-applies the preset on every request: a visitor search refines within the preset but can never widen it, even with a tampered URL.

How it works 

The search-and-filter form does not read its own settings to learn the preset. A resolver inspects the current page for a list content element, reads its FlexForm, and returns the active preset:

• No list on the page -- the form targets the configured list / search page.
• A list on the page -- the form stays on the page; a filtered list additionally contributes the preselected fields.

The lookup is language- and overlay-aware, because it reads the stored content element through the frontend's record retrieval.

The form is rendered by TouristAttractionSearch but submits under TouristAttractionList, so the demand travels in the list's namespace. On re-render the form adopts that demand to re-populate its fields, and the editor preset is forced onto the locked fields, so the hidden inputs always carry the editor's values.

Import 

Opening hours are imported as inline database records (one row per weekday and time span, with an optional validity range). You do not work with those rows directly: the model computes a display-ready shape from them.

Computed model 

A tourist attraction exposes two computed accessors:

• computedOpeningHours -- the regular hours.
• computedSpecialOpeningHours -- deviating hours, for example public holidays.

Both return the same structure: a list of periods (validity ranges), each listing weekdays Monday-first, each weekday carrying all of its time spans. A day without hours is marked closed, so every weekday is present in the output. Past periods are dropped; the period covering today is flagged as current.

Rendering with the shipped partial 

The extension ships a partial that renders the computed shape as a per-day table (one row per weekday, all spans listed, closed days shown as closed). Render it from your Show template, passing the computed hours and a heading label:

<f:render partial="OpeningHours/PerDayTable" arguments="{
    openingHours: attraction.computedOpeningHours,
    heading: 'LLL:EXT:thuecat/Resources/Private/Language/locallang.xlf:content.openingHours'
}" />
<f:render partial="OpeningHours/PerDayTable" arguments="{
    openingHours: attraction.computedSpecialOpeningHours,
    heading: 'LLL:EXT:thuecat/Resources/Private/Language/locallang.xlf:content.specialOpeningHours'
}" />

The partial takes two arguments:

The partial renders nothing when there are no periods, so a missing heading or empty section never appears.

Import 

Images and other files are imported into FAL and related to the record. The target file directory is part of the import configuration.

FAL accessors 

A tourist attraction exposes its media as native Extbase FAL relations:

mainImage returns a single file reference or none; mediaFiles and editorialImages return a (possibly empty) collection.

Rendering 

The FAL relations are rendered with the standard Fluid image view helper, so processing (cropping, scaling) and metadata (copyright, alternative text) are available:

<f:if condition="{attraction.mainImage}">
    <figure>
        <f:image image="{attraction.mainImage}" />
        <f:if condition="{attraction.mainImage.originalResource.properties.copyright}">
            <figcaption>{attraction.mainImage.originalResource.properties.copyright -> f:format.htmlspecialchars()}</figcaption>
        </f:if>
    </figure>
</f:if>

<f:for each="{attraction.mediaFiles}" as="image">
    <f:image image="{image}" />
</f:for>

Breaking 

• Remove support for TYPO3 v12.

• The list item moved from a partial to a template: Resources/Private/Partials/TouristAttraction/ListItem.html is now Resources/Private/Templates/TouristAttraction/ListItem.html. The name is unchanged; only the directory differs.

  Integrators overriding the list item must move their override accordingly. An override left in Partials/ is silently ignored — the file is no longer read from there, and the shipped template renders instead. Nothing errors, so check this explicitly when upgrading.

  The reason is caching: the attraction list now renders each item separately and caches the resulting HTML per attraction, so an item is rendered once and reused by every list showing it. A separately rendered item is a template rather than a partial.

  This also changes what the list templates receive. List.html and SelectedList.html no longer iterate attractions — the controller renders the items and assigns them as ready HTML in {items}:

  <f:for each="{items}" as="item">
      <f:format.raw>{item}</f:format.raw>
  </f:for>

  Copied!

  An override still iterating {list.paginatedItems} or {attractions} renders nothing, without an error. {list} remains assigned for pagination; {attractions} is gone from the curated list entirely.

  Both actions share one cache, so an attraction shown by a filtered list and a curated one is rendered once.

  Template paths are unchanged otherwise: the item is resolved through the plugin's configured templateRootPaths, so an override in an extension or sitepackage keeps working once it sits in Templates/.

Features 

• Attraction lists are cached, so a visitor rarely waits for one to be built twice.

  Three caches do the work, all in the pages cache group:

  tx_thuecat_teaser

  One rendered list item, keyed by the record, the detail page it links to and the language. An attraction shown by several lists — filtered, curated, on different pages — is rendered once and reused by all of them.

  tx_thuecat_list

  A whole rendered list, keyed by the plugin, the filter selection, the pagination page and the language.

  tx_thuecat_searchmask

  A rendered filter form, keyed by the plugin, its page, the selection and the language. Deliberately not by the pagination page, so paging through results reuses one form.

  Because they belong to the pages group, everything that already clears page caches clears these too: the "Clear cache" buttons in the backend, and any editor saving a record. Editors need do nothing differently — a changed attraction, town or category takes its cached output with it and the next visitor sees the new content.

  Entries are discarded by the records they show rather than by age, so nothing goes stale waiting for a lifetime to run out. A filter combination nobody has requested before is still built from scratch, but only its unseen items cost anything: the rest come from the teaser cache.

  The three caches therefore configure a lifetime of one year. This is not a staleness setting — invalidation by tag is what keeps content current — it exists because TYPO3's default would otherwise expire entries after an hour. Override it per cache in ext_localconf.php or config/system/additional.php via $GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations'][<identifier>]['options']['defaultLifetime'], though shortening it only costs rebuilds without making anything fresher.

  Note that an import currently discards the caches of every record it visits, whether or not that record changed, so lists are rebuilt after each import run. A known limitation, to be addressed separately; it costs speed, never correctness.

• Add support for TYPO3 v14.
• Handle images and other files properly via FAL upon import. Target file directory is now part of the import configuration.
• Events are imported with their images. An event's schema:photo and schema:image both land in the images field of tx_events_domain_model_event ; events have no separate main image, so the source ranking decides the order — the photo comes first. The previous cap of eight images per event is removed: every image upstream publishes is imported.

• Media uploaded directly to a record is imported. Alongside the established form, where a record points at a reusable media resource, upstream also lets editors upload a file into the record itself. Such a file was previously rejected before any download was attempted, and — because the rejection was fatal — it cost the whole root URL every one of its records. It is now imported like any other image, with its author and licence.

  This applies to every record type, not only events. A point of interest carrying a direct upload imports it into main_image / media_files as it would a referenced image.

  A directly uploaded file is identified by its file name in the delivered address, which stays stable across runs, so re-importing reuses the stored file instead of downloading it again.

  These files are served from the API host, which refuses anonymous requests, so the configured API key is sent when an image is fetched from that host. Images on other hosts — every referenced media resource so far — are requested unchanged, without a key.

• Import opening hours as inline database records ( tx_thuecat_opening_hours ) and expose a display-ready, computed shape via Domain\Model\Frontend\Place::getComputedOpeningHours() and getComputedSpecialOpeningHours() . The shape groups records into validity periods, lists every weekday Monday-first, keeps all time spans of a day and marks days without hours as closed. A OpeningHours/PerDayTable partial renders it. The current open/closed status is intentionally left to client-side logic.

• An event imported without a single date is named in the import log. Such an event is stored but cannot appear anywhere dates are shown, and until now nothing said so — the absence had to be noticed in the frontend and traced back by hand. Each one now gets a tx_thuecat_import_log_entry row of the new type eventWithoutDates at severity warning, naming the event and the record to look at.

  The reason is deliberately not distinguished: an event publishing no schedule, one whose schedule yields no usable day, and one whose dates are all excepted are reported alike, because the outcome is the same. The event still imports and a run whose only findings are dateless events exits 0.

  Events whose dates have all passed are included, so a finished event will produce this warning. That is intended — the log entry says "this event shows nothing", which is true of a past event as well — but it means the type is expected to appear routinely on sites with older data.

Fixes 

• Paging through an attraction list no longer shows the wrong page.

  Every pagination page and every filter combination of one list plugin shared a single page-cache entry, because currentPage and demand were excluded from the cache identifier. Whichever page was requested first was then served for all of them, until that entry expired.

  The symptom only appeared once a page had been cached, so it was reliably invisible on a developer machine and in tests, where every request starts from a cold cache.

  The list and search actions are now non-cacheable and serve their output from the caches described under Features, each keyed by the plugin, the filter selection, the pagination page and the language. Filter and pagination URLs are unchanged.

• A referenced resource that cannot be fetched no longer aborts the whole root URL. Previously any failure while resolving a reference (a resource deleted upstream, a server error, a malformed response, a network failure) propagated out of the resolver and the importer discarded every record belonging to that root. Now only the affected reference is dropped: the owning record is imported without that relation, and all other records under the same root are unaffected.

  Each affected parent record gets its own tx_thuecat_import_log_entry row of the new type referenceSkipped at severity warning, carrying the owner's remote_id and table_name alongside the reference URL, the target field and the failure reason — so the log names the records to fix, not merely the URL that failed. A URL already found to be failing is not fetched again for the rest of the run, but every parent that loses a reference is still logged.

  Because these runs report warning rather than error, thuecat:importviaconfiguration now exits 0 for them. Failures of the outer calls — the sync-scope/contains-place listing and the root URL fetches — are unchanged and still fail the run, so a genuine upstream outage remains distinguishable.

• A record no longer inherits relations from the record imported before it.

  Records that said nothing about a relation kept whatever the previous record in the same run had declared. The effect was visible with images — several events ending up with the same picture, none of which named it — but it applied to every imported relation: town, responsible organisation, nearby parking, categories. A record silent about a relation is now imported without it.

  Relations already stored from earlier runs are not corrected by this. The import stops writing them; removing one whose source is gone is a separate matter, and images that were wrongly related need to be removed by hand.

• A media entry the import cannot interpret no longer costs the whole root URL. Upstream may publish an entry that is neither a reference to a media resource nor a direct upload. Such an entry previously aborted the import of every record under that root. It is now skipped like an image that cannot be downloaded: the record is imported, its usable images are related, and a tx_thuecat_import_log_entry of type referenceSkipped at severity warning names the record and the entry. A run whose only problem is an entry of this kind exits 0.

• An image that cannot be downloaded no longer costs the run its media. Previously the download raised on any error status, the exception escaped the resolver and the importer discarded the whole root URL; because promotion of downloaded files was gated on the run's overall severity, that single failure also deleted every image already downloaded under all other roots. A run could finish having imported thousands of records and not one image.

  Now only the affected image is dropped: the owning record is imported without that file, its other images are related as usual, and records under the same root are unaffected. This holds for every failure mode — an error status, a refused connection, a timeout, or an empty body. Each affected record gets a tx_thuecat_import_log_entry row of type referenceSkipped at severity warning, naming the record and the URL that could not be fetched, so runs whose only problems are unfetchable images exit 0.

  The image download now sends through the PSR-18 client rather than RequestFactory::request() , whose Guzzle default raises on a 4xx/5xx before the response can be inspected. JSON-LD fetches are unchanged and still fail loudly.

• Staged media is now promoted into the target folder even when the run recorded an error elsewhere. A file in staging downloaded successfully, so an unrelated mapping failure says nothing about it. This is observable: a run ending in error now leaves promoted files where it previously left none. A promoted file that no record ended up referencing is reused by name on the next run rather than downloaded again. The per-run staging folder is still discarded on every exit path, so a crashed run leaves no orphans.
• thuecat:importviaconfiguration now prints a closing message stating whether the run completed, completed with warnings, or failed. It previously exited silently, so a non-zero exit arrived with no explanation.

• A schedule day that cannot seed a date series no longer aborts the event import.

  schema:byDay may carry values that are valid upstream but name no weekday — schema:PublicHolidays among them. These were passed on for date expansion, where they raised and cost the whole root URL its records. Such a value is now skipped: the event imports with the dates its remaining weekdays produce, and a tx_thuecat_import_log_entry of the new type scheduleDaySkipped at severity warning names the event and the value. Editors keep the information that upstream asked for something the import cannot express.

  Where a schedule supplies more usable weekdays than the import can carry — a monthly schedule holds one — the surplus days are recorded separately as scheduleDayDropped, also at warning. The two are deliberately distinct: one is an upstream value we cannot use, the other a usable value our own import discards, and they call for different editor action.

• schema:exceptDate is honoured.

  Dates a schedule explicitly excludes were imported like any other occurrence. They are now dropped, for every frequency. The comparison is by calendar day in the schedule's timezone, since an exception is date-only while occurrences carry a time.

• An event's stored dates are reconciled with its schedule on re-import.

  Only new occurrences were ever written; one that stopped being produced stayed in the database indefinitely. Dates the import owns are now compared against what the current schedule yields, and the difference is deleted. This is the observable change of this release: occurrences that became excepted, fell after a shortened series end, or vanished with a changed schedule disappear on the next run, where they previously lingered.

  Only the import's own rows are affected — ownership is established through the remote_id the import assigns — so dates created in the backend survive. The reconciliation is scoped to the events actually imported by the run: an event outside the run, or one whose root URL was abandoned, keeps its dates.

• A failed root URL is identifiable from the import log.

  mappingError and fetchingError entries recorded the exception's message and origin but not which configured URL produced them, so a run with several roots left the failure unattributable. Both now carry the root URL in remote_id and repeat it in the entry's context alongside the existing detail. Severity is unchanged: an abandoned root remains an error and still fails the run.

  The failing record itself is not named. It is not reliably known at the point the failure is caught — parsing may raise before any record is identified — and naming the wrong record would mislead more than naming none.

Tasks 

Nothing

Deprecation 

• The json-based media storage has been superseeded by proper FAL handling. The json-based output logic is still in

place. The next import will copy and relate the files as needed. With the next fitting version, the json-based fields will be removed.

Deprecated, triggering E_USER_DEPRECATED on use:

• Domain\Model\Frontend\Media::getMainImage() , getImages() , getExtraImages() , getEditorialImages() and getAllImages() (the json-blob read accessors).
• Domain\Model\Frontend\Base::getMedia() (hands out the json-blob carrier).

Use the FAL fields instead, available as native Extbase properties on Base: getMainImage() ( main_image ), getMediaFiles() ( media_files ) and getEditorialImages() ( editorial_images ). Re-run the import to populate main_image and media_files ; editorial_images is maintained in the backend. Templates should switch from {record.media.*} to these properties.

• The editorial_images field is now handled as the FAL field it always has been. Replace template output from {entity.media.editorialImages} to {entity.editorialImages} to make use of the full FAL provided functionality.

• The json-based opening hours storage has been superseeded by inline database records. The json-based output logic is still in place. The next import will create the inline records as needed. With the next fitting version, the json-based fields will be removed.

  Deprecated, triggering E_USER_DEPRECATED on use:

  • Domain\Model\Frontend\Place::getOpeningHours() , getMergedOpeningHours() , getSpecialOpeningHours() and getMergedSpecialOpeningHours() (the json-blob read accessors).

  The legacy \Domain\Model\Frontend\OpeningHours , MergedOpeningHours and MergedOpeningHourWeekDay models are deprecated alongside them.

  Use getComputedOpeningHours() / getComputedSpecialOpeningHours() instead. Re-run the import to populate the inline records. Templates should switch from {record.openingHours} / {record.mergedOpeningHours} to the OpeningHours/PerDayTable partial.

Breaking 

Nothing

Features 

• Add PHP 8.4 support.
• Add PHP 8.5 support.

Fixes 

• Allow none admin users to import.

  There was a broken configuration of corresponding TCA tables. It forced to insert log entries on root, whiteout allowing users to insert on root.

Tasks 

Nothing

Deprecation 

Nothing

Breaking 

Nothing

Features 

• Add TYPO3 wizard to select pages in configuration. That should ease live of editors, compared to manually inserting proper page uid.
• Add title to static import configuration. This title is auto filled on save with the titles of provided URLs.

Fixes 

• Prevent Error: Call to undefined method TYPO3CMSCoreDatabaseSchemaSchemaInformation::introspectTable() with newer TYPO3 v13 versions. We now check for the old API, falling back to the new. All of this is still @internal TYPO3 API.

  The corresponding core change was commit 45a50e455955c78f6baa2aec3af3865101ee06b9. We also need to update codappix/typo3-php-datasets dev dependency for the same reason.

• Handle 404 during import. Imports that would import a no longer existing resource resulted in a 503 Server Error. Those are now properly catched and logged. Those errors will no longer fail.

Tasks 

• Prevent creation of composer.lock file. As this is an extension without a lock state. We have different TYPO3 versions as supported versions and it should be easy to switch between them for testing and development.
• Streamline phpstan.neon formatting.

Deprecation 

Nothing

Breaking 

• Removed content element.

  No Content element is provided any longer. We recommend to build your own tailored content elements instead.

Features 

• Add TYPO3 v13 LTS Support.

Fixes 

Nothing

Tasks 

Nothing

Deprecation 

Nothing

Breaking 

Nothing

Features 

Nothing

Fixes 

• Add missing dependency to typo3/cms-install. As this provides the upgrade wizard feature.
• Handle broken opening hours. Those are skipped during import and written as error to TYPO3 logs. That way entries with broken opening hours can still be imported.

Tasks 

Nothing

Deprecation 

Nothing

Breaking 

• Drop support for TYPO3 10.4 and 11.5.
• Drop support for PHP 7.4 and 8.0.

Features 

• Add support for TYPO3 12.4.
• Add support for PHP 8.3.
• Add support for multiple slogans (array within slogan). The existing API will return the first slogan. A new method getSlogans is added which will return the array of slogans.

Fixes 

Nothing

Tasks 

Nothing

Deprecation 

Nothing

Breaking 

Nothing

Features 

• Add command to allow import of a single configuration. The command is also available as scheduler task. This finally allows to regularly execute imports. This also allows to import from CLI context with differently configured timeouts.

• Add support for additional images added via TYPO3. Some installations might need to add further images to records imported from ThüCAT. The records are now extended to support adding images by editors. The images are not touched during import. The images are also ignored during clean ups, the editor is in full control.

  This feature for now is only added to tourist attractions by default. The feature is implemented in a way that all objects extending the WerkraumMedia\ThueCat\Domain\Model\Frontend\Base class are usable by adding an editorial_images field to their table.

• Support translated offers. The translation for offers of tourist attractions got added.

Fixes 

• Catch mapping exceptions during converting entities. Those are handled the same way, the entity is skipped and errors are logged. That way further entities can be imported while only none working entities are skipped.
• Fix broken check of logged errors within functional tests. The logging is now adjusted to only log errors. The file will be checked for each test that does not expect errors to happen.
• Handle incoming array instead of string for AccessibilityCertification. That prevents mapping exceptions for objects containing the corresponding certification with more info than a single value.

Tasks 

• Converted log entry for none converted entity from error to notice. As this might hint at an issue but most probably is okay, e.g. due to none active language, missing name, etc.
• Separate default templates from templates for testing. That way we no longer test the delivered templates, but they should not be used anyway. Also we can now use templates only for testing to ensure that frontend rendering works as expected, without worrying about sites using the templates. The templates were copied and extended for editorial images.

Deprecation 

Nothing

Breaking 

• Permissions of backend modules. The modules got new identifiers. User permissions need to be adjusted. An update wizard is provided that will migrate the permissions.
• Drop support for PHP 7.2 + 7.3.

Features 

• Add support for TYPO3 v11 and PHP 8.0 + 8.1 + 8.2.
• Last import date is now shown within backend module beside each import configuration.
• New import configuration type "Contains Place". This allows to provide a single entity, e.g. a Town that has multiple schema:containsPlace entries. Each of them will be imported.
• Import will no longer break on mapping issues. Those will be logged and are available within the existing backend module. This allows to skip some objects which can not be handled yet. The log can be used to open issues. We then can improve the mapping.
• Import author of media. This allows to either render the license author or the author.

• Filter and sort opening hours. Filter out opening hours from the past, they are not available to the template anymore. Sort opening hours from early to later based on their end timing.

  This should improve the UX of website visitors. It is not possible yet to sort opening hours by hand within the thuecat backend.

• Support special opening hours. It is possible to define special opening hours, e.g. for holidays. Those are now also imported and provided to the templates.
• Allow to check if an opening hour is valid for a single day.
• The URL of attractions is now imported and provided to the template.
• Media has a new method getExtraImages() which will return everything from getImages() except the getMainImage(). We now also filter out the main image from other images, it will not exist twice anymore.
• Allow to hide parking facilities.
• Parking facilities can now be rendered sorted by alphabet. Use new method getParkingFacilitiesNearBySortedByAlphabet().
• Support types of public transport when returning distance to public transport. A new array key types was added. This is an array of types, e.g. CityBus or Streetcar. These can be used with f:translate ViewHelper to provide proper none technical labels.
• Configure EXT:scheduler table garbage collection task to clean up import records. It is now possible to select the tables within the TYPO3 scheduler task to be cleaned up.
• Respect schema:givenName and schema:familyName of schema:author for media. We only respected schema:name until now.
• Provide new key copyrightAuthor holding the actual author for convenience. It will pick the author value falling back to license.author.
• Provide new method to retrieve merged opening hours and merged special opening hours. The merge happens on the valid time span of each. The data structure is a bit different as different hours will be merged.

Fixes 

• Allow to import objects (e.g. Tourist Attractions) which are managed by generic organisations instead of specific Tourist Marketing Company. Those organisations will now also be imported, just like Tourist Marketing Company before. Both are organizations internally and only used for the TYPO3 backend module.

• Handle multiple thuecat:offerType values within Offer. The API is none breaking, the models still return only a single offer.

  They will filter down to the first offer which contains Offer within the value. Examples:

  Given: Childcare and CourseOffer will result in CourseOffer.

  Given: Childcare will result in Childcare.

  Existing imported data is still handled.

• Remove trailing : in German translation of content.distanceToPublicTransport. This was the only label with :.
• Keep editorial sorting of tourist attractions within content element. This was not the case yet, the records were sorted by dbms, e.g. by uid.

Tasks 

• Removed API Key from site configuration. The key was already moved to extension configuration as documented. Still we extended the site configuration, which is now cleaned up, see: https://github.com/werkraum-media/thuecat/issues/55
• Remove seconds from opens and closes of opening hours as we don't expect them to be used.
• Use new icons in streamlined color and UI. Provide new icon for storage folders. Provide new icon for content element.
• Add first acceptance tests for backend modules.

Deprecation 

Nothing

Breaking 

Nothing

Features 

Nothing

Fixes 

Nothing

Tasks 

• Changed Fluid templates:

  • Improve rendering of opening hours

Deprecation 

Nothing

Breaking 

Nothing

Features 

Nothing

Fixes 

• Use proper extension name for translation within templates.

  This was sitepackage and was changed to Thuecat.

Tasks 

• Changed Fluid templates:

  • Add more CSS classes fore better styling
  • Only render services part if services exist There is a follow up to move the huge condition from template to model: https://github.com/werkraum-media/thuecat/issues/64

• Improved composer authors:

  • Added Carlos
  • Added homepages
  • Added roles

Deprecation 

Nothing

Breaking 

Nothing

Features 

Nothing

Fixes 

Nothing

Tasks 

• Changed Fluid templates to be more polished using current Bootstrap markup.

Deprecation 

Nothing

Breaking 

Nothing

Features 

• Added missing French translations.

Fixes 

Nothing

Tasks 

Nothing

Deprecation 

Nothing

TCA searchFields 

Drop TCA ctrl/searchFields. Those are kept for TYPO3 v13 backwards compatibility and can be dropped once we drop v13 support.

PHPDoc Blocks with type hints mentioning Necessary for Extbase/Symfony. 

Those are necessary (at least with TYPO3 v12) because of Extbase and the underlying Symfony component.

Extbase uses the PHPDocExtractor first, before using the ReflectionExtractor, both part of Symfony property-info package. The ReflectionExtractor will check the mutator followed by accessors prior checking the property itself. Some of our properties have different return values by accessors than the stored value that is set to the property. We therefore need to keep the PHPDoc block as this is checked first.