User Selected Locator Style Not Highlighted

Posted by lcleveland in Bugs, Closed Bugs

The Settings | View | Locator Style interface has been replaced with a new React based Style top-level interface. The selected style is now highlighted properly after multiple fixes to the architecture. This is part of the early 2025 release updates to SaaS and is in the Store Locator Plus® WordPress plugin version 2502.05.xx release.

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.

Updating Staging SaaS Server

Posted by lcleveland in Biz Ops, Development, General, Process, Store Locator Plus®

This process is for updating the staging Store Locator Plus® SaaS server running on an ECS cluster after performing code updates.

These processes require a locally installed copy of the MySLP AWS ECS Kit repository which can be found at ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/myslp_aws_ecs_kit.

Edit your code or deployment kit files first. This can include WordPress plugins or themes, the Docker composer or image builder commands, helper scripts, or various configuration files used to manage and deploy the Store Locator Plus® SaaS container images.

Once your updates are ready, make sure the WordPress stack is up-to-date by updating the submodule links, then commit all of your updates to the MySLP AWS ECS Kit repository on the proper branch. There are AWS CodePipeline services running that will monitor the repository for changes, build any images as needed with ECR and deploy them via the Elastic Container Service if possible. Details on the processes are noted below.

Update The Submodules

From the MySLP AWS ECS Kit git project root:

./tools/create_mustuseplugins_stubs.sh

Commit The Code Updates To The Repo

Commit any changes to the MySLP AWS ECS Kit repository.

When you push the changes from your local develop, staging, or production branch an AWS listener service will detect the code changes and run Code Pipeline tied to services such as CodeBuild and ECS to deploy the final Store Locator Plus® SaaS container in the AWS cloud.

Commits to local branches will not trigger a change in the AWS deployments.

Commits to any branch not specifically named develop, staging, or production will not trigger changes in the AWS cloud deployments.

CodePipeline Notes

The CodePipeline that is configured to deploy the staging containers is named myslp-webserver-staging-pipeline.

Stage: Source

The pipeline monitors the staging branch on the AWS CodeCommit repo for the MySLP AWS ECS Kit project at ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/myslp_aws_ecs_kit

Stage: Build

The source will be read from the URL above and a series of commands will be executed in the cloud to create an container image. This image is stored in the AWS Elastic Container Registry as a private image.

The Store Locator Plus® SaaS (internal name: MySLP) container images are stored in the 744590032041.dkr.ecr.us-east-1.amazonaws.com/myslp2024-aarch64 docker image repository.

Staging branches will tag the latest build with the :staging tag.

Stage: Deploy

The deploy stage will execute if the build stage completes successfully. This stage will attempt to take the latest myslp2024-aarch64:staging ECR image and launch an active container in the AWS Elastic Container Service.

The deploy stage will attempt to launch a running container in the myslp-staging-cluster on the myslp-staging-service service within that cluster.

Manual Container Image Update

Build The Container Image and Store On AWS ECR

aws sso login --profile lance.cleveland

aws ecr get-login-password --region us-east-1 --profile lance.cleveland | docker login --username AWS --password-stdin 744590032041.dkr.ecr.us-east-1.amazonaws.com/myslp2024-aarch64

cd ./Docker/Images

docker build --platform=linux/arm64 -t 744590032041.dkr.ecr.us-east-1.amazonaws.com/myslp2024-aarch64:staging .
docker push 744590032041.dkr.ecr.us-east-1.amazonaws.com/myslp2024-aarch64:staging

SaaS Development / ECS Error establishing a database connection

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

Check The Server URL

For local development using composer the Docker/Composers/Secrets/docker-compose-rds-secrets.yml file will have the DB Host URL.

For ECS deployments the URL is in the Task Definition that is being run by the service. After updating the task you will want to deploy it to the ECS Service with Force Deployment and update the running service.

Check The Port

Newer database connections are not connecting on the default MySQL Port 3306 and instead use a different port. Newer systems use port 3309 for the development database server per the RDS database setup example.

Edit the Docker/Composers/Secrets/docker-compose-rds-secrets.yml file and add the port to the end:

SaaS Dev Setup

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

Copy Production Database To Development

Create a copy of the production database from to development on AWS RDS.

