Category: General

The Settings Interface architecture drives most of the legacy Store Locator Plus admin interfaces. These are the interfaces customers interact with most often, especially on the SaaS platform. It is the main component of the SLP Dashboard for SaaS.

It was originally written to manage the UI surfaces that present the myriad of settings (options) available to customers. It presents the “dials the users turn” to change how their store locator maps and directory presentations are configured. It grew to cover other admin UI interfaces including the Locations Interface.

Research Notes

About SLP_Settings

Extends SLP_Base_ReactObject which extends SLPlus_BaseClass_Object

SLP_Settings::render_settings_page

Outputs the HTML for settings pages, including the location details page (it uses the “settings” page construct). The output all ends up in a HTML element: <div class=’dashboard-wrapper’>…</div>.

General layout:

• <div class=’dashboard-wrapper’>
  • <header id=”dashboard-header” class=”dashboard-header”> = React blue bar header
  • <div class=’dashboard-main store-locator-plus’>
    • <section class=’dashboard-content’>
      • <div id=’wpcsl_container’ …>
        • <form method=’post’ class=’slplus_settings_form’ …>
          • …
          • <div id=”main” class=”dashboard-content-inner panel-settings”>
          • <div id=”wpcsl-nav” class=”sub_navigation”> = from \SLP_Settings::sublevel_navbar
          • <div id=”content” class=”content js settings-content”>

The settings page header

The page header ends up in:

<header id="dashboard-header" class="dashboard-header"><!-- react slp_adminheader --></header>

Which is setup and managed with:

		// -- include the asset file to get the WordPress Scripts defined dependencies and version ID
		$asset = include SLPLUS_PLUGINDIR . 'build/slp_adminheader/script.asset.php';

		wp_enqueue_script( 'slp_adminheader', SLPLUS_PLUGINURL . '/build/slp_adminheader/script.js', $asset['dependencies'], $asset['version'], true );

		wp_add_inline_script( 'slp_adminheader', 'const slpReact = ' . wp_json_encode( $this->get_vars_for_react() ) . ';', 'before' );

Rendered via the React component at
wp-content/plugins/store-locator-plus/src/components/AdminHeader.js

That renders React Components:

• <CssBaseline/>
• <AdminHeader/>

Where <AdminHeader/> renders as:

• <AppBar position=”sticky”>
  • <Toolbar>
    • <Typography variant=”h6″ component=”div”
      sx={{flexGrow: 1}}>{slpReact.pageName}</Typography>
    • {mainButtonGroup}
    • <Tooltip title={__(‘Documentation’, ‘store-locator-le’)}>
      • <IconButton … documentation … />

The settings page sub navbar (menu)

In the current version the header element DOES NOT contain the sub navbar.

It is rendered via SLP_Settings::sublevel_navbar deep inside the <div class=’dashboard-wrapper’>…</div> element.

React Update To Render Subnavbar

The goal is to render the \SLP_Settings::sublevel_navbar HTML output using React instead of the current PHP and HTML implementation.

The AdminHeader at wp-content/plugins/store-locator-plus/src/components/AdminHeader.js renders the top-of-page header with the page name and some interactive icon buttons.

The task is to add a submenu below the Toolbar that is comprised of the sections currently residing in $this->sections in the \SLP_Settings::sublevel_navbar method.  Using the $titleText ($section->name) within.  The wp_kses_post function current used to set $titleText is not necessary as the $section->name is already considered "clean".

The best way to get the variables into React so they are accessible in JavaScript is to modify the \SLP_Base_ReactObject::get_vars_for_react method.  Instead of attempting to override or extend the base \SLP_Base_ReactObject::get_vars_for_react method, add a filter in \SLP_Settings for slp_react_vars.   That will extend the react variable array via this return method on the end of the get_vars_for_react method:
apply_filters( 'slp_react_vars', $defaultVars );

You will find a good reference implementation of the slp_react_vars filter via:
\Customer_Profile_Site_Info::initialize - adds the filter for that class
\Customer_Profile_Site_Info::extendReactVars - extends the available JavaScript variables for React

In our case we are not extending MySLP variables, so the SLP_Settings::extendReactVars method should be more like this:
$vars['SLP']['sections'][] = array( 
'name' => $section->name,
'div_id' => ! empty( $section->div_id ) ? $section->div_id : $section->slug,
'link_id' => "wpcsl-option-{$div_id}"
);
This should be set up by looping through $this->sections in a new extendReactVars method in SLP_Settings.

This should create a horizontal navbar that shows and reveals each section by the div id. This may require further refinement as the current system uses outdated JavaScript and jQuery to hide and reveal subsequent divs by using the div IDS as noted in the link_id property.   For now we will assume that if React renders the components correctly the pre-existing JavaScript will take over.

Initial Results

Works on locations page.
Does not work on Settings page.
Spacing is not well defined, needs more space between menu items.

The locations interface needs a major overhaul.

