SaaS Hooks Calls

See Lance Cleveland’s WordPress Hooks Order Of Precedence.

Processing Modes

Base Loop

Generic WordPress + MySLP processing of a page request.

  • WordPress : muplugins_loaded
  • WordPress : registered_taxonomy
  • WordPress : registered_post_type
  • WordPress : plugins_loaded
  • WordPress : set_current_user
  • WordPress : init
    • SLP : slp_init_complete
      • SLP: start_slp_specific_setup
      • SLP: finish_slp_specific_setup
  • WordPress : parse_request
  • WordPress : rest_api_init
  • WordPress : send_headers

WordPress : plugins_loaded

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.

Used By

  • MySLP_Dashboard_Controller :: load_hooks()
    • add_action( ‘plugins_loaded’, array( CLASS, ‘plugins_loaded’ ) );

WordPress : set_current_user

WordPress : init

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.

Used By

  • Site_Architect::__construct()
    • add_action( ‘init’, array( $this, ‘sa_start_session’ ) );
  • SLP_Actions:initialize()
    • add_action( ‘init’, array( $this, ‘init’ ), 11 );

      Sets up the slplus->database object with slplus->database = SLP_Data::get_instance().
      This needs to happen AFTER the WoredPress:set_current_user is called so MySLP has the proper user meta to set the database attributes.
  • MySLP::add_hooks()
    • add_action( ‘init’, array( $this, ‘perform_init_actions’ ) );

User Logged In Traced Calls

  • Site_Architect::sa_start_session()
  • SLP_Actions::init()
  • MySLP::perform_init_actions()

SLP : slp_init_complete

Executed during WordPress : init hook via SLP_Actions::init() after all of the main SLP plugin init stuff has been executed.

Used By

  • \MySLP_Dashboard_Controller::load_hooks()
    • add_action( 'slp_init_complete', array( __CLASS__, 'slp_init_complete' ) );
  • SLP_BaseClass_Addon :: initialize()
    • add_action( ‘slp_init_complete’, array( $this, ‘slp_init’ ) );
  • SLP_Power_Pages :: add_hooks_and_filters()
    • add_action( ‘slp_init_complete’ , array( $this , ‘do_when_slp_ready’ ) , 11 ); // 11 ensures the base slp_init has run for the addon

WordPress : parse_request

Used By

  • WordPress : rest_api_loaded
    in wordpress/wp-includes/rest-api.php
    this eventually calls the REST custom endpoint permission_callback

WordPress : rest_api_init

Called when processing a REST API call.

slp_ajax_response

Used By

\SLP_Premier_AJAX::add_ajax_hooks()

Invoked By

\SLP_AJAX::renderJSON_Response()

slp_ajaxsql_fullquery

Used By

\SLP_Experience_AJAX::add_ajax_hooks()
\SLP_Premier_AJAX::add_ajax_hooks()

Invoked By

\SLP_AJAX::execute_location_query()

slp_rest_geocode_invalid_referer

Invoked By

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

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.

Store Locator Plus® JavaScript Pub/Sub

Store Locator Plus® was updated with a “pub/sub” model a few years ago. This feature is a managed interface for jQuery Callbacks that allows disparate Javascript functions to interact with each other. It works much like hooks and filters in WordPress, but solely within the JavaScript runtime space.

The basic premise is any JavaScript function can call a “publish” method that fires off a stack of callbacks.

slp_Filter('slp_map_ready').publish(cslmap);

What is run by those callbacks is set by having a JavaScript module call a “subscribe” method.

slp_Filter( 'slp_map_ready' ).subscribe( this.initialize );

Architecture: Locations Bulk Action

Location bulk actions allow for users to work on multiple locations at once. Export a list of locations, delete select locations from the location table, geocode locations ,and more.

2209.12

Export locations is our first attempt at making bulk actions work more like a single page application.

Instead of doing a form post and submitting the location list, then reading in some PHP-driven variables to set the JavaScript behavior — in 2209.12 the export process bypasses the form submit.

Bypass is handled by using a pub/sub module with a dynamic filter name “exportBulkAction”. This tells the main SLP JavaScript process to execute the callback stack instead of pushing a form submit. This allows the AJAX call to happen immediately without a full page re-render.

2208.15

The apply button processing is handled in the main plugin’s admin.js file.

It uses jQuery to process form variables and prepare the #locationForm to be submitted.

When submitted it sends the request back to WordPress for standard “full page load” processing.

Architecture: Location Download

A feature provided in the Professional level service is a CSV export of locations via the Location Manager page.

2209.12

This process is being revised so that export bulk action works more like a single page application.

Also see the Bulk Action processor page.

2208.15

The process flow for the Locations : Export CSV…

The process starts with a standard form submit from the Bulk Actions “Apply” button.

WordPress sets up a JavaScript variable location_import that has info about the action “export”.

This triggers a jQuery(document).ready() call that fires another request via AJAX back to WordPress with some new parameters in place.

That AJAX call eventually sends back a CSV file that is stored in a DOM div that was prepared with the jQuery() document loader when the refreshed page (post original submit) was rendered.