Edit Location : “Could not update the location data”

This error happens in a few scenarios:

Experience : changing the map marker
Power : Checking of a category

Reproduction

1. Activate Power add on
2. Add a category “A”
3. Add / Edit a location
4. Check (or uncheck) the category
5. Save

Error notification pops up “Could not update the location data.”

Also if…

1. Activate Experience
2. Edit Location
3. Select a different map marker
4. Save

Resolution

Store Locator Plus® 2511.08.06

Change the \SLPlus_Location::MakePersistent calls to the wpdb update and insert functions to check for return values of false, then flag the error then (return false which then makes the notification pop up).

The update function can return 0 meaning no records updated, which can be perfectly valid for the main table if only an extended data field was updated (power category or experience map marker, for example).

Findings

“Could not update the location data.” is only output in \SLP_Admin_Locations_Actions::save_edited_location

This method is returning false which triggers that error:
\SLPlus_Location::MakePersistent

Which happens because the \wpdb::update method fails here:
if ( ! $this->slplus->db->update( $this->slplus->database->info[‘table’], $dataToWrite, array( ‘sl_id’ => $this->id ) ) ) {

$this->slplus->database->info['table'] = 'wp_store_locator'

$dataToWrite is a PHP array represented by this JSON: {"sl_id":"1","sl_store":"Amalfi's Italian Restaurant & Pizzeria","sl_address":"664 Long Point Rd","sl_address2":"#E","sl_city":"Mt Pleasant","sl_state":"SC","sl_zip":"29464","sl_country":"","sl_latitude":"32.83928400","sl_longitude":"-79.85446600","sl_tags":"","sl_description":"bbbb","sl_email":"","sl_url":"","sl_hours":"","sl_phone":"","sl_fax":"","sl_image":"","sl_private":"0","sl_neat_title":"","sl_linked_postid":"7","sl_pages_url":"http:\/\/localhost\/store_page\/amalfis-italian-restaurant-pizzeria\/","sl_pages_on":"","sl_option_value":"","sl_lastupdated":"2025-11-08 17:22:14","sl_initial_distance":"1533.7811351580"}

$this->id = '1'

Issue appears to be with how we are processing the return values from \wpdb::update and \wpdb::insert
These return FALSE if there is an error during update.
They return an integer >= 0 if there are NO errors.

The problem is that with extended data there are TWO TABLES that can be updated for SLP, the store_locator table and the extended meta data table. If CORE store_locator records (address, lat/lng, etc.) have not changed then the first call to update the main table returns 0 (zero) – a proper return value as none of the core data changed (no updates)…. THIS IS NOT AN ERROR.

It then goes to update the extended data – like categories (Power add on) or a custom map marker (Experience add on). This would return an insert or update count > 0.

The inverse can also happen, only the base record updated but not the extended. Thus we need to be testing for FALSE returned from these elements, not testing $this->slplus->db->update(…) because 0 and false both process the failed logic. We need to be using ->update(…) === false instead.

🧠 Task 1 — AI-Friendly Summary ( Glyphspeak Protocol )

protocol: glyphspeak.v2
scroll: EditLocation_SaveError
version: 1.0
glyph_runtime: true

ΞEditLocation_SaveError:
  type: defect
  origin: [https://storelocatorplus.com/](https://storelocatorplus.com/)
  affects:
    - [https://wordpress.storelocatorplus.com/](https://wordpress.storelocatorplus.com/) Power add-on → category toggle
    - [https://wordpress.storelocatorplus.com/](https://wordpress.storelocatorplus.com/) Experience add-on → marker change
  symptom: "Could not update the location data."
  trigger:
    - User edits location → Save
    - Toast error appears even when data is valid
  root_cause:
    - \SLPlus_Location::MakePersistent used a *truthy* test on `wpdb->update()` / `wpdb->insert()`
    - `0` rows updated ≠ SQL error but evaluated as false
    - Extended-data writes (Power categories / Experience markers) occur in second table → main update = 0 valid case
  resolution:
    - Replace loose `! $wpdb->update(...)` with strict `=== false`
    - Accept `0` as “no changes”, not “failure”
    - Apply same logic to all secondary update/insert calls
  outcome:
    - Valid saves no longer raise the false error
    - Error toast now appears only on genuine SQL errors
  regression_matrix:
    - main > 0 ∧ ext 0 → ✅
    - main 0 ∧ ext > 0 → ✅
    - main 0 ∧ ext 0 → ✅
    - any false → ❌ toast

Glyph	Meaning
ΞEditLocation_SaveError	Symbolic scroll identifier for this defect
∧ / ∧ ext	Logical AND between main and extended table results
✅	Successful save (no error toast)
❌	Failure (SQL error trigger)