Let’s investigate the process and where we can start shimming some React components.

Research

Main Loader : Locations | Location Details (SaaS) Menu

• \SLP_Admin_UI::create_admin_menu
  • The main hook attached to \SLP_Admin_UI::$menu_items[‘slp_manage_locations‘]
  • When clicked, fires \SLP_Admin_UI::renderLocationsPage
    • Which calls \SLP_Admin_Locations::display

SLP_Admin_Locations

extends WP_List_Table – this is already going to be a shit show. The WP_List_Table interface is from 1902. Maybe before that. It is awful.

Referenced by:

• \MySLP_Admin::do_admin_startup()
  • Setting the screen property , probably not needed:
    SLP_Admin_Locations::get_instance()->screen = ‘store-locator-plus_page_slp_manage_locations’;
• \SLP_Power_Pages_Admin::extend_location_edit()
  • Only if Store Pages is active, add an edit section to show an “edit Store Page” link
• \SLP_Power_Pages_Admin::set_page_actions()
  • Add the recreate store page action hyperlink under each location on the table
• \SLP_Actions::save_screen_options()
  • To save the screen options, which is currently only the page (table rows) length.
• \SLP_Admin_Locations_Add::
  • initialize
  • extended_data_block – for extended data fields
• \SLP_Admin_UI::renderLocationsPage
  • To render the UI
• \SLP_Location_LoadFromWP::import
  • To only report back any URL the person puts in is invalid.
  • This is called from \SLP_Admin_Locations_Actions::process_actions when the current_action is load_from_wp
  • This is setup from \SLP_Admin_Locations_Load
• \SLP_Settings_manage_locations_table::display
  • A shim for $this->settings->add_ItemToGroup( array(
    ‘group_params’ => $group_params,
    ‘type’ => ‘manage_locations_table’,
    ) );

Notice: Function WP_Scripts::add was called incorrectly.

The script with the handle “google_maps” was enqueued with dependencies that are not registered: slp_core.

Reproduction

