Fix OpenStreetMap PoiCollection crash and migrate build to esbuild - #373
Merged
Conversation
The TYPO3 14 compatibility PR (#365) bumped the extension version to 13.0.0 in composer.json but never added a corresponding ChangeLog entry. Add the missing "Version 13.0.0" section, summarizing the most relevant architectural and compatibility changes introduced by that PR: the new Environment/EnvironmentFactory and MapProviderEnum/ MapperFactory abstractions, the switch to ConnectionPool and CSP-compliant asset definitions, and the removal of TYPO3 13 compatibility and several deprecated helper classes.
Replace the unmaintained gulp/gulp-concat/gulp-uglify/ gulp-sourcemaps toolchain with a single esbuild-based build.mjs script. This reduces the npm dependency tree from 383 to 8 packages and removes the last maintenance burden Dependabot kept flagging for this extension, without changing the resulting minified output. Also fix a TypeError in OpenStreetMap2.js: when a CityMap element has no assigned PoiCollection, the data-pois attribute is rendered as the literal string "null", which JSON.parse turned into a null value and crashed isPOICollectionsEmpty(). Fall back to an empty array with JSON.parse(...) ?? [] instead.
Bump the extension version to 13.0.1 in composer.json and Documentation/guides.xml, and add the corresponding ChangeLog section, covering the OpenStreetMap PoiCollection bugfix and the esbuild build tooling migration.
The "tx_address" mentioned in the previous entry is only a generic fixture extension added to the functional test suite to prove Maps2Registry works independently of a specific table; it is not a real integration target next to tt_address. Describe the actual production change instead: the registry moved from a JSON-file-based Singleton to TcaSchemaFactory-driven, cached, event-listener-based detection of maps2Relation columns.
The previous version bump updated composer.json and Documentation/guides.xml but missed the version field in ext_emconf.php, leaving it out of sync at 13.0.0.
CodeQL flagged two "DOM text reinterpreted as HTML" alerts in OpenStreetMap2.js: showSwitchableCategories() interpolated a category title into insertAdjacentHTML(), and getCheckbox() interpolated a category uid into an innerHTML template literal. Both category properties can originate from sys_category records edited by lower-privilege backend users and were rendered unescaped for every frontend visitor. Build both elements with plain DOM APIs (createElement, textContent, property assignment) instead, which removes the HTML-injection sink entirely.
The same "DOM text reinterpreted as HTML" pattern CodeQL flagged in OpenStreetMap2.js also exists in GoogleMaps2.js: showSwitchableCategories() interpolated a category title into insertAdjacentHTML(), and getCheckbox() interpolated a category uid into an innerHTML template literal. Build both elements with plain DOM APIs (createElement, textContent, property assignment) instead, matching the fix already applied to the OpenStreetMap implementation.
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
1 participant
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.
Summary
compatibility PR (Add TYPO3 14 compatibility #365), which bumped the extension version but
never documented it.
TypeErrorinOpenStreetMap2.js: when a CityMap element hasno assigned PoiCollection,
data-poisis rendered as the literalstring
"null", whichJSON.parseturned intonulland crashedisPOICollectionsEmpty(). Fall back to[]withJSON.parse(...) ?? [].gulp/gulp-concat/gulp-uglify/gulp-sourcemapstoolchain with a singleesbuild-basedbuild.mjsscript, cutting the npm dependency tree from 383 to 8 packages.
Supersedes [TASK] Replace Gulp with Esbuild for Maps2 build chain #371 (adds the bugfix, changelog and version bump on top
of the same underlying esbuild migration) and makes Bump brace-expansion and gulp in /Resources/Private/Build #372
(Dependabot's gulp 4→5 bump) obsolete, since gulp is removed entirely.
composer.json,ext_emconf.phpandDocumentation/guides.xml.Test plan
npm run buildexecuted successfully inside the DDEV container(Node 24), output validated with
node --checkfor all generatedfiles.
Maps (
/extension/maps2/point,/extension/maps2/city-map) andOpenStreetMap (same pages, after switching
mapProvidertoosm),no console errors after the fix.
the browser, no console errors.