SLP Updates 2502.23.XX – 2502.24.XX

Updates

The following issues have been updated starting with the 2502.23 release.

  • Fatal error: Uncaught Error: Undefined constant “MYSLP_DEPLOYMENT_LEVEL”
    • resolved: MySLP Dashboard 2502.23.01
      • Deployed to production 25/02/23 15:20 EST
  • Uploaded files : csv imports, custom map marker images stability
    • resolved: AWS system configuration update on shared EFS mount for uploads folder
      • Deployed to production 25/02/23 18:20 EST
  • Expired Account Notification for Active Users
    • Resolved: MySLP dashboard update on check_activation in the REST_API
      • Deployed to production 25/02/24 01:00 EST
  • MySQL 8 Rank Field Conflict
    • Resolved: Experience update on \SLP_Experience_AJAX::create_string_CustomSQLOrder() to address rank reserved work in MySQL 8.
    • Deployed to production 25/02/24 04:00 EST
  • My Profile Updates
    • Fix Stripe “Test Mode” warning on View Profile
    • Show UID/Site ID on top of customer profile section
    • Remove avatar/image sidebar and move edit profile to the top right of main bar
    • Reformat some headers on the page
    • Deployed to production 25/02/25 12:15 EST
  • Main Theme
    • Show the site tagline on bottom right corner of image
    • Will be used to manually update the version so users can easily see there is an update
    • Deployed to production 25/02/25 12:15 EST
  • Contact Us
    • Show a preview of the extra meta that will be sent to support
    • Add UID/Site ID next to the user name
    • Deployed to production 25/02/25 12:15 EST

SLP set_database_meta on null

Fatal error: Uncaught Error: Call to a member function set_database_meta() on null in /var/www/html/wp-content/plugins/store-locator-plus/include/module/admin/SLP_Admin_Activation.php:450

New local docker WP install activating SLP on clean database.

Resolution

This bug was resolved already.

\SLP_Data::initialize() no longer calls $this->set_database_meta(); on a fresh database installation.

AI Analysis

From gpt-5.3-codex (high) with a RAG hook via a proxy interface on the Spark…

Script 2025-06-18 15:04:06 -0400 345) 
b77cbd0e3 include/module/admin/SLP_Admin_Activation.php (SaaS Update Script 2025-06-18 15:04:06 -0400 346) 		if ( ! defined( 'MYSLP_VERSION' ) ) {
b77cbd0e3 include/module/admin/SLP_Admin_Activation.php (SaaS Update Script 2025-06-18 15:04:06 -0400 347) 			$this->check_for_addon_updates();
b77cbd0e3 include/module/admin/SLP_Admin_Activation.php (SaaS Update Script 2025-06-18 15:04:06 -0400 348) 		}
727b4970a include/SLP_Activation.php                    (Lance Cleveland    2017-12-28 11:20:55 -0500 349) 	}
727b4970a include/SLP_Activation.php                    (Lance Cleveland    2017-12-28 11:20:55 -0500 350) 

diff --git a/include/module/admin/SLP_Admin_Activation.php b/include/module/admin/SLP_Admin_Activation.php
index f9bd70e9..132cfb50 100644
--- a/include/module/admin/SLP_Admin_Activation.php
+++ b/include/module/admin/SLP_Admin_Activation.php
@@ -10,7 +10,7 @@ class SLP_Admin_Activation extends SLPlus_BaseClass_Object {
 	/**
 	 * Add roles and cap.
 	 */
-	private function add_slplus_roles_and_caps() {
+	private function add_slplus_roles_and_caps(): void {
 		$role = get_role( 'administrator' );
 		if ( is_object( $role ) && ! $role->has_cap( 'manage_slp_admin' ) ) {
 			$role->add_cap( 'manage_slp' );
@@ -24,7 +24,7 @@ class SLP_Admin_Activation extends SLPlus_BaseClass_Object {
 	 *
 	 * @return bool
 	 */
-	public function being_deactivated() {
+	public function being_deactivated(): bool {
 		if ( empty( $_REQUEST ) ) {
 			return false;
 		}
@@ -48,7 +48,7 @@ class SLP_Admin_Activation extends SLPlus_BaseClass_Object {
 	/**
 	 * Check if there are any add on updates.  Inactive plugins too.
 	 */
-	private function check_for_addon_updates() {
+	private function check_for_addon_updates(): void {
 		$plugins = get_plugins();  // contains all plugins active or not key = slug (store-locator-le/store-locator-le.php)
 
 		// Check all plugins

Cause is very likely a hook-order race on fresh installs.
1.
SLP_Admin_Activation::update() is invoked on plugins_loaded via [SLPlus.php:349](/Users/lancecleveland/phpStorm Projects/WordPress/wp-content/plugins/store-locator-plus/include/SLPlus.php:349) and [SLPlus.php:359](/Users/lancecleveland/phpStorm Projects/WordPress/wp-content/plugins/store-locator-plus/include/SLPlus.php:359).
2.
slplus->database is only created later on WP init in [SLP_Actions.php:103](/Users/lancecleveland/phpStorm Projects/WordPress/wp-content/plugins/store-locator-plus/include/module/actions/SLP_Actions.php:103) and [SLP_Actions.php:106](/Users/lancecleveland/phpStorm Projects/WordPress/wp-content/plugins/store-locator-plus/include/module/actions/SLP_Actions.php:106).
3.
In the failing build, activation line ~450 calls $this->slplus->database->set_database_meta() during fresh install, so database is still null and fatals.
4.
This exact issue was already fixed upstream in commit 21478780 (Jan 7, 2025) by removing that activation-time call.
Suggested patches (no code changed yet):
1.
Recommended backport: remove the fresh-install call to $this->slplus->database->set_database_meta() from SLP_Admin_Activation::update() (the exact 21478780 fix).
2.
Defensive hardening: if you keep any similar call, guard with isset($this->slplus->database) and is_object(...) before method invocation.
3.
Lifecycle hardening (optional): run version/activation update on init (after DB object creation) instead of plugins_loaded, or split update logic so anything touching slplus->database runs only after init.
Note: your local checkout at WordPress/wp-content/plugins/store-locator-plus already appears to have this fix; the reported crash likely comes from an older packaged artifact (stale Docker/plugin build) missing commit 21478780.