Architecture: Update Plugin

Posted by lcleveland in Architecture, Development, Store Locator Plus®

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.

Read More “Architecture: Update Plugin”

Store Locator Plus® JavaScript Pub/Sub

Posted by lcleveland in Architecture, Store Locator Plus®

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 );
Read More “Store Locator Plus® JavaScript Pub/Sub”

Architecture: Locations Bulk Action

Posted by lcleveland in Architecture, Store Locator Plus®

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.

Read More “Architecture: Locations Bulk Action”

Architecture: Location Download

Posted by lcleveland in Architecture, Store Locator Plus®

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.

Read More “Architecture: Location Download”

SOP: Code Management

Posted by lcleveland in Development, Internal Use Only, Process, Store Locator Plus®

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.

Read More “SOP: Code Management”

Sass, SCSS and CSS files

Posted by lcleveland in Development, Process, Store Locator Plus®

Store Locator Plus® uses SCSS files compiled by the Sass application to generate the custom CSS files for the application. To process these files you’ll need to have a builder application, such as Webpack via Node, or an IDE with a file watcher in place. Proper generation of the CSS compilations is critical to creating a proper application interface.

Eventually our process will move to a managed script to build the application stack as we move toward JavaScript interfaces, such as React, as a core of the user experience. In the meantime the IDE file watcher approach is in place.

Read More “Sass, SCSS and CSS files”

Dev Standards

Posted by lcleveland in Debugging, Development, Store Locator Plus®, Testing

git Branching Model

Master / Main

The production branch. This branch should always point to production releases – the code released to the public or in use on production systems.

Staging

The release candidate branch. Prerelease plugins or the plugins/components that are published to dashbeta for the SaaS offering.

Test / Develop

The branch being used for testing integration of ongoing development branches.

Version Identifiers

Starting in August 2022 all product versions will follow a YYMMDD.xx standard where YYMMDD is based on the development start date for primary product releases (Store Locator Plus® for WordPress, MySLP Dashboard,etc.) For related product releases (Power, Front-End, etc.) the date should try to match the main product/service it is related to but this is not a strict rule – rather a suggest to help users easily identify related releases.

The YYMMDD should be 2 digits each and xx should always start at 01 for the first revision. For example 220815.01 is the first iteration for an app that started development on 220815.

Code Formatting / Linting

JavaScript

The preferred linting library is ESLint due to the ongoing React support.

0 comments on “Debugging: Excess Option Lookup”

Debugging: Excess Option Lookup

Posted by lcleveland in Debugging, Development, WordPress

An excess number of option value lookups was discovered while testing Store Locator Plus® 5.13.8 where the option/label_directions was searched multiple times for a single map render. To reduce load on servers this should only happen once, at the start of the initial map rendering.

This is not a blatant “it did something wrong” or “didn’t do something it should” type of bug. This is a performance and resource usage bug and may require some new architcture.

The manifestation:

Debugging path… investigation

Looking for label_directions in the code…

The initial search through the plugins reveals places the settings are created, set, stored, and managed but not the “JavaScript hook” being fired via /wp-json (the REST API for WordPress). So we need to look deeper.

Looking for options/ in the code…

Let’s try the start of the REST API path after the generic /wp-json/store-locator-plus/v2/ part…

We can ignore the assets/ directory… but what else is in here…

Ahhh… the slp_core.js call to slplus.rest_url + ‘options/’ + attribute looks sus…a

Solution (planned for SLP 5.14)

There was a problem in slp_core.js with value testing.

Turns out an empty value causes multiple REST calls. The following is an invalid test to see if a property exists, which is what we want here. Previously it was checking the value was SET and had a “non-falsy” value. In JavaScript lots of things are “kind of true” or “kind of false” (aka Falsy), for example the empty string “” is FALSE. That is not what we want here.

In slp_core.js we ant to replace the if (!<var>) with if (! var.hasOwnProperty()) …

Cause

The call to /v2/options/label_directions was firing once for every location because the default value for the directions label is empty (“”). This was evaluating to false, which forced the SLP JavaScript to query the server to get the value, which set it to “”.

For each location that was rendered the setting was checked… “is the label for directions set?” or more accurately “Is the label for directions set and NOT empty?”. Every time it came back saying “no, it is NOT set” or rather “It IS empty” … so the code would then go ask the REST API server for the label value.

Rinse and repeat.

0 comments on “Debugging: Shortcode Attributes Not Processing”

Debugging: Shortcode Attributes Not Processing

Posted by lcleveland in Debugging, Development, WordPress

Adding attributes to the [slplus] shortcode will override default settings for the Store Locator Plus® plugin on a per-map basis.

We are investigating a shortcode like this:

[SLPLUS center_map_at=”Laverton Victoria ” append_to_search=”Australia” initial_radius=”1000″]

Some of these properties are not functioning as expected in the upcoming SLP 5.13.X release.

center_map_at Test

Note: This feature requires the Experience add on to be active.

Running this test on the Docker localhost, adding a shortcode with ONLY the center_map_at setting.

[slplus center_map_at=”Westford MA 01886″]

How it behaves in 5.12.X…

And in 5.13.8… it is working…

initial_radius Test

Adding initial_radius to our testing… requires some setup.

First change the SLP settings under Results to “Initial Search Radius 10” and leave Center Map At at “Charleston SC”.

The results look as expected… one location within 10 miles of Charleston…

And with center_map_at=”Mt Pleasant SC 29464″ initial_radius=”500″ … also looks as expected…

And with the append_to_search=”…” addition…

Now with the full shortcode…

[slplus center_map_at=”Mt Pleasant SC 29464″ initial_radius=”500″ append_to_search=”, United States”]

And run find locations…

The , United States is appended and appears to be working normally.

And now activating Power 5.13 and Premier 5.12 alongside Experience 5.12 and SLP 5.13.8…

It all works same as above…

Apparently this bug was fixed along the way.