Store Locator Plus® Internal Docs
SLP Internal Documentation
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
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 |
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
This setting is stored in the options_nojs[‘style’] option setting.
It is managed by an instantiation of the SLP_Settings_style_vision_list object.
This is a “smart option” managed by SLP_SmartOptions.
It is defined in \SLP_SmartOptions:view_appearance()
It has a ‘vue’ object type for rendering assistance.
Triggered selecting – Menu : Store Locator Plus® | Settings
Most recent to oldest…
Renders the list of styles.
When $this->value === $item->clean_title it marks it as selected.
$item is from the list of locator styles fetched from the SLP locator style service (see \SLP_Settings_style_vision_list->items below).
In our test case $this->value is EMPTY string “”.
\SLP_Setting->set_value() appears to have value already set to “”.
Track down the SLP_SmartOptions and how it loads the default values from options/options_nojs into the Smart Option properties.
Sets the value of a setting.
Fetches the value of a setting from \WPOption_Manager::get_wp_option() if necessary.
Extends SLP_Setting.
SLP_Setting type: “style_vision_list”
Extends SLP_Settings_card_list.
Contains the array of styles retrieved from the SLP Locator Styles service (REST call to external service).
Contains the currently set/selected style for the user.
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
See Lance Cleveland’s WordPress Hooks Order Of Precedence.
Generic WordPress + MySLP processing of a page request.
Fires once activated plugins have loaded. The hook is generally used for immediate filter setup, or plugin overrides. The plugins_loaded action hook fires early, and precedes the setup_theme, after_setup_theme, init and wp_loaded action hooks.
Fires after WordPress has finished loading but before any headers are sent. Most of WP is loaded at this stage, and the user is authenticated.
Executed during WordPress : init hook via SLP_Actions::init() after all of the main SLP plugin init stuff has been executed.
add_action( 'slp_init_complete', array( __CLASS__, 'slp_init_complete' ) );Called when processing a REST API call.
\SLP_Premier_AJAX::add_ajax_hooks()
\SLP_AJAX::renderJSON_Response()
\SLP_Experience_AJAX::add_ajax_hooks()
\SLP_Premier_AJAX::add_ajax_hooks()
\SLP_AJAX::execute_location_query()
\SLP_REST_Handler::valid_referer() for any site that is not coming from get_site_url() or get_home_url(). This is run via the WordPress REST API handler via the register_rest_route() for the readable request for geocoding at the wp-json/store-locator-plus/v2/geocode/<address> endpoint. This happens via the permission_callback property.
You will see this message in Generate Embed when reviewing the interface for any user.
As of February 21st, 2024, google.maps.Marker is deprecated. Please use google.maps.marker.AdvancedMarkerElement instead. At this time, google.maps.Marker is not scheduled to be discontinued, but google.maps.marker.AdvancedMarkerElement is recommended over google.maps.Marker. While google.maps.Marker will continue to receive bug fixes for any major regressions, existing bugs in google.maps.Marker will not be addressed. At least 12 months notice will be given before support is discontinued. Please see https://developers.google.com/maps/deprecations for additional details and https://developers.google.com/maps/documentation/javascript/advanced-markers/migration for the migration guide.
Dev Notes
https://storelocatorplus.youtrack.cloud/issue/SLP-14/google.maps.Marker-is-deprecated