Open
Conversation
Items can now have any number of named locations. The admin edit form uses a Leaflet.draw toolbar to add, reposition, and delete markers. Each marker has an optional label editable via popup. The browse map, item show pages, exhibit map blocks, and static site export all reflect multiple locations.
The multi-location rewrite broke the pre-existing behavior of initializing the edit map at the item's saved coordinates and zoom. For single-location items the saved zoom is now respected. For multi-location items fitBounds overrides the center on tab select.
The multi-location rewrite dropped the panTo call after adding a geocoded marker, so the map no longer moved to the found location.
Switch from single-resource format (id/url) to multi-resource format (count/url) to support items with multiple locations. Adds item_id as a whitelisted index param with applySearchFilters support so the url is resolvable.
Leaflet.draw is needed on the item edit form and the contribution form. Loading it globally is not ideal but matches the existing approach for Leaflet itself.
Adds a button to every map (browse, item show, item edit) that fits all markers in the viewport. Translatable strings for the control are passed from PHP to JS via the options object.
KML was a Google Maps era holdover, never a natural fit for Leaflet. A dedicated browseJsonAction() now serves browse-json.php, moving marker HTML assembly to PHP where Omeka helpers are available. Removes the KML route, context switch filters, and ~80 lines of client-side XML parsing.
Before multi-location support, the item marker was placed at the map center via center.show. That was replaced by the options.points loop. Inline and remove the now-single-use _getCenter() helper.
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.
Items can now have more than one location. Each location has an optional label, and the item edit form uses Leaflet.draw to add, reposition, and delete markers. All map views have been updated to reflect this. Includes a database migration.
Breaking changes
This feature requires a major version bump (4.0) due to some breaking changes:
geolocationsfield — the shape of this field in the items API response has changed to support multiple locations per item.Table_Location::findLocationByItem()— removed and replaced byfindLocationsByItem()to support multiple locations per item.Existing API consumers and any code calling these methods directly will need to update.
Cleanup
Several pieces of holdover code have been removed:
map_type— a database column and API field from the Google Maps era, later repurposed to track which mapping library was in use. Once Google Maps support was dropped it was always'Leaflet'and served no purpose.