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.