• Login as admin on WordPress (http://localhost/wp-admin/)
• Make sure the SLP base plugin is active
  • No other plugins are needed
• Go to the Location Details page (http://localhost/wp-admin/admin.php?page=slp_manage_locations)

---

Dev Notes

SLP Architecture

slp_core (WordPress/wp-content/plugins/store-locator-plus/js/slp_core.js)

slp_core is the WordPress handle for the slp_core.js file.
slp_core.js is the primary Google maps interface between WordPress and JavaScript

Where the slp_core is found in store-locator-plus v2603.03.01

slp_core is REGISTERED here: \SLP_Actions::wp_enqueue_scripts
slp_core is currently only enqueued here: \SLP_UI::render_shortcode

---

google_maps (Google public Google Map JavaScript loader)

This loads a URL similar to:
https://maps.googleapis.com/maps/api/js?libraries=geometry,marker&v=quarterly&language=en&region=US&key=<GOOGLE_API_KEY>&loading=async

In the JavaScript this is referenced as google.maps.*

Google Maps is only enqueued here with the google_maps hook: \SLPlus::enqueue_google_maps_script
* @used-by \SLPlus::nqGoogleMaps
* @used-by \SLP_Actions::wp_enqueue_scripts
* @used-by \SLP_Admin_UI::initialize via the WordPress admin_enqueue_scripts hook

Non Admin Implementation

google_maps is used for users that are not logged in (non-admin) when rendering the SLPLUS shortcode.

This is managed via \SLP_UI::render_shortcode

\SLP_Power_UI::at_startup adds google_maps as a js_requirement (managed by \SLP_BaseClass_UI as part of normal UI interface management). This is likely unnecessary.

JavaScript References

• SLP
  • js/slp_core.js
• Power add on (slp-power)
  • slp-power_userinterface.js
• Premier add on (slp-premier)
  • js/markerclusterer.js
  • slp-premier_userinterface.js

Admin Implementation

This is called on the slp_manage_locations (Location Details) admin page: \SLP_Admin_UI::initialize
via add_action( ‘admin_enqueue_scripts’, array( $this, ‘enqueue_slp_core_and_google_maps’ ) );

JavaScript References

• SLP
  • js/slp_core.js
  • admin-locations-tab.js
• Premier add on (slp-premier)
  • admin-locations-tab.js
  • admin-settings-tab.js
  • admin.js

---

AI Actions

Prompt

@amelia – We need to fix a script enqueue issue on the Location Details page
___
The script with the handle “google_maps” was enqueued with dependencies that are not registered: slp_core.
__

This error is caused because the WordPress script with the handle slp_core is not enqueued.

__

Option 1: We could enqueue this by calling \SLP_UI::render_shortcode

For the JavaScript in slp_core to be fully functional it requires localized variables.
Currently this only happens in \SLP_UI::render_shortcode
The problem is that \SLP_UI::render_shortcode has the extra overhead:
– Generating a large HTML output string
– Firing a slp_after_render_shortcode action
We only want the JavaScript variables configured and then localized via \SLP_UI::localize_script

If we use this method, we would need to bypass the HTML output and slp_after_render_shortcode action hook processing.

The best way to hook that would be to rewrite \SLP_Admin_UI::initialize to call a new method:
– Replace add_action( ‘admin_enqueue_scripts’, array( $this->slplus, ‘enqueue_google_maps_script’ ) );
– With add_action( ‘admin_enqueue_scripts’, array( $this, ‘enqueue_slp_core_and_google_maps’ ) );

Create a new method \SLP_UI::enqueue_slp_core
– Extracts the first chunk of \SLP_UI::render_shortcode up to the wp_enqueue_script( ‘slp_core’ );
– It needs to accept the parameters from \SLP_UI::render_shortcode

Create a new method \SLP_Admin_UI::enqueue_slp_core_and_google_maps
– call the new \SLP_UI::enqueue_slp_core method
– call \SLPlus::enqueue_google_maps_script

Update \SLP_UI::render_shortcode to call \SLP_UI::enqueue_slp_core to replace the code that was moved to the new \SLP_UI::enqueue_slp_core method

AI Results

\SLP_UI::register_slp_scripts_if_needed is a duplicate of \SLP_Actions::wp_enqueue_scripts.
This unnecessary extra code.
Duplicate code should be avoided when possible.

Created \SLP_UI::enqueue_slp_core with admin_safe flag resulting in inefficient architecture.
This is only called with the admin_safe flag from \SLP_Admin_UI::enqueue_slp_core_and_google_maps.
The register_slp_scripts_if_needed call in the admin_safe short circuit block can be put inline in the calling method as a call to \SLP_Actions::wp_enqueue_scripts.
The admin_safe only method localize_script_admin_safe could should be in SLP_Admin_UI as it is an admin only method: \SLP_Admin_UI::localize_script_admin_safe.
The wp_enqueue_script( ‘slp_core’ ); call can be in the calling method as well.
Returning the $attributes array is not necessary.

My fixes to the AI work:

Rip out the admin_safe short circuit from SLP_UI and place the equivalent code in SLP_Admin_UI as these updates only related to admin hooks. SLP_UI relates to non-admin code and should not have admin-only methods in there. Us nqGoogleMaps in admin as that can certainly load in async versus defer mode.

in SLP_Admin_UI

	public function enqueue_slp_core_and_google_maps( string $hook = '' ): void {
		$slp_actions = SLP_Actions::get_instance();
		$slp_actions->wp_enqueue_scripts(); // misnomer - registers the slp_core script

		$this->localize_script_admin_safe();
		wp_enqueue_script( 'slp_core' );

		$this->slplus->nqGoogleMaps( $hook );
	}

	/**
	 * Localize only the data needed for admin enqueue paths without invoking shortcode SmartOptions callbacks.
	 */
	private function localize_script_admin_safe(): void {
		$scriptData = array(
			'options'              => is_array( $this->slplus->options ) ? $this->slplus->options : array(),
			'environment'          => array(
				'addons'      => $this->slplus->AddOns->get_versions(),
				'slp_version' => SLPLUS_VERSION,
			),
			'plugin_url'           => SLPLUS_PLUGINURL,
			'ajaxurl'              => admin_url( 'admin-ajax.php' ),
			'nonce'                => wp_create_nonce( 'wp_rest' ),
			'apikey'               => SLPlus::get_instance()->get_apikey(),
			'rest_url'             => rest_url( 'store-locator-plus/v2/' ),
			'messages'             => $this->get_messages(),
			'shortcode_attributes' => $this->js_attributes,
		);

		ksort( $scriptData['options'] );
		wp_add_inline_script(
			'slp_core',
			'const slplus = ' . wp_json_encode( $scriptData )
		);
	}

	/**
	 * Set the messages for us in the JS array.
	 *
	 * @return string[]
	 */
	private function get_messages(): array {
		$messages = $this->slplus->Text->get_text_group( 'messages' );

		return apply_filters( 'slp_js_messages', $messages );
	}

In SLP_UI

Move the localize_script_admin_save to the SLP_Admin_UI module where it belongs. Have register_slp-scripts_if_needed method call SLP_Actions->wp_enqueue_scripts in SLP_Actions.

	private function register_slp_scripts_if_needed(): void {
		$slp_actions = SLP_Actions::get_instance();
		$slp_actions->wp_enqueue_scripts();
	}

---

Update

The latest update needs to be reviewed. It is calling enqueue_google_maps_script from \SLP_Admin_UI::initialize
With add_action( ‘admin_enqueue_scripts’, array( $this, ‘enqueue_slp_core_and_google_maps’ ) );

Need to look at Premier interfaces listed above for Google Maps interactions.

Settings | Map | Map Center Fallback

This should be showing the Google Map to show the map center.

Read more: Prod v Stage Settings Testing

---

iknowkungfu (883.881)

Production : 2503.19