The SaaS platform uses internal processing hooks to auto-detect the hostname and update the WordPress data accordingly to change the site and home URL. This makes it easier to transfer the data set from production to staging and production. See the Creating A Development or Staging Database Copy post for more details on that process.
A fully qualified domain name (FQDN) example would be ‘dashboard.storelocatorplus.com’. A uniform resource locator (URL) example would be ‘https://dashboard.storelocatorplus.com’.
Places site URL data is stored
Database Tables
wp_blogs
wp_options / wp_<site#>_options
option_name: siteurl set to the URL
option_name: home set to the URL
option_name: myslp_dashboard_theme_options , option_value array key ‘dashboard_site’ set to the URL
wp_site
record id: 1, domain column set to FQDN
Environment Variables
WP_HOME, value URL
WP_HOSTURL , value FQDN
WP_SITEURL, value URL
Dynamic URL Management
The SaaS platform uses the sunrise.php early-loading PHP code to set the domain from the web server provided $_SERVER[‘HTTP_HOST’]. It leverages the WordPress : home_url filter to set the URL for the site impacting WordPress functions such as get_rest_url() and home_url() among a dozen others.
The sunrise.php file will change home_url, site_url, and admin_url dynamically via WordPress filters.
This will update the wp_<site#>_options entries for siteurl and home.
Via MySLP Dashboard Theme
The MySLP Dashboard theme contains some default URLs that are used to create links, including logout, recover password, etc. These options are stored in the wp_options table in the myslp_dashboard_theme_options option key under a subkey in option_value named dashboard_site.
These are coming from $myslp->User->mapview_count.
This is coming from \MySLP_User::mapview_count which is managed with magic method setters and getters. The data is stored in the user_meta object within \MySLP_User in a key names “mapview_count”.
Incrementing Map View Counts
This count is updated whenever \MySLP_REST_API::get_map_options() is called (theoretically/assumed to be whenever the map is rendered).
Resetting Map View Count
This is reset to 0 via \myslp_extend_plan() within the myslp-dashboard-helpers module.
Called By
\MySLP_Dashboard_Controller::check_subscription() Runs when a subscription status is checked, has expired, and is renewed automatically.
\myslp_extend_plan()
\MySLP_Recurring_Payments::initialize() ONLY if payment type is PayPal…
These are coming from the user meta “user_subscription_status” key as a subarray named “referer_urls”.
\MySLP_User::log_referer()
This adds to the list of referring URLs any time a map URL is requested.
If you look through the documentation (or code) for the slp_rest_geocode_invalid_referer hook, you will see that this is only called when running a geocoding request.
This means that up to the current 2501.XX.YY release of MySLP, the list of sites only shows sites where a geocoding request was called from. This is NOT necessarily all the sites that have requested that a map be displayed.
/**
* Check if it is OK to enqueue the admin JavaScript, assume so if the hook starts with our prefix.
*
* @param $hook
*
* @return boolean
*/
Loops over the \SLP_Admin_UI::menu_items[] array which is an array of arrays where the key is the page key and the subarray contains the dislpay class, the hook name, label, etc. like this:
Saving/changing the Style ID (Smart Option: style_id) is what applies the pre-made styles from the Style Server (running on the main SLP site at the moment).
\SLP_SmartOptions::view_appearance()
This method defines the Smart Option for style_id. It is a hidden field (changed with JS on the old Settings | View interface). When changed it calls \SLP_SmartOptions::change_style_id() which directly calls \SLP_Style_Manager->change_style() to load the style changes from the style server.
This also sets up related style Smart Option which displays the “style_vision_list” vue based listing.
The now-defunct theme Smart Option is also set, but this is for legacy support and no longer used.
Only the Style Vision list currently caches style info by setting a transient via \SLP_Style_Manager::cache_style(), it does this as it renders each style response returned from the style server while rendering the vision list.
The cache is kept for one week.
The current style comes from a transient that caches the style server responses.
This is also used to cache the style settings from the server by comparing \SLP_Style_Manager::current_style->slug versus the \SLP_SmartOptions::style value
Used By
\SLP_Style_Manager::style_matches_slug()
which is used by \SLP_Style_Manager::set_active_style()
which is used by \SLP_Style_Manager::apply_style()
This setting is stored in the options_nojs[‘style’] option setting.
It is managed by an instantiation of the SLP_Settings_style_vision_list object.
data_field: options_nojs[style]
label: ‘Locator Style’
type: ‘style_vision_list’
This is a “smart option” managed by SLP_SmartOptions. It is defined in \SLP_SmartOptions:view_appearance() It has a ‘vue’ object type for rendering assistance.
Stack Trace : SLP | Settings
Triggered selecting – Menu : Store Locator Plus® | Settings
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.
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.
\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.
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.
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:
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
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.
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.
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();
}
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.
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.
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”.
