Dynamic Site URL / Home URL

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.

Via MySLP Dashboard

\MySLP_Addon::updateUserBlogDomain()

Runs on the dashboard hook to WordPress : init

  • \MySLP_Addon::updateUserBlogDomain()
    • \MySLP_Addon::performUserBlogUpdates()
      • \MySLP_Addon::change_blog_urls_if_needed()

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.

SaaS Returning Wrong Location List

Users are seeing the wrong locations when logged in, seeing the main super admin locations.

Reproduction

  • Login as a super admin (CiCi?)
  • Bring up the customer list and switch to any customer (bhinson)

The default location list is not correct. For bhinson it shows 2 locations that belong to super admin. bhinson has 0 locations.

Testing Update : 2024.11.14

  • Correct locations show up on MySLP menu, but NOT the SLP menu.

Dev Notes

SaaS is using a custom REST endpoint to find locations: …/myslp/v2/locations

This is running a custom interface in the MySLP Dashboard defined wp-content/plugins/myslp-dashboard/include/class.myslp.rest.api.php which fetches locations from include/location/MySLP_Location.php get_locations();

This leverages wp-content/plugins/store-locator-plus/include/module/location/SLP_Location_Utilities.php to provide the location data interface.

In MySLP_Locations the slptbl is set in __construct() which may be too early.
it is coming back as wp_store_locator which is incorrect
It appears switch_to_blog() has not yet been called.
The call stack at this point..

switch_to_blog is called in MySLP class via perform_init_actions()
which is attached to the WP hook ‘init’ with no order of precedence set

SLP not returning proper locations

The SLP Location Manager is rendered via SLP_Admin_Locations::display_manage_locations_table()
./wp-content/plugins/store-locator-plus/include/module/admin/SLP_Admin_Locations.php

It is pulling locations vis the $slplus->database property which is an instantiation of SLP_Data::
./wp-content/plugins/store-locator-plus/include/module/data/SLP_Data.php

SLP_Data::initialize is setting the SLP_Data::from_slp_table property via SLP_Data::set_database_meta()
This pulls from SLP_Data::db which is an instantiation of the WordPress wpdb class. The table is set by adding wpdb->prefix to the ‘store_locator’ fixed string.

wpdb->prefix is not pulling the proper user prefix , likely due to switch_to_blog() not being called yet.

Call Sequence

  • store-locator-plus.php is loaded…
  • slp_setup_environment() is called…
  • SLPLUS::initialize() is executed
    • $this->database = new SLP_Data()
  • SLP_Actions::initialize()
    • add_action( ‘init’, array( $this, ‘init’ ), 11 );
  • SLP_Actions::init() via WP init hook
  • MySLP::perform_init_actions()

Resolution

MySLP

The main MySLP dashboard loader (wp-content/plugins/myslp-dashboard/myslp-dashboard.php) was initializing the MySLP_Location class which immediate set the properties for SLP table and Extendo table names.

This needed to be deferred until after the MySLP::perform_init_actions() was called.

Added a new method in MySLP_Location::perform_init_actions() that sets the slp and extendo class properties. It is called from within the MySLP::perform_init_actions() to ensure proper timing on the reading of those table names.

SLP

Initialize the $slplus->data (SLP_Data) object AFTER the user login, performing the setup in the init action hook within SLP_Actions.

SaaS Development / ECS Error establishing a database connection

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: