Store Locator Plus® Internal Docs
SLP Internal Documentation
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
See screen shot as how it shows in Staging , on the Categories page,
a bunch of script under locations but only the first one Named Distribution shows the script
[19-Nov-2024 15:11:30 UTC]
PHP Deprecated: Creation of dynamic property SLP_Power_Category_Manager::$wp_categories_by_id is deprecated
in /var/www/html/wp-content/
plugins/slp-power/include/module/category/SLP_Power_Category_Manager.php
on line 274
Generate Embed is not populating the embed map as the REST API call is generating an internal error.
The MySLP_REST_API is expecting the SLP AJAX property to be set and it is null.
class.myslp.rest.api.php:438, MySLP_REST_API->get_options()
class.myslp.rest.api.php:279, MySLP_REST_API->get_map_options()
MySLP.php:257, MySLP->rest_dispatch_request_filter()
class-wp-hook.php:324, WP_Hook->apply_filters()
plugin.php:205, apply_filters()
class-wp-rest-server.php:1187, WP_REST_Server->respond_to_request()
class-wp-rest-server.php:1041, WP_REST_Server->dispatch()
class-wp-rest-server.php:431, WP_REST_Server->serve_request()
rest-api.php:424, rest_api_loaded()
class-wp-hook.php:324, WP_Hook->apply_filters()
class-wp-hook.php:348, WP_Hook->do_action()
plugin.php:565, do_action_ref_array()
class-wp.php:418, WP->parse_request()
class-wp.php:813, WP->main()
functions.php:1336, wp()
wp-blog-header.php:16, require()
index.php:17, {main}()
The front-end/locations.js is using jQuery.ajax() but it is calling a REST API url, not an AJAX listener endpoint… from the locations.js call…
Update the MySLP_REST_API->get_options() method to use SLP_Ajax::get_instance() to ensure that object is instantiated before use when not doing an AJAX call.
Use the main MySLP::getUserBlogId() to fetch blog IDs.
Use SLP_Ajax::get_instance() versus the uninitialized slplus->AjaxHandler to get the SLP AJAX instance.
slplus->AJAX (slplus->AJAX_Handler) was not initialized because the call is a REST call not an AJAX call.
Users are seeing the wrong locations when logged in, seeing the main super admin locations.
The default location list is not correct. For bhinson it shows 2 locations that belong to super admin. bhinson has 0 locations.
SaaS is using a custom REST endpoint to find locations: …/myslp/v2/locations
This is running a custom interface in the MySLP Dashboard defined wp-content/plugins/myslp-dashboard/include/class.myslp.rest.api.php which fetches locations from include/location/MySLP_Location.php get_locations();
This leverages wp-content/plugins/store-locator-plus/include/module/location/SLP_Location_Utilities.php to provide the location data interface.
In MySLP_Locations the slptbl is set in __construct() which may be too early.
it is coming back as wp_store_locator which is incorrect
It appears switch_to_blog() has not yet been called.
The call stack at this point..
switch_to_blog is called in MySLP class via perform_init_actions()
which is attached to the WP hook ‘init’ with no order of precedence set
The SLP Location Manager is rendered via SLP_Admin_Locations::display_manage_locations_table()
./wp-content/plugins/store-locator-plus/include/module/admin/SLP_Admin_Locations.php
It is pulling locations vis the $slplus->database property which is an instantiation of SLP_Data::
./wp-content/plugins/store-locator-plus/include/module/data/SLP_Data.php
SLP_Data::initialize is setting the SLP_Data::from_slp_table property via SLP_Data::set_database_meta()
This pulls from SLP_Data::db which is an instantiation of the WordPress wpdb class. The table is set by adding wpdb->prefix to the ‘store_locator’ fixed string.
wpdb->prefix is not pulling the proper user prefix , likely due to switch_to_blog() not being called yet.
The main MySLP dashboard loader (wp-content/plugins/myslp-dashboard/myslp-dashboard.php) was initializing the MySLP_Location class which immediate set the properties for SLP table and Extendo table names.
This needed to be deferred until after the MySLP::perform_init_actions() was called.
Added a new method in MySLP_Location::perform_init_actions() that sets the slp and extendo class properties. It is called from within the MySLP::perform_init_actions() to ensure proper timing on the reading of those table names.
Initialize the $slplus->data (SLP_Data) object AFTER the user login, performing the setup in the init action hook within SLP_Actions.
Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /var/www/html/wp-content/plugins/myslp-customer-maintenance/include/MySLP_SysAdmin_View_Profile.php on line 275
When the page renders the debug.log entry will show the message above.
A stop-gap measure is in place to default to text “stripe”, but we need to find out why the myslp->User object does not have a payment method set.
$payment_method = $myslp->User->payment_method ?? 'stripe';