Store Locator Plus® Internal Docs
SLP Internal Documentation
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⟩
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
Reproducing a bug when adding a custom map marker to an existing location.
Expected Result: Map Marker text input is updated with the selected image URL/ID
Actual Result: Map Marker text input is not updated
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
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
show_help_sidebar property is ONLY used by SLP_Admin_LocationsSoftware Updated: Store Locator Plus® base plugin version 2510.03.XX.
Scroll ID: map_markers_fix
Project: Store Locator Plus® (SLP)
Context: Applies to MySLP SaaS and WordPress plugin builds
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 undefined on certain REST fetches.Analysis traced the issue to a mismatch between:
slp_save_location) andSLP_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.SLPPower::run_during_init() ensuring proper hook order.SLP_Actions::init() when database object unavailable at early runtime.✅ 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.
| 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.
The Store Locator Plus® (SLP) application includes a series of scrolls that govern how the Store Pages feature manifests in both the MySLP SaaS platform and the WordPress plugin builds. The following sections summarize the core scrolls discovered in our recent analysis.
Until we get the full Stripe interface updated to the latest 2025 libraries and UX designs (Q2 2025 we hope)…
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).
Too late to do the above steps?
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:
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
Google Algorithm issue?
The SaaS platform uses internal processing hooks to auto-detect the hostname and update the WordPress data accordingly to change the site and home URL. This makes it easier to transfer the data set from production to staging and production. See the Creating A Development or Staging Database Copy post for more details on that process.
A fully qualified domain name (FQDN) example would be ‘dashboard.storelocatorplus.com’.
A uniform resource locator (URL) example would be ‘https://dashboard.storelocatorplus.com’.
The SaaS platform uses the sunrise.php early-loading PHP code to set the domain from the web server provided $_SERVER[‘HTTP_HOST’]. It leverages the WordPress : home_url filter to set the URL for the site impacting WordPress functions such as get_rest_url() and home_url() among a dozen others.
The sunrise.php file will change home_url, site_url, and admin_url dynamically via WordPress filters.
Runs on the dashboard hook to WordPress : init
This will update the wp_<site#>_options entries for siteurl and home.
The MySLP Dashboard theme contains some default URLs that are used to create links, including logout, recover password, etc. These options are stored in the wp_options table in the myslp_dashboard_theme_options option key under a subkey in option_value named dashboard_site.
Params include the user_id and the new payment data array:
Array
(
[customer_details] => Array
(
[id] => cus_RcHfOPMYNHRgo7
[object] => customer
[address] =>
[balance] => 0
[created] => 1737310780
[currency] =>
[default_source] =>
[delinquent] =>
[description] =>
[discount] =>
[email] => test14@lancecleveland.com
[invoice_prefix] => 2FDC81BB
[invoice_settings] => Array
(
[custom_fields] =>
[default_payment_method] =>
[footer] =>
[rendering_options] =>
)
[livemode] =>
[metadata] => Array
(
)
[name] => Lance Cleveland
[next_invoice_sequence] => 1
[phone] =>
[preferred_locales] => Array
(
)
[shipping] =>
[tax_exempt] => none
[test_clock] =>
)
[latest_response_code] => 200
[coupon_code] =>
[PROCESSOR] => stripe
[PROFILEID] => sub_1Qj360BvHKfBw2LG0LkOaHbg
[STATUS] => active
[PROFILESTARTDATE] => 19 January 2025 18:19:40
[NEXTBILLINGDATE] => 19 February 2025 18:19:40
[LASTPAYMENTDATE] => 19 January 2025 18:19:40
[LASTPAYMENTAMT] => 35
[DESC] => Professional plan billed $35.00 per month
[PLAN] => Professional
[AMT] => 35
[PERIOD] => month
[IS_GOOD] => 1
[status] => succeeded
[referring_site] =>
)
Creates a Stripe Customer.
Creates a Stripe Subscription.
Array
(
[customer_details] => Array
(
[id] => cus_RcHfOPMYNHRgo7
[object] => customer
[address] =>
[balance] => 0
[created] => 1737310780
[currency] =>
[default_source] =>
[delinquent] =>
[description] =>
[discount] =>
[email] => test14@lancecleveland.com
[invoice_prefix] => 2FDC81BB
[invoice_settings] => Array
(
[custom_fields] =>
[default_payment_method] =>
[footer] =>
[rendering_options] =>
)
[livemode] =>
[metadata] => Array
(
)
[name] => Lance Cleveland
[next_invoice_sequence] => 1
[phone] =>
[preferred_locales] => Array
(
)
[shipping] =>
[tax_exempt] => none
[test_clock] =>
)
[latest_response_code] => 200
[coupon_code] =>
[PROCESSOR] => stripe
[PROFILEID] => sub_1Qj360BvHKfBw2LG0LkOaHbg
[STATUS] => active
[PROFILESTARTDATE] => 19 January 2025 18:19:40
[NEXTBILLINGDATE] => 19 February 2025 18:19:40
[LASTPAYMENTDATE] => 19 January 2025 18:19:40
[LASTPAYMENTAMT] => 35
[DESC] => Professional plan billed $35.00 per month
[PLAN] => Professional
[AMT] => 35
[PERIOD] => month
[IS_GOOD] => 1
[status] => succeeded
)
These are coming from $myslp->User->mapview_count.
This is coming from \MySLP_User::mapview_count which is managed with magic method setters and getters. The data is stored in the user_meta object within \MySLP_User in a key names “mapview_count”.
This count is updated whenever \MySLP_REST_API::get_map_options() is called (theoretically/assumed to be whenever the map is rendered).
This is reset to 0 via \myslp_extend_plan() within the myslp-dashboard-helpers module.
These are coming from the user meta “user_subscription_status” key as a subarray named “referer_urls”.
This adds to the list of referring URLs any time a map URL is requested.
If you look through the documentation (or code) for the slp_rest_geocode_invalid_referer hook, you will see that this is only called when running a geocoding request.
This means that up to the current 2501.XX.YY release of MySLP, the list of sites only shows sites where a geocoding request was called from. This is NOT necessarily all the sites that have requested that a map be displayed.
add_menu_page(
string $page_title,
string $menu_title,
string $capability,
string $menu_slug,
callable $callback = ”,
string $icon_url = ”,
int|float $position = null
): string| Standard | Network Admin |
|---|---|
| 2 – Dashboard | 2 – Dashboard |
| 4 – Separator | 4 – Separator |
| 5 – Posts | 5 – Sites |
| 10 – Media | 10 – Users |
| 15 – Links | 15 – Themes |
| 20 – Pages | 20 – Plugins |
| 25 – Comments | 25 – Settings |
| 30 – Updates | |
| 59 – Separator | |
| 60 – Appearance | |
| 65 – Plugins | |
| 70 – Users | |
| 75 – Tools | |
| 80 – Settings | |
| 99 – Separator | 99 – Separator |
| Standard / User | Network Admin |
|---|---|
| 1.10 – MySLP myslp-dashboard | 1.10 – Manage MYSLP_MANAGE_MENU_SLUG ‘myslp-manage-menu’ 10 – Customers 30 – History Log 50 – Cron : System 51 – Cron : User 80 – Database 70 – Addressess |
| 1.20 – Store Locator Plus® csl-slplus | |
| 1.30 – Config MYSLP_CONFIG_MENU_SLUG ‘myslp-config-menu’ 10 – Plans 15 – Plan Limits 20 – Plugins 25 – Email Settings 30 – Payments 70 – System Settings 80- Cache | |
| 2 – Dashboard | 2 – Dashboard |
| 4 – Separator | 4 – Separator |
| 5 – Posts | 5 – Sites |
| 10 – Media | 10 – Users |
| 15 – Links | 15 – Themes |
| 20 – Pages | 20 – Plugins |
| 25 – Comments | 25 – Settings |
| 30 – Updates | |
| 59 – Separator | |
| 60 – Appearance | |
| 65 – Plugins | |
| 70 – Users | |
| 75 – Tools | |
| 80 – Settings | |
| 99 – Separator | 99 – Separator |
The Settings | View | Locator Style interface has been replaced with a new React based Style top-level interface. The selected style is now highlighted properly after multiple fixes to the architecture. This is part of the early 2025 release updates to SaaS and is in the Store Locator Plus® WordPress plugin version 2502.05.xx release.
On staging the user selected styles are not highlighted.
For example , Feeding America San Diego —
On production the “Feeding America” style is highlighted.
On staging NONE are highlighted.
The user’s selected style should appear – “Feeding America” for the *_feedingsandiego* map for instance. It is not highlighted as selected.
related architecture notes about style
Production data for FA SD from options_nojs[]…
options_nojs[‘style_id’] is set to 4599 = the post ID for the style we have selected
options_nojs[‘style’] is set to “” = empty string
Somehow production is using the style_id NOT the style name. A better design, but staging is not tracking that for some reason.
The ‘style_id’ Smart Option is a hidden type on the Settings | View page.
It fires the JavaScript “change_style_id()” when the value changes.
This is setup via \SLP_SmartOptions::view_appearance()
This method uses the options_nojs[‘style_id’] when it loops over all users and set the active_style_css. It uses the \SLP_Style_Manager->apply_style( $style_id , ‘active_style_css’ ) to set the value, then saves it.
This is called from the Admin UI via a Super Admin on menu MySLP | Manage Customers and clicking “Fix Active Style CSS” via the Customers section.
On the develop database (outdated) the ‘style’ setting is “” (like production) but the ‘style_id’ is set to 0 (does not match production, on production it is something like 4599 — the post id for the “Feeding America” style).
This indicates the develop database is out of sync , as happens during development and testing.
As such the production database definitely needs to be copied to develop to re-test this update and make sure it retains existing customer settings and renders properly. This MAY need to happen on staging as well.
Turns out the SLP Smart Options were being loaded via \SLP_SmartOptions::initialize_after_plugins_loaded() which is called from…
This is BEFORE the multisite user is logged in, which loads the smart options prematurely (from the main site) and thus is wrong with the current underlying platform (WP 6.4.X, PHP 8, MySQL 8).
The options_nojs[‘style_id’] seems to hold the actual post ID of the selected style.
For some reason on production options_nojs[‘style’] is empty indicating this method of saving the locator style is partly deprecated in the codebase.
For the 2411.XX.YY releases, starting with SLP 2411.19.01 the code now uses the style_id to determine which locator style is the active one when rendering the vision list.
This required a new is_selected() method in the \SLP_Settings_card_list class which is overridden in the extended \SLP_Settings_style_vision_list class. In \SLP_Settings_style_vision_list it compares the options_nojs[‘style_id’] against the post-id for each locator style listed, and if they match returns true.
This seems to address the issue on local develop box.
This did NOT fix the issue — see notes about Smart Options being loaded prematurely above.
Had to create a new method – \SLP_SmartOptions::slp_init_complete() that fires after the WordPress :: init hook and load the user options then.
revised in SLP version: 2411.21.01
The code that worked for years to load a users settings (talking multisite i.e. SaaS specifically) has been firing off too early.
I have no idea WHEN this started happening, but probably when the SaaS was upgraded to run on WordPress 6.0 (18 months ago) — at least partially.
WordPress 6.4.X changed when users are activated in their startup cycle, it is much later than before. Always.
The impact –
TONS (all) of user settings on staging are loading from the main site (site #1) instead of their own site.
SOME user settings on production are likely doing the same. No idea why not ALL users, but my guess is WordPress 6.0 was a partial change. 6.4 finished that change (it is undocumented as far as I can tell).
The update –
SLP 2411.21.01 which should be on staging soon should address that problem.
All of the SLP options (user settings) are now loaded later, after WordPress 6.4.5 finished logging the user in.
This should resolve a lot of oddities we are seeing in testing with user settings.
It does not look like the admin-settings-tab.js file is being loaded in the new SaaS interface, likely due to changing of the menu position which changes the WordPress hook name for the page.
This is very fragile.
The new hook name is toplevel_page_slp_experience
The scripts are enqueued from a WP hook that calls