Features 

  • Support multiple languages.

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.

Figure 1-1: Overview of currently available configurations and Organisations.

Figure 1-2: Overview of executed imports and their results.

Frontend 

A dedicated content element is provided to display tourist attraction.

A dedicated Page Type is provided to reference tourist attraction.

Installation 

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.

Configuration 

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
            }
        }
    }
}
Copied!

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.

Integration 

Frontend output 

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.

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:

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.

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
    }
}
Copied!

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.

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/
}
Copied!

The templates are

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

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
Copied!

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}
}
Copied!

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.

Content element example 

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)'
Copied!

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
    }
}
Copied!

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.

Changelog 

5.0.0 

Breaking 

  • Remove support for TYPO3 v12.

Features 

  • 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.

Fixes 

Nothing

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.

4.2.0 

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

4.1.0 

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

4.0.0 

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

3.0.1 

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

3.0.0 

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

2.1.0 

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

2.0.0 

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

1.2.2 

Breaking 

Nothing

Features 

Nothing

Fixes 

Nothing

Tasks 

  • Changed Fluid templates:

    • Improve rendering of opening hours

Deprecation 

Nothing

1.2.1 

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:

  • Improved composer authors:

    • Added Carlos
    • Added homepages
    • Added roles

Deprecation 

Nothing

1.2.0 

Breaking 

Nothing

Features 

Nothing

Fixes 

Nothing

Tasks 

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

Deprecation 

Nothing

1.1.1 

Breaking 

Nothing

Features 

  • Added missing French translations.

Fixes 

Nothing

Tasks 

Nothing

Deprecation 

Nothing

Maintenance 

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.

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.

Sitemap