Enabling Reports Produces Fatal Error

User Report (texas)

I have always had the reporting functionality turned on. I noticed it no longer is on and when enabled it displays this code:

Fatal error: Uncaught Error: Class \"SLP_Power\" not found in /var/www/html/wp-content/plugins/slp-power/include/module/admin/SLP_Power_Admin_Reports2022.php on line 37 
Error: Class \"SLP_Power\" not found in /var/www/html/wp-content/plugins/slp-power/include/module/admin/SLP_Power_Admin_Reports2022.php on line 37 

Dev Notes

A basic typo in the reports module was performing an include in the wrong place.

Resolved in Power 2502.25.02.

Ignore Radius Breaks Search Button

Search Button Not Working (User: Teivin)

From their website, search button does not fire.

Analysis

If Settings | Search | Radius Behavior is set to “Do not use” it will trigger the problem.

The backend code in the Experience codebase has a bug that is not using a properly initialized AJAX class. This is a side effect of the PHP upgrade.

It is resolved in the 2502.25.01 release of Experience.

MySQL 8 Rank Field Conflict

Part of the Pins Not Showing Up for uws_at issue.

Rank Field Conflict With MySQL 8

While changed settings is an issue and still needs to be investigated, the main culprit here is the upgrade from MySQL 5 to MySQL 8. Servers were upgraded to MySQL 8 as the prior release we no longer supported. Amazon RDS services dropped support for the older MySQL version with a hard cut off in the fall of 2024. As such we were forced to upgrade MySQL; A good thing overall but it involved a lot of data query and code updates and testing.

MySQL added the work “rank” as a reserved word. This conflicts with our Professional an Enterprise feature that has used rank as a standard field name for a decade. Turns out we missed on location where we need to specially mark this field in the data query.

Any sites that have, or had, a location with the rank field set may experience an issue with initial location results not appearing.

Resolved in the 2502.24.01 update to the Experience module.
Testing underway 25/02/24 13:00 EST.
On production as of 25/02/24 14:45 EST.

Pins Not Showing Up for uws_at

This report involves two primary issues. The bigger issue is in the MySQL 8 conflict and is being resolved. We are still investigation the Settings Reset issue.

Settings Reset To Default

Some user settings (noted below) are not the same as they were originally on the production server after the 2502 update. This is still being investigated.

See https://internal.storelocatorplus.com/settings-reset-to-default/

Rank Field Conflict With MySQL 8

MySQL added the work “rank” as a reserved word. This conflicts with our Professional an Enterprise feature that has used rank as a standard field name for a decade. Turns out we missed on location where we need to specially mark this field in the data query.

See https://internal.storelocatorplus.com/mysql-8-rank-field-conflict/

User Report

The map is not working, and the pins are not showing up. Please let me know what happened. Thanks! We need to fix this ASAP.


Account: uws_at_*_dot_com
Account Level: Professional
Status: active
Expires: 2025-02-26 04:39:09

Versions:
SLP: 2502.21.01
myslp-dashboard-options: 2502.24.01
slp-premier-options: N/A
slp-power: 2502.18.01
slp-experience: 2502.20.01

Add Location With Lat/Lng Does Not Save

Fixed in SLP 2502.19.01

Reproduction

Got to Location Details | Add
Name: Test
Latitude: 32.8393273773774
Longitude: -79.85448363551637

Code Tracing

In \SLPlus_Location::MakePersistent

$dataTooWrite = 
array (
  'sl_store' => 'Test',
  'sl_address' => '',
  'sl_address2' => '',
  'sl_city' => '',
  'sl_state' => '',
  'sl_zip' => '',
  'sl_country' => '',
  'sl_latitude' => '32.8393273773774',
  'sl_longitude' => '-79.85448363551637',
  'sl_tags' => '',
  'sl_description' => '',
  'sl_email' => '',
  'sl_url' => '',
  'sl_hours' => '',
  'sl_phone' => '',
  'sl_fax' => '',
  'sl_image' => '',
  'sl_private' => '',
  'sl_neat_title' => '',
  'sl_linked_postid' => 0,
  'sl_pages_url' => '',
  'sl_pages_on' => '',
  'sl_option_value' => '',
  'sl_initial_distance' => 943.4293089967016,
)

Error Logs

Database insert error:

WordPress database error: Processing the values for the following fields failed: sl_latitude, sl_longitude. The supplied values may be too long or contain invalid data.

Resolution

The problem is that Google is falsely creating GPS coordinates on the Google Maps interface likely in an effort to thwart data harvesting.

The latitude/longitude combination 32.8393273773774, -79.85448363551637 represents 14 places after the decimal.

9 places after the decimal represents a length on the earth’s surface of approximately 110 microns.

Anything after the sixth decimal place, about 11cm is fairly useless for general map locations.

In Store Locator Plus 2502.19.01 the \SLP_Admin_Locations_Actions::add_location() method was updated to format incoming latitude and longitude data to present no more than 9 places after the decimal. This is necessary to fit the data into a 14 character data field which is stored as a string.

This can include values with negative representation including “-180.123456789”.

REST Route Missing Permissions Callback SLP_REST_HANDLER

[03-Feb-2025 22:35:07 UTC] PHP Notice:  Function register_rest_route was called incorrectly. 

The REST API route definition for myslp/v2/locations/(?P\d+) is missing the required permission_callback argument. 

For REST API routes that are intended to be public, use __return_true as the permission callback. Please see <a>Debugging in WordPress</a> for more information. (This message was added in version 5.5.0.) in /var/www/html/wp-includes/functions.php on line 6031

Resolved in 2502.05.01

Add permission call back to check for manage_slp role on REST endpoint for location management.

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.

MySLP/v2/locations REST Route Registration Incorrect

Resolved in MySLP Dashboard 2502.05.01

[14-Nov-2024 19:52:23 UTC] PHP Notice:  Function register_rest_route was called incorrectly. 

The REST API route definition for myslp/v2/locations/(?P\d+) is missing the required permission_callback argument.

For REST API routes that are intended to be public, use __return_true as the permission callback.

MySLP_REST_API->register_routes(class WP_REST_Server { protected $namespaces = ['oembed/1.0' => [...], 'myslp/v2' => [...]]; protected $endpoints = ['/' => [...], '/batch/v1' => [...], '/oembed/1.0' => [...], '/oembed/1.0/embed' => [...], '/oembed/1.0/proxy' => [...], '/myslp/v2' => [...], '/myslp/v2/locations' => [...], '/myslp/v2/locations-limit' => [...]]; protected $route_options = []; protected $embed_cache = [] })
/var/www/html/wp-includes/class-wp-hook.php:324

register_rest_route($route_namespace = 'myslp/v2', $route = '/locations/(?P<id>\\d+)', $args = [0 => ['methods' => 'GET', 'callback' => [...], 'permission_callback' => class Closure { ... }], 1 => ['methods' => 'POST, PUT, PATCH', 'callback' => [...]], 2 => ['methods' => 'DELETE', 'callback' => [...], 'args' => [...]]], $override = *uninitialized*)
/var/www/html/wp-content/mu-plugins/myslp-dashboard/include/class.myslp.rest.api.php:110