🔲 Google Maps JavaScript API has been loaded directly without loading=async. This can result in suboptimal performance. For best-practice loading patterns please see https://goo.gle/js-api-loading
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.
Since containers are ephemeral and each instance handles requests independently, sharing session data requires using a centralized session storage such as AWS ElastiCache.
ElastiCache can be configured for Valkey (open source Reddis) or Memcache. Valkey is lower cost.
Set up ElastiCache
Create a Valkey server.
Configure a publicly accessible or VPC-limited endpoint, depending on your ECS networking setup.
Choose 3 subnets on same network as ECS containers
Choose the ECS security group
Configure The Docker Image
Add the Redis extension to PHP and enable it in the php.ini configuration. This configuration uses environment variables so the Redis server can be configured with environment variables for each container instance.
Update the host Dockerfile to install Redis and the libs needed to support it. Copy the php ini file into conf.d so it is loaded when PHP starts. This example is from a WordPress 6 image running PHP 8 on Apache.
Docker Composer is for local development container setup. ECS Task definitions are for AWS Cloud Elastic Container Services.
For our local Docker Composer configuration we use a docker-compose secrets file that is not committed to our repository for setting sensitive environment variables.
In this example the PHP_SESSION_* environment variables are read by the PHP startup and substituted in the session.* variables.
For a PHP connection to a cluster, like we have on our AWS fault-tolerant container clusters you and fault-tolerant ElastiCache clusters you need to set something similar in the Task Definition environment variables using the same names as above.
Configure your Application Load Balancer (or Elastic Load Balancer) to enable sticky sessions to reduce the need to share session data across containers. Sticky sessions ensure that a user is always directed to the same container instance during their session.
– Application Load Balancer: Enable Session Stickiness. – Set a **duration-based stickiness** cookie to control how long the user remains connected to the same task/container.
**Note**: Sticky sessions are not ideal for auto-scaling environments or when maintaining container independence is critical, so this should complement, not replace, shared session storage.
Additional Considerations
1. **Security**: – Encrypt session data in transit using TLS (especially when connecting to Redis or RDS). – Ensure that only trusted ECS tasks and resources can access session storage by restricting permissions through IAM roles and security groups.
2. **Performance Tuning**: – Cache session data effectively using low TTLs for Redis or Memcached. – Monitor ElastiCache or RDS instance performance to prevent bottlenecks caused by session sharing.
3. **Scaling and Resilience**: – Use multi-AZ configurations for Redis or RDS. – Consider Redis Cluster for read/write scaling and high availability.
By offloading session management to centralized storage and using ECS best practices, your WordPress instances can efficiently share session information while scaling seamlessly.
Tweaking The Configuration
The cluster is not working exactly as expected.
One container will connect and appears to work properly, but the user experience will swap form a logged in page to a not logged in page mid-session. The assumption is that this is due to the user connection jumping to a different server in the container cluster.
Attempted Resolution: Set PHP session.save_handler to rediscluster
On the staging server the initial php session_save handler (set via environment variable) was set to redis.
Changing this to rediscluster did not change the session switching behavior.
Attempted Resolution: Revise the PHP session_start() call
In WordPress the session_start() was moved from the prior invocation in the WordPress init() hook to the muplugins_loaded hook which loads earlier in the process. This did not seem to have an impact on the issue. Some minor updates to deal with configurations using a Redis Cluster and not were made as well as ensuring we check if a session was already started.
Our Redis Cluster code, invoked during muplugins_loaded with a MySLP_RedisCluster::get_instance() call.
<?php
defined( 'MYSLP_VERSION' ) || exit;
/**
*
*/
class RedisClusterSessionHandler implements SessionHandlerInterface {
private $redis;
public function __construct() {
$redisClusterEndpoint = get_cfg_var( 'session.save_path' );
if ( empty( $redisClusterEndpoint ) ) {
throw new RuntimeException( 'No Redis Cluster endpoint configured' );
}
// Parse and extract host/port (handle both single node and cluster)
$parsedUrl = parse_url( $redisClusterEndpoint );
$redisHost = $parsedUrl['host'] ?? 'localhost';
$redisPort = $parsedUrl['port'] ?? 6379;
// Use an array format required by RedisCluster
$redisClusterNodes = [ "$redisHost:$redisPort" ];
try {
// Initialize RedisCluster
$this->redis = new RedisCluster( null, $redisClusterNodes, 5, 5, true );
} catch ( RedisClusterException $e ) {
throw new RuntimeException( 'Failed to connect to Redis Cluster: ' . $e->getMessage() );
}
}
/**
* Initialize session
* @link https://php.net/manual/en/sessionhandlerinterface.open.php
*
* @param $savePath
* @param $sessionName
*
* @return bool <p>
* The return value (usually TRUE on success, FALSE on failure).
* Note this value is returned internally to PHP for processing.
* </p>
* @since 5.4
*/
public function open( $savePath, $sessionName ): bool {
return true; // No need to do anything here
}
/**
* Close the session
* @link https://php.net/manual/en/sessionhandlerinterface.close.php
* @return bool <p>
* The return value (usually TRUE on success, FALSE on failure).
* Note this value is returned internally to PHP for processing.
* </p>
* @since 5.4
*/
public function close(): bool {
return true; // No need to close anything explicitly
}
/**
* Read session data
* @link https://php.net/manual/en/sessionhandlerinterface.read.php
*
* @param $sessionId
*
* @return string <p>
* Returns an encoded string of the read data.
* If nothing was read, it must return false.
* Note this value is returned internally to PHP for processing.
* </p>
* @since 5.4
*/
public function read( $sessionId ): string {
$sessionData = $this->redis->get( "PHPREDIS_SESSION:$sessionId" );
return $sessionData ?: ''; // Return session data or empty string if not found
}
/**
* Write session data
* @link https://php.net/manual/en/sessionhandlerinterface.write.php
*
* @param $sessionId
* @param string $data <p>
* The encoded session data. This data is the
* result of the PHP internally encoding
* the $_SESSION superglobal to a serialized
* string and passing it as this parameter.
* Please note sessions use an alternative serialization method.
* </p>
*
* @return bool <p>
* The return value (usually TRUE on success, FALSE on failure).
* Note this value is returned internally to PHP for processing.
* </p>
* @since 5.4
*/
public function write( $sessionId, $data ): bool {
return $this->redis->setex( "PHPREDIS_SESSION:$sessionId", 3600, $data ); // 1-hour TTL
}
/**
* Destroy a session
* @link https://php.net/manual/en/sessionhandlerinterface.destroy.php
*
* @param $sessionId
*
* @return bool <p>
* The return value (usually TRUE on success, FALSE on failure).
* Note this value is returned internally to PHP for processing.
* </p>
* @since 5.4
*/
public function destroy( $sessionId ): bool {
return $this->redis->del( [ "PHPREDIS_SESSION:$sessionId" ] ) > 0;
}
/**
* Cleanup old sessions
* @link https://php.net/manual/en/sessionhandlerinterface.gc.php
*
* @param $maxLifetime
*
* @return int|false <p>
* Returns the number of deleted sessions on success, or false on failure. Prior to PHP version 7.1, the function returned true on success.
* Note this value is returned internally to PHP for processing.
* </p>
* @since 5.4
*/
public function gc( $maxLifetime ): int|false {
return true; // Redis handles expiration via TTL, so no need to do anything
}
}
/**
*
*/
class MySLP_RedisCluster extends MySLP_Base {
private $redis;
/**
* Catch cluster redirects (MOVED) using the built-in PHP RedisCluster lib
* @return void
* @throws RedisClusterException
*/
final function initialize() {
$redisClusterEndpoint = get_cfg_var( 'session.save_path' );
if ( class_exists( 'RedisCluster' ) && ! empty( $redisClusterEndpoint ) ) {
try {
$handler = new RedisClusterSessionHandler();
session_set_save_handler( $handler, true );
} catch ( RuntimeException $e ) {
error_log( 'Error initializing RedisClusterSessionHandler: ' . $e->getMessage() );
}
}
if ( ! session_id() && ! headers_sent() ) {
session_start();
}
}
}
SaaS WP Login Processing
wp-login.php
$reauth = empty( $_REQUEST[‘reauth’] ) ? false : true; is set to false.
$user = wp_signon( array() , $secure_cookie “” )
do_action( ‘wp_login’ , $user->user_login “lcleveland” , $user “WP_User” is set)
if ( empty( $_COOKIE[ LOGGED_IN_COOKIE ] )) is NOT empty
LOGGED_IN_COOKIE is something like “wordpress_logged_in_e2ec4afff4940eebb6cd200cc8206825” which IS set on this session
$requested_redirect_to ==> ‘https://staging.storelocatorplus.com/wp-admin/” as set in $_REQUEST[‘redirect_to’]
if ( ! is_wp_error( $user ) && ! $reauth ) { // This is executing because user is set and reauth is not set.
Need to set the WP Secrets the same (keys and salts) on ALL nodes in the cluster that share login. The auth (login) cookies have salt and keys in them and with each server generating their own they will not be validated.
Docker has a method to pass these in via an ENV setting.
The front end sends a request back to WordPress via AJAX to request a list of locations. Part of that request encodes all of the form field entries, including the category drop down selection, into a query-encoded (key/value pairs with an & delimiter) string that is send in the formData property to the backend.
The category ID is not being parsed and filtered properly.
Looking At The Data Request
Via browser developer tools and the network I/O inspector, XHR filter…
HTTP Method: POST URL: /wp-admin/admin-ajax.php Request Payload…
You can see the formdata property in the POST body along with the encoded form data including the cat=5 entry. This is where the requests tells the back end to limit results to those that have WordPress category ID #5 attached to the location.
Diving Into The Code
On the back end the AJAX is routed through the Store Locator Plus® base plugin via the standard WordPress hooks and filters. These are setup in the SLP_AJAX class via this add_ajax_hooks method:
Where the csl_ajax_search eventually finds its way to the find_locations method.
Debugging the find_locations method it looks like the formdata variable coming in via the superglobal $_REQUEST variable is not being set properly.
Digging Into The Malformed Variables
Looking at the call stack the form data is mishandled causing the & in the query string to be encoded as &, this causes wp_parse_args() to set the property name incorrect as you can see in the debugging screenshot below.
Turns out the wp_kses_post() is too aggressive with the data munging and converts & to & which then throws wp_parse_args() for a loop.
Instead we need to use esc_url_raw() to leave most URL entities intact.
This function applies filters that can be hooked to perform specific sanitization procedures for the particular metadata type and key. Does not sanitize anything on its own. Custom filters must be hooked in to do the work. The filter hook tag has the form “sanitize_{$meta_type}_meta_{$meta_key}“.
Only sanitizes specific options known to WordPress (primarily for internal use). After the value has been handled by the functions in the switch statement, it will be passed through a sanitize_option_$option filter.
That means this CANNOT be used for anything that processes HTML elements.
The Code
/**
* Sanitizes a string from user input or from the database.
*
* - Checks for invalid UTF-8,
* - Converts single `<` characters to entities
* - Strips all tags
* - Removes line breaks, tabs, and extra whitespace
* - Strips octets
*
* @param string $str String to sanitize.
* @return string Sanitized string.
*/
function sanitize_text_field( $str ) {
$filtered = _sanitize_text_fields( $str, false );
/**
* Filters a sanitized text field string.
*
* @since 2.9.0
*
* @param string $filtered The sanitized string.
* @param string $str The string prior to being sanitized.
*/
return apply_filters( 'sanitize_text_field', $filtered, $str );
}
esc_attr() Use on everything else that’s printed into an HTML element’s attribute.
esc_html() Use anytime an HTML element encloses a section of data being displayed. This WILL NOT display HTML content, it is meant for being used inside HTML and will remove your HTML.