[FEAT] TYPO3 14 compatibility (JR-179) - #1
Open
fennec-agent wants to merge 9 commits into
Open
Conversation
Make the extension installable and runnable under TYPO3 14.3.x while keeping TYPO3 13.4 support, so the janda-roscher project can transition smoothly. Changes: - composer.json: require typo3/cms-* "^13.4 || ^14.0", add explicit php "^8.2" and the extbase/frontend/backend/fluid subpackages the extension uses. - MapController: replace the removed TSFE->additionalHeaderData (the TypoScriptFrontendController was removed in v14) with PageRenderer::addHeaderData(), which works in both v13.4 and v14. - tt_content.php: migrate the plugin from the removed "list_type" sub type to a dedicated CType. registerPlugin() now registers CType "cbgooglemaps_quickgooglemap"; the FlexForm is attached via addToAllTCAtypes() plus a static columnsOverrides DS, replacing the deprecated addPiFlexFormValue() and the removed subtypes_addlist/subtypes_excludelist. - ext_localconf.php: pass ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT to configurePlugin() (TYPO3 Rector MigratePluginContentElementAndPluginSubtypes). - Remove the manual New Content Element Wizard page TSconfig (and its CType=list/ list_type defValues): since v13 the wizard item is auto-registered from the CType, so the manual entry produced a duplicate. Wizard title/description are now passed to registerPlugin(). Verified: composer validate, php -l on all PHP files, TYPO3 Rector (UP_TO_TYPO3_13) dry-run clean. Not yet smoke-tested in a live v14 instance. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The TYPO3 Extension Scanner flagged several deprecated/removed API usages
in MapController that the v14 compatibility commit had not yet covered:
- #109551 GeneralUtility::getIndpEnv('TYPO3_REQUEST_HOST') (deprecated in
v14.3): replaced by $normalizedParams->getRequestHost(), cached on the new
$requestHost property and used for the icon URLs.
- #109575 ContentObjectRenderer->parentRecord (deprecated in v14.3): removed.
It was only used in a dead, always-false isset() expression appended to
contentId.
- ContentObjectRenderer accessed via a fresh GeneralUtility::makeInstance():
this returned an empty renderer, so $ceData was always null. Now the current
content object is read from the "currentContentObject" request attribute (the
supported way since v13), which also fixes the long-standing dead $ceData
logic.
As a result contentId now uses the real content element uid (unique per CE)
instead of a random number, fixing potential DOM id / JS variable collisions
when multiple maps are rendered on one page. Flexform values are unaffected
(they continue to flow through $this->settings).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Bring the fork in line with the proven, complete TYPO3 v14 configuration that
already runs on the janda-roscher staging instance, so the fork can serve as the
single source of truth (consumed via Composer VCS) instead of a vendored copy.
Imported from the staging-validated config:
- CType registration via ExtensionUtility::registerPlugin + FlexForm data
structure via static TCA (replaces the removed addPiFlexFormValue()).
- Declarative icon registration through Configuration/Icons.php (ce-default-icon
-> ce_wiz.svg) instead of an imperative IconRegistry call in ext_localconf.
- list_type -> CType upgrade wizard (Classes/Updates) so existing content
element records are migrated, plus the Extension.svg / marker.png assets.
MapController:
- Keep the v14 modernization: read the content object from the
"currentContentObject" request attribute (a fresh ContentObjectRenderer carries
no record data) and replace the deprecated
GeneralUtility::getIndpEnv('TYPO3_REQUEST_HOST') with normalizedParams
->getRequestHost().
- Remove the page-header Google Maps script injection: the API must only load
after the visitor granted consent. Loading happens in Map/Index.html after
sg-cookie-optin emits "externalContentAccepted"; injecting it into the header
loaded Google before consent (DSGVO violation).
The generic Map/Index.html stays in the extension; the janda-roscher-branded
template override moves to the sitepackage in a separate janda-roscher change.
…JR-179) The MapController no longer injects the Google Maps API <script> into the page header (to avoid loading Google before cookie consent), so the frontend template must request the API itself. The generic Map/Index.html only referenced google.maps.* without ever loading it, leaving google.maps undefined. - Wrap the Google map container in a sg-cookie-optin protection element (#cbMapsOptIn / frame-external-content-protection). - Request https://maps.googleapis.com/maps/api/js with the key from settings.googleapi.key, and run the map init only after the API onload — both triggered by the "externalContentAccepted" event (fired on accept and on load when consent was already granted). Mirrors the consent-gated loader the janda-roscher sitepackage template uses, so the extension renders a working, DSGVO-compliant Google map standalone too.
[TASK] complete v14 migration and keep consent-safe map loading (JR-179)
…R-179)
TYPO3 v14 ActionController declares $settings as a typed 'array' property.
Redeclaring it untyped in MapController triggered a fatal at container build
('Type of ...::$settings must be array'), which broke 'typo3 extension:setup'
during deploy. Restore the explicit array type (matches the parent and the
previously deployed code).
[FIX] restore array type on MapController::$settings for TYPO3 v14 (JR-179)
…-179) Make the TYPO3 v14 plugin registration explicit by passing ExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT as the fifth configurePlugin() argument. Behaviour is unchanged (omitting it already defaults to 'CType' internally), but it silences the extension scanner finding for #105076/#105538 and documents intent now that list_type plugin sub types are gone.
[TASK] add explicit v14 CType plugin type to canonical branch (JR-179)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this extension is
cbgooglemaps(formerly Quick Google Maps) is a TYPO3 CMS extension that embeds maps from Google Maps, MapBox or OpenStreetMap/Leaflet into the frontend as a content element, via TypoScript or as a Fluid cObject. It ships an Extbase plugin (MapController), a FlexForm for per-element configuration, custom FormEngine elements (geocoding/preview buttons, JS-library loader) and the JS libraries.Why
Driving ticket JR-179 (janda-roscher v13→v14 upgrade).
cbgooglemapswas capped at TYPO3 ~12.4/13.4 and is a hard blocker for the project upgrade. This PR makes it install and run under TYPO3 14.3.x (PHP ≥ 8.2) while keeping 13.4 support (^13.4 || ^14.0) so the project can transition without a flag day.Base branch:
feature/typo3-13— it is strictly ahead ofdevelop(contains all ofdevelopplus the 12.4/13.4 work: Services.yaml, MapController/TCA updates), so it holds the latest code.v14 changes made
composer.json):typo3/cms-*→^13.4 || ^14.0, explicitphp: ^8.2, added the extbase/frontend/backend/fluid subpackages the code actually uses.TSFE(MapController):TypoScriptFrontendController/$GLOBALS['TSFE']was removed in v14.addJsCss()now usesPageRenderer::addHeaderData()instead of$GLOBALS['TSFE']->additionalHeaderData(works in 13.4 + 14).tt_content.php,ext_localconf.php): the legacylist_typeplugin sub type was removed in v14. The plugin is now a dedicated CTypecbgooglemaps_quickgooglemap:registerPlugin()registers the CType (and auto-adds the wizard item).addToAllTCAtypes('tt_content', 'pi_flexform', $cType, ...)+ a staticcolumnsOverrides[...]['pi_flexform']['config']['ds']— replacing the deprecatedaddPiFlexFormValue()and the removedsubtypes_addlist/subtypes_excludelist.configurePlugin()now passesExtensionUtility::PLUGIN_TYPE_CONTENT_ELEMENT.mod.wizards.newContentElementpage TSconfig (and itsCType=list/list_type=defValues). Since v13 the wizard entry is auto-registered from the CType, so the manual entry caused a duplicate. Wizard title/description are passed toregisterPlugin()instead.Rector
Ran
ssch/typo3-rectorv3.14.2, setTypo3LevelSetList::UP_TO_TYPO3_13, dry-run againstClasses/,Configuration/,ext_localconf.php(isolated docker php:8.3). It flagged exactly one change —MigratePluginContentElementAndPluginSubtypesRectoraddingPLUGIN_TYPE_CONTENT_ELEMENTtoconfigurePlugin()— which was applied. Re-run is clean (Rector is done!).Verified
composer validate --no-check-publish→./composer.json is validphp -lon all PHP files (Classes + Configuration + ext_localconf) → no syntax errorsVerified vs. not-yet-smoke-tested
Verified: version constraints, PHP lint, composer validate, Rector clean. Not yet smoke-tested in a real TYPO3 14 instance — needs an actual v14 install to confirm the content element renders in the backend (wizard, FlexForm, FormEngine buttons) and the map renders in the frontend for all three providers. No live v14 instance was available here.
🤖 Generated with Claude Code