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

Store Locator Plus® Staging (Prerelease) Updates 2024 Edition

We are going to move away from manually-executed grunt tasks via the wp-dev-kit repository and move toward an AWS implemented solution. We are going to leverage AWS developer tools to get the job done.

The general process is that you work on code and merge it into the develop branch of the store-locator-plus repository on CodeCommit (the main upstream source). When that code is deemed “ready for testing” the repo manager will merge the develop branch into the staging branch for the repository. CodePipeline should see the change to the staging branch in the repo and fire off the build and deployment processes.

CodeCommit

The repo, and now official “source of truth” for the SLP code and build kit repositories.

ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/store-locator-plus

The “upstream” aws repo for Store Locator Plus®.

CodeBuild

The build manager that will compile , minify, clean, and otherwise manipulate the stuff in the main SLP repo and prepare it for release. In this case a staging release of the WordPress plugin .zip file.

CodePipeline

Watches the main SLP repo for changes on the staging branch and fires off the CodeBuild execution when that happens.

Our pipeline is the store-locator-plus-staging-release pipeline. It has 3 stages:

Source

The CodeCommit source noted above.

Build

The CodeBuild project noted above.

Note that the CodePipeline takes over the artifact generation output and will dump the final output artifact store-locator-plus.zip into a different CodePipeline specific bucket. This is NOT the same bucket that is specified in the CodeBuild configuration.

Deploy

This is a setting in CodePipeline, NOT a CodeDeploy project, that copies the output artifact (store-locator-plus.zip) from the private CodePipeline artifacts bucket over into the storelocatorplus/builds/staging bucket.

S3 Buckets

This process uses S3 buckets to store build and pipeline artifacts.

The deployment process uses a public web endpoint (HTTP, non-secure) to store the final output artifact alongside some other SLP “goodies”.

The AWS S3 SLP storage site is: http://storelocatorplus.s3-website-us-east-1.amazonaws.com/

This bucket contains an index.html that has been created “by hand” to link to the staging and production zip files.

Image by 🌼Christel🌼 from Pixabay

PHP Documentation

Store Locator Plus® PHP Code Documentation

Generating The Documentation

The phpDocumentor tool is used to generate the docs via a Docker image. You will need Docker installed to generate the docs.

In the main plugins directory (~/phpStorm Projects/WordPress/wp-content/plugins) drop in the following phpdoc.dist.xml file. This version will generate documentation for the SLP and Power add on in a single HTML subsite.

Debug: Results Phone Label Issue

Bug report

The Label for RESULTS PHONE is not appearing in front end

Recreation on QC

Set style on QC to “Default”.

Settings | Results | Results Layout:

<div id=”slp_results_[slp_location id]” class=”results_entry location_primary [slp_location featured]”> <div class=”results_row_left_column” id=”slp_left_cell_[slp_location id]” > [slp_addon section=primary position=first] <span class=”location_name”>[slp_location name] [slp_location uml_buttons] [slp_location gfi_buttons]</span> <span class=”location_distance”>[slp_location distance_1] [slp_location distance_unit]</span> [slp_addon section=primary position=last] </div> <div class=”results_row_center_column location_secondary” id=”slp_center_cell_[slp_location id]” > [slp_addon section=secondary position=first] <span class=”slp_result_address slp_result_street”>[slp_location address]</span> <span class=”slp_result_address slp_result_street2″>[slp_location address2]</span> <span class=”slp_result_address slp_result_citystatezip”>[slp_location city_state_zip]</span> <span class=”slp_result_address slp_result_country”>[slp_location country]</span> <div class=”contact_info”> <span class=”slp_result_address slp_result_phone”>[slp_location phone]</span> <span class=”slp_result_address slp_result_fax”>[slp_location fax]</span> </div> [slp_addon section=secondary position=last] </div> <div class=”results_row_right_column location_tertiary” id=”slp_right_cell_[slp_location id]” > [slp_addon section=tertiary position=first] <div class=”online_info”> <span class=”slp_result_contact slp_result_website”>[slp_location web_link]</span> <span class=”slp_result_contact slp_result_email”>[slp_location email_link]</span> <span class=”slp_result_contact slp_result_directions”><a href=”https://[slp_option map_domain]/maps?saddr=[slp_location search_address]&daddr=[slp_location location_address]” target=”_blank” class=”storelocatorlink”>[slp_location directions_text]</a></span> </div> <span class=”slp_result_contact slp_result_hours textblock”>[slp_location hours]</span> [slp_location pro_tags] [slp_location iconarray wrap=”fullspan”] [slp_location eventiconarray wrap=”fullspan”] [slp_location socialiconarray wrap=”fullspan”] [slp_addon section=tertiary position=last] </div> </div>

Settings | Results | Labels | Phone

Phone

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.

SOP: Code Management

All development is done on personal forked copies (origin) of the primary Store Locator Plus® repositories (upstream). Upstream is considered the “single source of truth” for the current code state.

Additional Reading

Forks and Pull Requests

To begin work, fork the main Store Locator Plus® repository (upstream) to a personal repo (origin).

When code is ready to be integrated with current ongoing development effort, issue a pull request for your origin:update/<something> (see branch conventions below) branch into the upstream:develop branch. When the pull request is approved and merged, the upstream:develop branch be ready for the rest of the team.

Monitor upstream:develop regularly and be sure to fetch-and-merge (aka “pull”) the upstream:develop branch into origin:develop. Any in-progress origin:update/<something> branches that have not had a pull request issues against upstream should be rebased onto the new origin:develop branch. Make sure all conflicts are resolved.