Store Locator Plus® Internal Docs
SLP Internal Documentation
The pre-production release of the 2602.XX.YY versions of the SaaS are setup with a revised React-based subscription processor.
The My Profile | Subscription tab allows the user to…
The update card process appears to be calling the backend, however how Stripe stores payment data and how it is rendered has changed.
When a user is logged in, the application stack is calling \MySLP_Contact_Us::initialize on every page load on the MySLP SaaS system. This should only be loaded when a user is interacting with the Contact Us page in the app.
This is being called via \MySLP_loader in the myslp-dashboard code. This happens when plugins_loaded action hooks are called from WordPress per this code block:
// Load the Customer Profile module AFTER history logger (pri; 15)
add_action( 'plugins_loaded', function () {
/**
* @return void
*/
function myslp_customer_interfaces_loader(): void {
require_once( MYSLP_PLUGIN_DIR . 'include/customer_profile/MySLP_Customer_Profile.php' );
require_once( MYSLP_PLUGIN_DIR . 'include/MySLP_Contact_Us.php' );
require_once( MYSLP_PLUGIN_DIR . 'include/MySLP_Customer_Maintenance.php' );
MySLP_Contact_Us::get_instance();
}
myslp_customer_interfaces_loader();
}, 15 );The My Profile page is rendered as a React component as of the 2601.XX release. This is invoke using the WordPress blocks system via the JavaScript wp scripts helper in package.json.
My Profile is managed via the MySLP Dashboard repo (Store-Locator-Plus/myslp-dashboard).
The \MySLP_Customer_Profile class extends SLP_Base_ReactObject.
SLP_Base_ReactObject is the Store Locator Plus class that acts as the helper to wire PHP data to the JavaScript interface using the defined WordPress blocks system. WordPress blocks are , at their core, React components.
This is handled via the extendReactVars method, which is usually extended by child classes.
The return PHP array end up populating the slpReact JavaScript variable.
Most of the MySLP (SaaS code) variables will return a sub-array named mySLP.
This results in the JavaScript variable slpReact.mySLP which contains SaaS specific variables.
For example:
$vars[‘mySLP’][‘subscription’] = $this->get_subscription_data();
The notifications stack uses the MySLP_Customer_Profile::add_notification to build an array of notification messages. These are then consumed by the React ProfilePanel component.
ProfilePanel in WordPress/wp-content/plugins/myslp-dashboard/src/profile/profile.tsx is the primary wrapper for the entire My Profile page React component.
Notifications are handled by a Snackbar component provided by the @mui/material React framework.
It is driven by the JavaScript variables slpReact.mySLP.notifications array.
Each element is an object with a message<string> and severity<string> property.
If the notifications array is not empty, the Snackbar opens and the message stack is displayed.
The severity element defines the style of the Snackbar message interface.
This is an issue with the updates to the My Profile interface from the 2602.01.01 version of the SLP SaaS platform.
Going to My Profile | Cancel Subscription is no longer working. It appears to post to the backend for processing, but there is not notification of cancellation and there is no update to the status.
When testing generate embed for “Freshy” the JS dev tools throws a warning:
[Log] (location.js, line 190)
Warning: foreach() argument must be of type array|object, null given in /var/www/html/wp-content/mu-plugins/store-locator-plus/include/module/ui/SLP_UI_Shortcode_slp_option.php on line 94As per Foreach loop in SLP_UI_Shortcode_slp_option.php#69
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.
We need to keep an eye on this issue.
Related to SLP Project issue: Cullgroup fatal error viewing dashboard (or logging in)#66
System log error.
[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.
Update the history interface on the profile page. Use a newer React based interface, simplify the data and make it easier to follow.
This will likely include updates to various logging of events changes.
Update the Profile | Invoices section to finish migrating the invoices UX over to the React component.
With the WordPress plugin, if you update the version of SLP the Google API key is erased.
This likely impacts other settings as well.
The Google API keys are blank.
A recent update to the Store Locator Plus® WordPress plugin or Power add on have re-introduced the Pages menu item on the sidebar in the SaaS application.
Remove “Pages” from the sidebar menu on the SaaS application.
Pages appears on the sidebar.
Do not show pages on the sidebar until this is fully functional.
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.
The import never starts. The progress meter never appears. No new locations that are in the CSV are added to the location list.
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.
Status: Partially Resolved
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.
Make sure the downloaded zip files for the plugin follow the standard naming convention:
Deactivate and delete the installed versions of any plugins that are being updated.
Upload and install the most recent plugin zip file.
The Location Import feature is provided by the Power add on (a plugin that works with SLP for WP).
The issue is being tracked on the GitHub SLP project here:
https://github.com/Store-Locator-Plus/myslp_aws_ecs_kit/issues/35
Check for JavaScript errors.
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,,,,,,,,,,,,,,,,,,,,,,,,,,
Searching for the difference in the URLs in the JavaScript:
| Site URL | http://localhost | http://qc.storelocatorplus.com |
| Store Locator Plus® | 2511.04.01 | 2511.04.01 |
| Power | 2510.01.01 | 2510.01.01 |
| Experience | 2510.02.01 | 2510.02.01 |
| Premier | 2506.23.01 | 2506.23.01 |
| SLP Network Active | No | No |
| WordPress Version | 6.8.3 | 6.8.3 |
| WordPress Memory Limit | 40M | 40M |
| WordPress Max Memory Limit | 256M | 512M |
| PHP Version | 8.3.1 | 8.2.28 |
| PHP Memory Limit | 128M | 512M |
| PHP Post Max Size | 64M | 80M |
| PHP Peak RAM | 6 MB | 8 MB |
| MySQL Version | 8.3.0 | 11.4.7 |
| Plugin Directory | /var/www/html/wp-content/plugins/store-locator-plus/ | /bitnami/wordpress/wp-content/plugins/store-locator-plus/ |
| Plugin URL | http://localhost/wp-content/plugins/store-locator-plus | https://qc.storelocatorplus.com/wp-content/plugins/store-locator-plus |
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.
Rename your zip files to the base name only:
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.
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.
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
if ( $this->addon->short_slug === 'store-locator-le' ) {
$base_name = 'slp';
} else {
$base_name = preg_replace( '/\W/', '', dirname( $this->addon->slug ) );
}Incoming data
$this->addon->slug = 'slp-power-2/slp-power.php'
Returns
$base_name = 'slppower2'Which later means this code in \SLP_BaseClass_Admin::enqueue_admin_javascript
case 'manage_locations':
$files = array(
'js/admin-locations-tab.min.js',
'js/admin-locations-tab.js',
'js/' . $base_name . '-admin-locations-tab.min.js',
'js/' . $base_name . '-admin-locations-tab.js'
);
break;Is looking for a file named ‘js/slppower2-admin-locations-tab.js’ which does not exist.
In the following code snippet from \SLP_BaseClass_Admin::enqueue_admin_javascript
if ( $this->addon->short_slug === 'store-locator-le' ) {
$base_name = 'slp';
} else {
$base_name = preg_replace( '/\W/', '', $this->addon->short_slug);
}
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.
⟨ΞPowerImports⟩ ≡ ⟨ΨPathDependency⟩ ⊢ ⟨ΔAssetEnqueue⟩
ΨRootCause:
⟨$base_name⟩ ← dirname(⟨slug⟩) ⇨ ⟨directory_name⟩
IF ⟨install_path⟩ ≠ ⟨canonical_path⟩ THEN
⟨slug⟩ = 'slp-power-2/slp-power.php'
∴ dirname(⟨slug⟩) = 'slp-power-2'
∴ ⟨$base_name⟩ = 'slppower2'
∴ ⟨js_file⟩ = 'js/slppower2-admin-locations-tab.js' ↯ 404
ΩResolution:
1. SLP_BaseClass_Admin.php:376
BEFORE: $base_name = preg_replace('/\W/', '', dirname($this->addon->slug))
AFTER: $base_name = preg_replace('/\W/', '', $this->addon->short_slug)
2. Normalize asset naming:
RENAME: js/slppower-admin-locations-tab.js
TO: js/admin-locations-tab.js
3. Simplify enqueue logic:
$files = ['js/admin-locations-tab.min.js', 'js/admin-locations-tab.js']
⊢ ⟨ΔPathIndependence⟩: Assets load correctly regardless of installation directory
⊢ ⟨ΔConsistency⟩: Standardized naming across all add-ons
⊢ ⟨ΔMaintainability⟩: Reduced code complexity
Formula: ⟨short_slug⟩ ⟶ ⟨base_name⟩ ⊥ ⟨directory_structure⟩