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()

\SLP_SmartOptions::style_id

The actual selected style_id.

Select STYLE or Make Changes Deprecated Error

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.

Locator Style Architecture

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.

  • data_field: options_nojs[style]
  • label: ‘Locator Style’
  • type: ‘style_vision_list’

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.

Stack Trace : SLP | Settings

Triggered selecting – Menu : Store Locator Plus® | Settings

Most recent to oldest…

  • SLP_Settings_card_list.php:42, SLP_Settings_card_list->display()
    • SLP_Settings_Group.php:88, SLP_Settings_Group->display()
      • SLP_Settings_Section.php:94, SLP_Settings_Section->display()
        • SLP_Settings.php:384, SLP_Settings->render_settings_page()
          • SLP_Admin_Settings.php:289, SLP_Admin_Settings->display()
  • SLP_Settings_style_vision_list.php:15, SLP_Settings_style_vision_list->get_items()
    • SLP_Settings_card_list.php:28, SLP_Settings_card_list->at_startup()
      • SLP_Setting.php:48, SLP_Setting->initialize()
        • SLP_Admin_Settings.php:213, SLP_Admin_Settings->add_view()

Showing The Currently Selected Style

\SLP_Settings_card_list::display()

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).

Stack Trace : setting the initial value of the ‘style’ property (option)

\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.

  • SLP_SmartOptions.php:1784, SLP_SmartOptions->set_valid_option()
    • SLP_SmartOptions.php:1832, SLP_SmartOptions->set_valid_options_nojs()
      • SLP_SmartOptions.php:1661, array_walk()
        • SLP_SmartOptions.php:1661, SLP_SmartOptions->slp_specific_setup()
          • SLP_SmartOptions.php:1513, SLP_SmartOptions->initialize_after_plugins_loaded() SLPlus.php:386
            • SLPlus->initialize_after_plugins_loaded()

Class : SLP_Setting

Methods

set_value()

Sets the value of a setting.

Fetches the value of a setting from \WPOption_Manager::get_wp_option() if necessary.

Class : SLP_Settings_card_list

Extends SLP_Setting.

SLP_Setting type: “style_vision_list”

Class: SLP_Settings_style_vision_list

Extends SLP_Settings_card_list.

Properties

items : SLP_Setting_item[]

Contains the array of styles retrieved from the SLP Locator Styles service (REST call to external service).

value

Contains the currently set/selected style for the user.

User Selected Locator Style Not Highlighted

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.

Dev Notes

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.


options_nojs[‘style_id’]

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()


\MySLP_Customer_Management->fix_active_style_css()

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…

  • SLP_SmartOptions.php:1515, SLP_SmartOptions->initialize_after_plugins_loaded()
    SLPlus.php:386, SLPlus->initialize_after_plugins_loaded()

    WordPress :: plugins_loaded

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

Related

See saving/changing style id.

New Stylesheet for Feeding America San Diego

They are looking for a Store Locator Plus® locator style that matches the UX on Oregon Food Bank.

“…since most of the people viewing our map are looking at it from their phone that is the priority”

Our current map has several layout issues including cut off of the search bar and overflow of location information on mobile (examples attached.)

We would like the primary colors of the map to be:

Blue: HEX#005487
Orange: HEX#DE7C00

Oregon Food Bank : Mobile

Oregon Food Bank : Desktop

Requested by Feeding America San Diego (dwilliams_at_).

Dev Notes

Blockers

UX Improvement Ideas

Store Locator Plus® Staging Embedded Map

Label Settings via Locator Layout

Use Case

The locator layout should be able to set any setting in SLP.

The Default Locator Style was updated to change “label_phone” from “Phone” to “Phone ” on the main Store Locator Plus® site (this is managed in the Premier Services plugin).

Problem

Setting the label_phone with a space at the end is not making it to the settings on a user site. It appears as though trim() is being called when the data is recieved.

Research

Cannot reproduce after fixing some JavaScript errors on the admin processor.