Update MySLP AWS ECS Kit RDS Secrets

This assumes you have a local copy of the AWS ECS Kit repo.

ssh://git-codecommit.us-east-1.amazonaws.com/v1/repos/myslp-dashboard

Edit Docker/Composers/Secrets/docker-compose-rds-secrets.yml.

Change the WORDPRESS_DB_HOST to the new AWS RDS endpoint.

Update The Docker Image

Update The Submodules

First update the submodule data and loader files by opening a terminal window at the MySLP AWS ECS Kit root directory.

./tools/create_mustuseplugins_stubs.sh

When this finishes, update this repo and push to origin and the AWS CodeCommit directory via git. 

This will ensure the new submodule list is updated on the ECR Docker Image for the SLP SaaS product.

Build The ECR Image

Validate The ECR Login

aws sso login --profile lance.cleveland
aws ecr get-login-password --region us-east-1 --profile lance.cleveland | docker login --username AWS --password-stdin 744590032041.dkr.ecr.us-east-1.amazonaws.com/myslp2024-aarch64

Build The Image

cd ./Docker/Images
docker build --platform=linux/arm64 -t 744590032041.dkr.ecr.us-east-1.amazonaws.com/myslp2024-aarch64:develop .

This image is built with a local wildcard certificate for *.storelocatorplus.com.

The domain names it can serve via Apache are defined in 000-default.conf which includes:
* local.storelocatorplus.com
* test.storelocatorplus.com
* dashbeta.storelocatorplus.com
* dashboard.storelocatorplus.com

Push The Image To AWS ECR

docker push 744590032041.dkr.ecr.us-east-1.amazonaws.com/myslp2024-aarch64:develop

Running Containers Locally

This kit will allow you to not only build the baseline Docker image for MySLP2024 on the ARM64 (aarch64) architecture but it also provides a mechanism for using that image to launch various test environments on your laptop via named projects running a WordPress and MySQL host.

The local execution is managed via the Docker Compose files in ./Docker/Composers all commands should be executed there. Start with this command:

cd ./Docker/Composers

MySLP2024 Baked In

All the code is baked into the myslp2024-aarch64 image.

Data is served from the AWS RDS Dev MySQL server.

docker compose -f docker-compose-myslp2024-core-dev.yml -f Secrets/docker-compose-rds-secrets.yml -p myslp2024_bakedin up -d

MySLP2024 Local Source

Ensures a copy of the WordPress 6.4.2 code is available for debug tracing in ./Guest/wordpress for inline debugging with xDebug.

Overwrites the SLP specific code files with locally mapped files mounted via Volumes.

Data is served from the AWS RDS Dev MySQL server.

docker compose -f docker-compose-myslp2024-core-dev.yml -f docker-compose-myslp2024-use-localsource.yml -f Secrets/docker-compose-rds-secrets.yml -p myslp2024_localsource up -d

Accessing The Docker Container

Add an entry into /etc/hosts on your local system like this:

Go to MySLP2024 Baked In

All the code is baked into the myslp2024-aarch64 image.

Data is served from the AWS RDS Dev MySQL server.

docker compose -f docker-compose-myslp2024-core-dev.yml -f Secrets/docker-compose-rds-secrets.yml -p myslp2024_bakedin up

MySLP2024 Local Source

Ensures a copy of the WordPress 6.4.2 code is available for debug tracing in ./Guest/wordpress for inline debugging with xDebug.

Overwrites the SLP specific code files with locally mapped files mounted via Volumes.

Data is served from the AWS RDS Dev MySQL server.

docker compose -f docker-compose-myslp2024-core-dev.yml -f docker-compose-myslp2024-use-localsource.yml -f Secrets/docker-compose-rds-secrets.yml -p myslp2024_localsource up

Accessing The Build

Add an entry to /etc/hosts

127.0.0.1 localhost dev.storelocatorplus.com local.storelocatorplus.com localwp.storelocatorplus.com kubernetes.docker.internal kubernetes.docker.internal

Surf to https://local.storelocatorplus.com/

Upgrade The Network

If the core WordPress database engine has been changed you may need to login as a super admin for the SaaS platform and upgrade the network to ensure all the blog sites (customer accounts) are updated to the latest data structures.

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”

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.