On the Generate Embed feature the JavaScript console reports the following when trying to fetch the map_marker_tooltip (Enterprise feature) option:
{
"code": "invalid_option",
"message": "Not a valid option slug.",
"data": null
}Saving/Changing Style ID
Saving/changing the Style ID (Smart Option: style_id) is what applies the pre-made styles from the Style Server (running on the main SLP site at the moment).
\SLP_SmartOptions::view_appearance()
This method defines the Smart Option for style_id.
It is a hidden field (changed with JS on the old Settings | View interface).
When changed it calls \SLP_SmartOptions::change_style_id() which directly calls \SLP_Style_Manager->change_style() to load the style changes from the style server.
This also sets up related style Smart Option which displays the “style_vision_list” vue based listing.
The now-defunct theme Smart Option is also set, but this is for legacy support and no longer used.
$smart_options['theme'] = array(
'type' => 'hidden',
'default' => 'a_gallery_style',
);
$smart_options['style_id'] = array(
'type' => 'hidden',
'call_when_changed' => array( $this, 'change_style_id' ),
);
$smart_options['style'] = array(
'type' => 'style_vision_list',
'show_label' => true,
'wrapper' => false,
'vue' => true,
);
$smart_\SLP_Style_Manager::change_style_id()
Call stack when clicking “select style” on the legacy “style vision list”:
SLP_SmartOptions.php:320, SLP_SmartOptions->change_style_id()
SLP_SmartOptions.php:539, SLP_SmartOptions->execute_change_callbacks()
SLP_Admin_Settings.php:409, SLP_Admin_Settings->save_options()
SLP_Admin_UI.php:538, SLP_Admin_UI->setup_admin_screen()
class-wp-hook.php:324, WP_Hook->apply_filters()
class-wp-hook.php:348, WP_Hook->do_action()
plugin.php:517, do_action()
class-wp-screen.php:424, WP_Screen->set_current_screen()
screen.php:243, set_current_screen()
admin.php:212, {main}()Call stack when clicking “activate” on the new style manager (React based) interface:
SLP_SmartOptions.php:320, SLP_SmartOptions->change_style_id()
SLP_SmartOptions.php:539, SLP_SmartOptions->execute_change_callbacks()
SLP_REST_Handler.php:719, SLP_REST_Handler->update_smart_option()
MySLP.php:266, 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}()Style Caching
Only the Style Vision list currently caches style info by setting a transient via \SLP_Style_Manager::cache_style(), it does this as it renders each style response returned from the style server while rendering the vision list.
The cache is kept for one week.
The current style comes from a transient that caches the style server responses.
An example entry:
stdClass Object
(
[id] => 67
[date] => 2023-02-21T13:38:51
[date_gmt] => 2023-02-21T18:38:51
[guid] => stdClass Object
(
[rendered] => http://3.211.25.112/?post_type=slp_style_gallery&p=67
)
[modified] => 2024-12-21T13:25:44
[modified_gmt] => 2024-12-21T18:25:44
[slug] => basic
[status] => publish
[type] => slp_style_gallery
[link] => https://storelocatorplus.com/slp_style_gallery/basic/
...
\SLP_SmartOptions::style
This is the style vision list rendering.
This is also used to cache the style settings from the server by comparing \SLP_Style_Manager::current_style->slug versus the \SLP_SmartOptions::style value
Used By
- \SLP_Style_Manager::style_matches_slug()
- which is used by \SLP_Style_Manager::set_active_style()
- which is used by \SLP_Style_Manager::apply_style()
- which is used by \SLP_Style_Manager::set_active_style()
\SLP_SmartOptions::style_id
The actual selected style_id.
SmartOptions
Smart Options via the SLP_SmartOptions class (include/module/smartoptions/SLP_SmartOptions.php) handles nearly all of the settings (options in WordPress parlance) for the Store Locator Plus® plugin.
Methods
get_ValueOf( <property:string> )
Get the value of a Smart Option.
Check if a given property exists and return the value.
@param string $property The property to check.
@return bool Returns true if the property exists and is not null, and its 'is_true' property is true. Otherwise, returns false.
is_true( <property:string)
Check if a given property is true.
@param string $property The property to check.
@return bool Returns true if the property exists and is not null, and its ‘is_true’ property is true. Otherwise, returns false.
if ( SLP_SmartOptions::get_instance()->is_true( 'use_territory_bounds' ) ) {
$this->add_territory_bounds();
}
Architecture: Update Plugin
FOR INTERNAL USE ONLY
The process that happens when a plugin is updated, especially the conversion of pre-existing options to SLPlus options / options_nojs serialized JSON objects.
In older releases , including some vestiges that still existing in 2209.X versions, options were stored in a WordPress option_name that match the plugin name. Such as option_name ‘slp-power’ for the power add on. Each add on had its own set of options.
When Smart Options were introduced into the SLP architecture there were two options that stored “all settings”. csl-slplus-options (aka “options”) stores settings that were not being localized and sent to JavaScript. csl-slplus-options_nojs (aka “options_nojs”) are the settings that are not localized. (In theory… both of these will be replaced with a single monolithic store in csl-slplus-options eventually and specific settings retrieved from JavaScript via a REST call).
The idea was to eventually (soon?) convert all separate plugin-specific option settings like option_name = ‘slp-power’ into a standard csl-slplus-options string. Below is the flowchart that describes how that conversion happens.