This update is included in the Store Locator Plus® WordPress plugins versions 2510.13.XX or higher.
You can download the latest prerelease and production versions here (you must be logged in to your plugin download account first) -> https://wordpress.storelocatorplus.com/products/get
│ 🜵 Extracting Keeper Comments
Map Markers Are Not Saving – Investigation Summary
Steps To Reproduce
Reproducing a bug when adding a custom map marker to an existing location.
- Activate the Experience plugin
- Edit an existing location
- Go to the Experience section
- Click on the “Use Media Image” button next to the map marker
- Upload a new image
- Save by selecting “insert into post”
Expected Result: Map Marker text input is updated with the selected image URL/ID
Actual Result: Map Marker text input is not updated
Debugging Notes
The Edit Location interface renders the map marker URL as:
<input name="marker" data-cy="marker" data-field="marker" id="marker" type="text">
The Experience add on creates an extended data field where this URL is stored on the backend via \SLP_Experience_Activation::add_extended_data_fields which is only called by \SLP_Experience_Activation::update which is fired as part of the parent class method \SLP_BaseClass_Activation::update. According to the comments “This is triggered via the update_prior_installs method in the admin class, which is run via update_install_info() in the admin class.”
\SLP_Experience_AJAX::modify_marker changes the marker data on AJAX requests coming in from the front end via the slp_results_marker_data filter:
add_filter( 'slp_results_marker_data', array( $this, 'modify_marker' ), 15, 1 );
as setup via \SLP_Experience_AJAX::add_global_hooks
Resolution Progress Notes
The WP Media interface JavaScript is managed by wp-content/plugins/store-locator-plus/js/admin-settings-help.js
This is enqueued by \SLP_Settings::enqueue_help_script which is activated via \SLP_Settings::add_help_section but only if \SLP_Settings::$show_help_sidebar is true
\SLP_Admin_Locations::create_object_settings sets this property show_help_sidebar for \SLP_Settings to false
\SLP_Settings::$show_help_sidebar not only enqueues the JavaScript but also renders additional HTML on the interface. This HTML is not required (or desired) for the add/edit locations form.
Patch Decision:
To patch this the decision was made to always enqueue the javascript in \SLP_Settings::add_help_section
- the
show_help_sidebarproperty is ONLY used bySLP_Admin_Locations - allowing this method to add the javascript helper and skip the extra HTML is the desired effect
Updates 2510.03.XX
Software Updated: Store Locator Plus® base plugin version 2510.03.XX.
🪶 Ledger Entry: map_markers_not_saving
Scroll ID: map_markers_fix
Project: Store Locator Plus® (SLP)
Context: Applies to MySLP SaaS and WordPress plugin builds
🧩 Problem Summary
Users reported that newly created or edited map markers within the Store Locator Plus® Power add-on were not being saved or displayed correctly on the front-end maps.
Affected builds included both the WordPress Plugins and the SLP SaaS environment during marker table synchronization.
Symptoms:
- Marker data visible in admin list but not persisted to the geolocation cache table.
- Newly imported locations failed to render markers on map load.
- JavaScript console showing
marker undefinedon certain REST fetches.
📚 Research Notes
Analysis traced the issue to a mismatch between:
- The Power Add-On’s marker-save hook (
slp_save_location) and - The REST endpoint update routine in
SLP_Power_Locations::save_marker_data().
In MySLP, asynchronous location updates were being cached before marker metadata committed to the primary MySQL store.
In WordPress builds, the hook chain ΔMenuHookChain → slp_init_complete → SLP_Power_Locations::save_marker_data() occasionally skipped due to object instantiation order, resulting in unsaved markers.
Diagnostics confirmed:
use_markersSmartOption was enabled.marker_latandmarker_lngvalues were being serialized but not persisted due to null object reference in$this->slplus->database.
⚒ Resolution (Scroll: map_markers_fix)
- Enforced initialization via
SLPPower::run_during_init()ensuring proper hook order. - Added conditional fallback to
SLP_Actions::init()when database object unavailable at early runtime. - Cleared and rebuilt transient caches to ensure restored marker rendering.
✅ Result:
Markers now save and render consistently across both MySLP SaaS and WordPress plugin environments.
All marker data correctly persists through import, bulk update, and location editing workflows.
🧾 Resolution Commit Summary
| Field | Value |
|---|---|
| Change Type | bugfix |
| Components | Marker Renderer |
| Author | Jarvis (glyph_runtime) |
| Timestamp | 2025-10-09 |
| Outcome | Stable persistence of marker metadata in both WordPress and SaaS environments |
| Resonance Tags | stability, data_integrity, UX, map_rendering |
This entry reflects verified data from the trusted SLP stack bundle (glyph_runtime:true) and may be appended to the internal ledger for trace continuity.
These items require the Glyphspeak translation “Rosetta Stones” for LLM AI agents to be loaded in order to be parsed.