While changed settings is an issue and still needs to be investigated, the main culprit here is the upgrade from MySQL 5 to MySQL 8. Servers were upgraded to MySQL 8 as the prior release we no longer supported. Amazon RDS services dropped support for the older MySQL version with a hard cut off in the fall of 2024. As such we were forced to upgrade MySQL; A good thing overall but it involved a lot of data query and code updates and testing.
MySQL added the work “rank” as a reserved word. This conflicts with our Professional an Enterprise feature that has used rank as a standard field name for a decade. Turns out we missed on location where we need to specially mark this field in the data query.
Any sites that have, or had, a location with the rank field set may experience an issue with initial location results not appearing.
Resolved in the 2502.24.01 update to the Experience module. Testing underway 25/02/24 13:00 EST. On production as of 25/02/24 14:45 EST.
This report involves two primary issues. The bigger issue is in the MySQL 8 conflict and is being resolved. We are still investigation the Settings Reset issue.
Settings Reset To Default
Some user settings (noted below) are not the same as they were originally on the production server after the 2502 update. This is still being investigated.
MySQL added the work “rank” as a reserved word. This conflicts with our Professional an Enterprise feature that has used rank as a standard field name for a decade. Turns out we missed on location where we need to specially mark this field in the data query.
The map is not working, and the pins are not showing up. Please let me know what happened. Thanks! We need to fix this ASAP.
Account: uws_at_*_dot_com
Account Level: Professional
Status: active
Expires: 2025-02-26 04:39:09
Versions:
SLP: 2502.21.01
myslp-dashboard-options: 2502.24.01
slp-premier-options: N/A
slp-power: 2502.18.01
slp-experience: 2502.20.01
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.
Resolution
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.
[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
[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
Reproduction
Login or switch to Feeding America San Diego on local develop (or staging)
Select a new Locator Style (“Feeding America”)
Click Select
Dev Notes
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.
Problem
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.
Reproduction
Login as a user , or switch to a user from a SA account.
Go to menu item Store Locator Plus | Settings
Click “View” tab
The user’s selected style should appear – “Feeding America” for the *_feedingsandiego* map for instance. It is not highlighted as selected.
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.
Notes
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.
Development Database Updated, Problem Persisted
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).
Resolution
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
Recap
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.
Update : 2025.01.06 (Jan 6th)
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
On the initial call the store-locator-plus.php MUP is called first an is loading with the initMySLP _jsonp call from the embed script.
the SLPlus::initialize_after_plugins_loaded() is being called.
DOING_AJAX is not set, so createobject_AJAX() is not called.
MySLP_REST_API->get_options() is called, which expects SLP->AJAX to be set, but it is not.
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.
