Store Locator Plus® Internal Docs
SLP Internal Documentation
Some users with active accounts are reporting an expired account notification when viewing the embedded locations on their website.
The core platform has been moved from a proprietary server cluster on Amazon EC2 instances that were self-managed to a container-based platform. This will allow for seamless software updates with minimal downtime during the update process. The previous platform would go into maintenance mode and be unavailable for users for up to 20 minutes when a major software update was performed. The new platform switches software in less than 2 minutes, often with no noticeable downtime for users.
PHP is running on version 8.3.2 which improves security and performance.
WordPress, a core element of the SaaS platform, is running 6.4.5 which improves security and fixes multiple bugs related to user session stabilization.
MySQL, the core database, is running version 8.x which is faster for most queries.
Changing the styles of the Store Locator Plus® interface has been updated to a completely new design. This feature replaces the previous Settings | View | Locator Style interface and now resides in its own top level menu as “Style”.
The SaaS version of Store Locator Plus® will show a preview of the newly selected interface after the settings have been updated. The page will refresh to ensure the encapsulated CSS styling that goes with the new settings is loaded in its entirety.
This interface replaces the legacy interface shown below:
While the generate embed interface helps preview what the map interface may look like on your site, it is often difficult to see the full impact as the page sizes are limited. Users can now create their own test pages to try out a wider variety of page layouts with the embedded map.
The new pages menu appears in the sidebar when a user is logged in.
While we do not restrict the pages at the moment, this is NOT meant to be a full location services or public web hosting option. Please do not direct your general website visitors to pages published on the Store Locator Plus® SaaS platform. This feature can change at any time and is not guaranteed to always be visible to the general public.
The Stripe payment processing engine has been updated to version 3, a major upgrade — two in fact, since the core Stripe engine was initially implemented in the Store Locator Plus® SaaS platform. This will enable us to extend the subscription renewal and modification system and include automated billing for overages while providing more detailed reports on customer usage in a future release.
Add a SaaS Sign up page using the latest Stripe V3 JavaScript API on the SaaS dashboard site. This is mostly to enable rapid turn around testing on staging and development servers but will also provide for newer UX updates to the sign up process as well as better account and subscription management through Stripe in the future.
Fixed in SLP 2502.19.01
Got to Location Details | Add
Name: Test
Latitude: 32.8393273773774
Longitude: -79.85448363551637
In \SLPlus_Location::MakePersistent
$dataTooWrite =
array (
'sl_store' => 'Test',
'sl_address' => '',
'sl_address2' => '',
'sl_city' => '',
'sl_state' => '',
'sl_zip' => '',
'sl_country' => '',
'sl_latitude' => '32.8393273773774',
'sl_longitude' => '-79.85448363551637',
'sl_tags' => '',
'sl_description' => '',
'sl_email' => '',
'sl_url' => '',
'sl_hours' => '',
'sl_phone' => '',
'sl_fax' => '',
'sl_image' => '',
'sl_private' => '',
'sl_neat_title' => '',
'sl_linked_postid' => 0,
'sl_pages_url' => '',
'sl_pages_on' => '',
'sl_option_value' => '',
'sl_initial_distance' => 943.4293089967016,
)Database insert error:
WordPress database error: Processing the values for the following fields failed: sl_latitude, sl_longitude. The supplied values may be too long or contain invalid data.The problem is that Google is falsely creating GPS coordinates on the Google Maps interface likely in an effort to thwart data harvesting.
The latitude/longitude combination 32.8393273773774, -79.85448363551637 represents 14 places after the decimal.
9 places after the decimal represents a length on the earth’s surface of approximately 110 microns.
Anything after the sixth decimal place, about 11cm is fairly useless for general map locations.
In Store Locator Plus 2502.19.01 the \SLP_Admin_Locations_Actions::add_location() method was updated to format incoming latitude and longitude data to present no more than 9 places after the decimal. This is necessary to fit the data into a 14 character data field which is stored as a string.
This can include values with negative representation including “-180.123456789”.
[03-Feb-2025 22:35:07 UTC] PHP Notice: Function register_rest_route was called incorrectly.
The REST API route definition for myslp/v2/locations/(?P\d+) is missing the required permission_callback argument.
For REST API routes that are intended to be public, use __return_true as the permission callback. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/html/wp-includes/functions.php on line 6031
Resolved in 2502.05.01
Add permission call back to check for manage_slp role on REST endpoint for location management.
Fatal error: Uncaught Error: Call to a member function set_database_meta() on null in /var/www/html/wp-content/plugins/store-locator-plus/include/module/admin/SLP_Admin_Activation.php:450New local docker WP install activating SLP on clean database.
https://storelocatorplus.youtrack.cloud/issue/SLP-12/SLP-setdatabasemeta-on-null
This is a code consistency/standard thing.
Why different options?
MySLP uses a lot of SITE_ID_CURRENT_SITE.
looks to be related to get_network_option() calls.
Some places use BLOG_ID_CURRENT_SITE.
Mostly, but not exclusively, for swith_to_blog() calls.
Both are defined in the Docker composer and both are set to 1.
Looks to be a legacy thing where there was (is?) a plan to have a network (the SITE ID) of blogs (the blog ID). In our case they will be one and the same.
Resolved in MySLP dashboard 2502.05.01
[14-Nov-2024 19:52:23 UTC] PHP Notice: Function register_rest_route was called incorrectly. The REST API route definition for myslp-signup/v2/account/(?P\d+) is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/html/wp-includes/functions.php on line 6031
[14-Nov-2024 19:52:23 UTC] PHP Notice: Function register_rest_route was called incorrectly. The REST API route definition for myslp-signup/v2/account is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/html/wp-includes/functions.php on line 6031
[14-Nov-2024 19:52:23 UTC] PHP Notice: Function register_rest_route was called incorrectly. The REST API route definition for myslp-signup/v2/site-architect is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/html/wp-includes/functions.php on line 6031
[14-Nov-2024 19:52:23 UTC] PHP Notice: Function register_rest_route was called incorrectly. The REST API route definition for myslp-signup/v2/site-architect/allowed-plugins is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/html/wp-includes/functions.php on line 6031
[14-Nov-2024 19:52:23 UTC] PHP Notice: Function register_rest_route was called incorrectly. The REST API route definition for myslp-signup/v2/account/get_payment_meta is missing the required permission_callback argument. For REST API routes that are intended to be public, use __return_true as the permission callback. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/html/wp-includes/functions.php on line 6031
Resolved in MySLP Dashboard 2502.05.01
[14-Nov-2024 19:52:23 UTC] PHP Notice: Function register_rest_route was called incorrectly.
The REST API route definition for myslp/v2/locations/(?P\d+) is missing the required permission_callback argument.
For REST API routes that are intended to be public, use __return_true as the permission callback.
MySLP_REST_API->register_routes(class WP_REST_Server { protected $namespaces = ['oembed/1.0' => [...], 'myslp/v2' => [...]]; protected $endpoints = ['/' => [...], '/batch/v1' => [...], '/oembed/1.0' => [...], '/oembed/1.0/embed' => [...], '/oembed/1.0/proxy' => [...], '/myslp/v2' => [...], '/myslp/v2/locations' => [...], '/myslp/v2/locations-limit' => [...]]; protected $route_options = []; protected $embed_cache = [] })
/var/www/html/wp-includes/class-wp-hook.php:324
register_rest_route($route_namespace = 'myslp/v2', $route = '/locations/(?P<id>\\d+)', $args = [0 => ['methods' => 'GET', 'callback' => [...], 'permission_callback' => class Closure { ... }], 1 => ['methods' => 'POST, PUT, PATCH', 'callback' => [...]], 2 => ['methods' => 'DELETE', 'callback' => [...], 'args' => [...]]], $override = *uninitialized*)
/var/www/html/wp-content/mu-plugins/myslp-dashboard/include/class.myslp.rest.api.php:110
[14-Nov-2024 19:25:43 UTC] PHP Notice: Function wp_dequeue_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or login_enqueue_scripts hooks. This notice was triggered by the google_maps handle. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 3.3.0.) in /var/www/html/wp-includes/functions.php on line 6031
[14-Nov-2024 19:25:43 UTC] PHP Notice: Function wp_deregister_script was called incorrectly. Scripts and styles should not be registered or enqueued until the wp_enqueue_scripts, admin_enqueue_scripts, or login_enqueue_scripts hooks. This notice was triggered by the google_maps handle. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 3.3.0.) in /var/www/html/wp-includes/functions.php on line 6031
If you change settings in Staging , Under Map or View get errors , example:
Deprecated: Calling get_class() without arguments is deprecated in
mu-plugins/store-locator-plus/include/module/admin_tabs/SLP_BaseClass_Admin.php on line 592
Added get_class($this) to the method in SLP_BaseClass_Admin on line 592 as required by PHP 8.
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