For some reason embed scripts from the staging test site do not work on QC such as the QC Ice Cream test page. The embeds work on other sites including local Docker developer test rigs, the LanceCleveland.com blog site, and
This issue appears to have been temporary, and may be cause by a Web Application Firewall (WAF) on AWS blocking requests due to too many requests.
The issue is that any staging.storelocatorplus.com URL was coming back as a 404 but only when the request was made from the qc.storelocatorplus.com domain.
[Tue Jan 20 16:44:46.077513 2026] [core:error] [pid 59] [client 127.0.0.1:47176] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. Use ‘LimitInternalRecursion’ to increase the limit if necessary. Use ‘LogLevel debug’ to get a backtrace.
On the WordPress Test Site (https://qc.storelocatorplus.com/) the Location Import feature of Store Locator Plus® for WordPress (SLP for WP) is not working.
Location import does work on the local Docker container.
Location import does work on staging and production versions of the SaaS application.
The version of the SLP, Power, Experience, and Premier plugins are the same on QC, localhost (the docker container), and the SaaS deployments.
Ensure the Store Locator Plus® and Power plugins are active.
Go to Store Locator Plus | Locations on the sidebar menu.
Click the import tab.
Click the upload CSV button.
Choose a sample CSV file like the one noted below.
Result
The import never starts. The progress meter never appears. No new locations that are in the CSV are added to the location list.
Expected Result
An import information window should show the circular loading progress meter and the location import count when finished. New locations appear on the location list.
Resolution
Status: Partially Resolved
Findings
Turns out that if a user downloads a new version of the Power add on (a zip file) and already has a prior version of the slp-power.zip file in the download directory on their laptop, the browser may create a new file named slp-power-2.zip without direct notification or confirmation it has done so.
If the user uploads this file to the WordPress installation it will create a NEW installation of the Power plugin at ./wp-content/plugins/slp-power-2/. This may or may not reside alongside a version of the older installation at ./wp-content/plugins/slp-power/ which is the standard installation path.
Even if a user deactivates and deletes the existing Power add on , which is best practice, before uploading the new slp-power-2.zip , the new path for the plugin will not match the prior path.
This causes the JavaScript for location imports included in the Power add on to not be loaded.
Workaround
Make sure the downloaded zip files for the plugin follow the standard naming convention:
SLP plugin should be named store-locator-plus.zip
Power add on should be named slp-power.zip
Deactivate and delete the installed versions of any plugins that are being updated.
Upload and install the most recent plugin zip file.
Meta
The Location Import feature is provided by the Power add on (a plugin that works with SLP for WP).
sl_id,sl_store,sl_address,sl_address2,sl_city,sl_state,sl_zip,sl_country,sl_latitude,sl_longitude,sl_tags,sl_description,sl_email,sl_url,sl_hours,sl_phone,sl_fax,sl_image,sl_private,sl_neat_title,featured,rank,category,category_slug,contact,contact_address,contact_email,contact_fax,contact_image,county,department,district,facility_type,first_name,identifier,introduction,last_name,marker,mobile_phone,notes,office_hours,office_phone,region,territory,title,training,year_established
5136,"Amalfi's Italian Restaurant & Pizzeria","664 Long Point Rd",#E,"Mt Pleasant",SC,29464,,32.83928400,-79.85446600,,,,,,,,,,,0,,,,,,,,,,,,,,,,,,,,,,,,,,
5138,"The Wine Bar","664 Long Point Rd","Unit G","Mt Pleasant",SC,29464,,32.83930200,-79.85423300,,,,,,,,,,,0,,,,,,,,,,,,,,,,,,,,,,,,,,
5140,"Burtons Grill & Bar","1876 North Highway 17",,"Mt Pleasant",SC,29464,,32.83029500,-79.83291900,,,,,,,,,,,0,,,,,,,,,,,,,,,,,,,,,,,,,,
Info Gathering Toward Resolution
Path Disclosure
Searching for the difference in the URLs in the JavaScript:
Added additional information to the SLP | Info | Environment tab within the SLP plugin showing the plugin directory and path.
updated \SLP_REST_Environment::get() to add new environment variables
If you upload slp-power-12.zip to a WordPress site your new power directory will be ./wp-content/plugins/slp-power-12/
That is NOT and issue if you’ve NEVER had power installed before (my plugins detect whatever random directory you put in the first time).
However if you UPDATE an existing Power plugin that was already installed at wp-content/plugins/slp-power with a zip file named slp-power-12.zip the app will break. First of all you’ll likely end up with TWO power plugins listed in your plugin directory. Out of habit you will likely delete the older one, which inevitably will be the one in wp-content/plugins/slp-power, leaving the revised path of wp-content/plugins/slp-power-12/ as the new path.
Plugin Update Best Practices
Rename your zip files to the base name only:
store-locator-plus.zip (or store-locator-le.zip if you are an original old-school SLP user from version 5 or earlier)
slp-power.zip
slp-experience.zip
slp-premier.zip
If it won’t let you, sort folder on your computer by name and delete the old copies…. then rename the downloaded zip file t one of the above.
Install the properly named zip file on WordPress:
First delete the original plugin (deactivate/delete) then upload the new zip file.
This process MIGHT work with the inline update like the pic below, but some systems cannot handle the duplicate directory on the server automatically (some do, but not all) . Thus it is safer to deactivate/delete first versus using the “fancy updater” that does an inline replace in WordPress.
The inline update process.
New Research : Reproduced On Localhost
I realized renaming the directory from slp-power to slp-power-2 (or 3) in the IDE will NOT change the mount point in the Docker container. To change that the Docker composer file needs to change the mount point of the volumes.
I created a new composer file that mounts the wp-content/plugins/slp-power directory in the IDE (on the host laptop for Docker) to wp-content/plugins/slp-power-2 in the Docker container.
Shut down the prior Docker container and started a new container with the revised path.
Sure enough, the Power import breaks if the Power add on is NOT installed in ./wp-content/plugins/slp-power/
This indicates an error in the base plugin (SLP) or Power add on that is not allowing the install path to be flexible. It skips loading the required JavaScript library.
Work Toward Resolution
UX Update Show Directories
Let’s show the add on directory paths in the SLP | Info | Environment panel.
Updated \SLP_REST_Environment::get() to show the directory path for any add on directly underneath the plugin version.
\SLP_BaseClass_Admin::enqueue_admin_javascript is the likely culprit which is NOT loading wp-content/plugins/slp-power/js/slppower-admin-locations-tab.js if the directory changes to wp-content/plugins/slp-power-2/js/slppower-admin-locations-tab.js
In the following code snippet from \SLP_BaseClass_Admin::enqueue_admin_javascript
In addition to the fix, I renamed wp-content/plugins/slp-power/js/slppower-admin-locations-tab.js to wp-content/plugins/slp-power/js/admin-locations-tab.js
This makes it more consistent with other plugins. It also allows \SLP_BaseClass_Admin::enqueue_admin_javascript to be simplified to: case 'manage_locations': $files = array( 'js/admin-locations-tab.min.js', 'js/admin-locations-tab.js' ); break;
Power 2511.05.01 now requires SLP 2511.05.01 with the primary fix being in the SLP main plugin.
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:
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_sidebar property is ONLY used by SLP_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 undefined on 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_markers SmartOption was enabled.
marker_lat and marker_lng values 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.
Until we get the full Stripe interface updated to the latest 2025 libraries and UX designs (Q2 2025 we hope)…
Customer Needs To Change Payment Method
BEFORE the subscription expires and is canceled…
Login to our Stripe Dashboard
Go to Subscriptions on the left menu
Find the customer or subscription (can use customer ID, subscription ID, email, etc.)
Click the … action button and click Share Payment Update Link
That will email the customer a link from the Stripe site to update payments for their subscription (which will attach to MySLP automatically… we don’t keep ANY payment info).
Expired subscription we need to fix/extend
Too late to do the above steps?
Login to our Stripe Dashboard
Go to Subscriptions on the left menu
Click the Create Subscriptions button on the top right
Attach to the customer we need to reinstate
For duration pick 1 Cycle : this is important otherwise they get a “forever subscription” by default
Pick the same product/subscription level they had
You may need to type the name “Enterprise” or “Professional” or “Advanced” to see it on the drop down, then click the product / price on the list that appears.
Click Create subscription
This will email the customer a payment / invoice link to get the subscription updated. They should be Able to add a new payment method.
This will also create a temporary subscription for the default cycle (1 month out), essentially giving them a free month to update their payment info etc.
Now you need to get their new subscription ID to put in the MySLP system:
Go to Subscriptions
Look for the new subscription, it should have a status showing it will cancel soon (as they likely have not paid yet)…
Click on the STATUS column to see the subscription details
DO NOT click on the “view subscription” action item as it will only go to the SCHEDULED subscription which has a bastardized subscription ID that is useless to us. If the subscription ID has _sched_ in the name DO NOT USE IT. (see image below for example).
If you click on the status column you should see a normal subscriptions page with details about the customer, subscription, etc.
Copy the subscription ID, it should start with sub_1**** (or another digit possibly but NOT sub_sched_****).
Go to the MySLP dashboard
Find the customer
Edit the customer
Scroll down to the bottom
Record the existing subscription ID information in customer notes (Help Scout, Google Sheets tracking doc, etc.)
Paste the subscription ID from Stripe and save it.
Within 10 minutes or so the subscription should update and the customer account/MySLP subscription should be reactivated. You may need to visit the customer site and pull up the map to force it to re-read the subscription ID ; If you do this the first attempt may show expired. Wait 2 minutes then reload the map page.
Central PA food bank issue Zip code for Harrisburg PA returns incorrectly or no results , V 2503-06
We are currently having an issue where Harrisburg PA Zip codes 17110, 17123, 17124,17125, 17130 when searched using our MYSLP map to locate food resources is returning a home point that is not in the correct area, 17110 returns to somewhere in Washington state, and the others are showing as out of the country which is also not correct. Please advise how to address this. The map with the issues is located at https://www.centralpafoodbank.org/find-help/find-food/.
Interestingly we had the same thing happen Jan 31, 2024
