EXT:thuecat
ThüCAT is ¨Thüringer Content Architektur Tourismus¨. This is an extension for TYPO3 CMS (https://typo3.org/) to integrate ThüCAT. The existing API is integrated and allows importing data into the system.
ThüCAT is ¨Thüringer Content Architektur Tourismus¨. This is an extension for TYPO3 CMS (https://typo3.org/) to integrate ThüCAT. The existing API is integrated and allows importing data into the system.
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):
Allows to create new import configurations.
Allows to inspect:
Figure 1-1: Overview of currently available configurations and Organisations.
Figure 1-2: Overview of executed imports and their results.
A dedicated content element is provided to display tourist attraction.
A dedicated Page Type is provided to reference tourist attraction.
The extension can be installed via composer, see t3gettingstarted:extensions-management. The composer package can be found at packagist.org.
Integrators can include and configure TypoScript once it is installed and enabled. See Include TypoScript from extensions. All available configurations can be found at Configuration.
At least one import configuration needs to be created and imported. See Import configuration.
Some API requests are only possible by providing an API Key. This key can be configured via "Extension Configuration".
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
}
}
}
}
Each import is defined via a special import configuration record. This record can be created via TYPO3 backend module.
There are different configurations available:
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.
EXT:thuecat registers Extbase controller actions and ships template stubs, but no content elements. You define the content elements in your own extension or sitepackage and point them at the registered plugins, so rendering stays under your control.
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:
| Plugin name | Content element | Template |
|---|---|---|
TouristAttractionList | List | List |
TouristAttractionList | Filtered list | List |
TouristAttractionListSelected | Selected list | SelectedList |
TouristAttractionSearch | Search-and-filter | SearchForm |
TouristAttractionShow | Detail | Show |
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.
Set up these pages once and configure their ids (see Site settings):
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.
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 Content element example.
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/ListTouristAttraction/SelectedListTouristAttraction/SearchFormTouristAttraction/ShowProvide 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 = {$list.itemsPerPage}
}
The search-and-filter form adapts to what shares its page:
page.pid.thuecat_attraction_search).After a search the form re-populates with the submitted values, so the visitor keeps their input.
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.
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:
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.
A complete, ready-to-use content element built with
content_blocks:Index. This example is the selected list:
an editor picks a fixed set of attractions, rendered in the chosen order. Replace
myvendor with your own vendor name.
Definition (ContentBlocks/ContentElements/attraction-list-selected/config.yaml):
name: myvendor/attraction-list-selected
group: Thuecat Attraction
prefixFields: true
prefixType: vendor
fields:
- identifier: TYPO3/Header
type: Basic
- identifier: 'pi_flexform'
type: 'FlexForm'
useExistingField: true
fields:
- identifier: 'settings.selectedRecords'
type: 'Select'
renderType: 'selectMultipleSideBySide'
foreign_table: 'tx_thuecat_tourist_attraction'
foreign_table_where: 'AND {#tx_thuecat_tourist_attraction}.{#sys_language_uid} IN (0, -1)'
Wiring (ContentBlocks/ContentElements/attraction-list-selected/setup.typoscript):
tt_content.myvendor_attractionlistselected =< lib.contentBlock
tt_content.myvendor_attractionlistselected {
20 =< lib.contentBlock.20
20 {
pluginName = TouristAttractionListSelected
}
}
The settings.selectedRecords FlexForm field lets the editor choose the
attractions; the TouristAttractionListSelected plugin renders them via the
SelectedList template in the picked order.
The other content elements follow the same shape: a FlexForm field for their settings (a town preset for the filtered list, none for the plain list, none for the search-and-filter form) wired to the matching plugin name from Frontend output.
Nothing
Nothing
The next import will copy and relate the files as needed. With the next fitting version, the json-based fields will be removed.
Nothing
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.
Nothing
Nothing
Nothing
Prevent Error: Call to undefined method TYPO3CMSCore 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/ dev dependency for the same reason.
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.phpstan.neon formatting.Nothing
Removed content element.
No Content element is provided any longer. We recommend to build your own tailored content elements instead.
Nothing
Nothing
Nothing
Nothing
Nothing
typo3/cms-install .
As this provides the upgrade wizard feature.Nothing
Nothing
getSlogans is added which will return the array of slogans.Nothing
Nothing
Nothing
Nothing
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.
AccessibilityCertification.
That prevents mapping exceptions for objects containing the corresponding certification with more info than a single value.Nothing
schema:containsPlace entries.
Each of them will be imported.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.
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.getParkingFacilitiesNearBySortedByAlphabet().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.schema:givenName and schema:familyName of schema:author for media.
We only respected schema:name until now.copyrightAuthor holding the actual author for convenience.
It will pick the author value falling back to license.author.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.
: in German translation of content.distanceToPublicTransport.
This was the only label with :.Nothing
Nothing
Nothing
Nothing
Changed Fluid templates:
Nothing
Nothing
Nothing
Use proper extension name for translation within templates.
This was sitepackage and was changed to Thuecat.
Changed Fluid templates:
Improved composer authors:
Nothing
Nothing
Nothing
Nothing
Nothing
Nothing
Nothing
Nothing
Nothing
List of changes that need to be done for maintenance reasons. Those affect the extension itself, not users of the extension.
E.g. changes once we drop a certain TYPO3 version. We might have new code backported for compatibility in older TYPO3 versions. Those changes are documented so we know what to do once we drop an older version.
searchFields Drop TCA ctrl/. Those are kept for TYPO3 v13 backwards compatibility
and can be dropped once we drop v13 support.
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 Reflection, both part of Symfony property-info package.
The Reflection 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.