# Settings Tab Won’t Save (WooCommerce / Schema / AI)

> SEObolt settings tab shows a green success notice but changes do not persist: three Settings API misregistrations across 2.4.127-129, all fixed in 2.4.129+.

- Canonical: <https://royalplugins.com/support/seobolt/settings-tab-wont-save/>
- HTML version: <https://royalplugins.com/support/seobolt/settings-tab-wont-save/>

---

You click **Save Changes** on a SEObolt settings tab, the page reloads with a green “Settings saved” success notice — but your field values are gone, the toggle is still off, or your changes silently reverted. Three consecutive Settings API misregistration bugs hit different tabs across SEObolt Pro 2.4.127, 2.4.128, and 2.4.129. All three are fixed by 2.4.129+. Here’s how to confirm + the diagnostic if you’re still hitting it on the current version.

### If you’re on SEObolt Pro 2.4.129 or later, this is fixed

Update SEObolt Pro to 2.4.129+ first. All three known “tab silently drops on save” bugs (WooCommerce, Schema, AI) ship a fix as of 2.4.129. If you’re still hitting it on 2.4.129+ that’s a different bug — run the diagnostic below and contact priority support.

## Which Tab + Version

Three different tabs, three different root causes, three different SEObolt versions where each was fixed:

| Affected tab | Visible symptom | Root cause | Fixed in |
| --- | --- | --- | --- |
| **Settings → AI** | No “Save Changes” button at all on the page; nothing persists because there’s no submit affordance | Tab was incorrectly marked AJAX-managed in the dispatcher, suppressing the outer `<form>` wrapper | **2.4.127** |
| **Settings → WooCommerce** | All 11 fields (product schema toggles, default brand, identifier type, slug remover, title patterns, noindex options) silently drop on save. Success notice still shows. | The `seobolt_woocommerce` option was never registered with the WP Settings API. options.php only persists whitelisted options, so unregistered field posts went into the void. | **2.4.128** |
| **Tools → Schema Builder → Default Schema Types per Post Type** | Schema defaults silently drop on save. Success notice still shows. | Form posted to options.php with the correct whitelist, but the sanitize callback dispatched on a hidden `_wp_http_referer_tab` field that the form didn’t set — so the sanitizer’s schema case never fired. | **2.4.129** |

Why three consecutive misregistrations

SEObolt Pro’s settings UI is split into many tabs that all submit to the same `options.php` endpoint with a shared `seobolt_settings_group` whitelist + a tab-dispatching sanitize callback. The dispatcher reads a hidden `_wp_http_referer_tab` field to know which tab’s case to run. Bugs (a) missing `register_setting()`, (b) missing or wrong `_wp_http_referer_tab`, (c) AI dispatcher mis-classification all surface the same way: options.php returns the “Settings saved” notice (because the form posted), but no field actually persists (because the whitelist or sanitizer rejected everything).

## The Fix

### Update to SEObolt Pro 2.4.129+ (covers all three)

#### Check your current version

WP Admin → **Plugins → Installed Plugins**. Find SEObolt Pro and note the version. If it’s lower than **2.4.129**, you’re hitting one of the three known bugs.

#### Update SEObolt Pro

Click the **Update** link inline. If WordPress doesn’t show an update available, click **Dashboard → Updates → Check Again**.

#### Re-save the affected tab

Go back to the tab where Save wasn’t persisting. Re-enter your values and click **Save Changes**. Now reload the page after the success notice — your values should still be there.

## Diagnostic if You’re on 2.4.129+ and Still Hitting It

If you’re on the fixed version and a save still doesn’t persist, the cause is somewhere else. Two probes that take 30 seconds each:

### Probe 1: Check the option in the database

Read the actual stored value directly via WP-CLI (or phpMyAdmin if you don’t have shell access). Run this immediately AFTER clicking Save Changes:

```
# WooCommerce tab
wp option get seobolt_woocommerce --format=json

# Schema defaults
wp option get seobolt_schema --format=json

# AI settings
wp option get seobolt_ai --format=json
```

If the option contains your saved values — the save worked but the UI is reading from cache. Try a hard refresh (Ctrl+Shift+R), clear any object caching plugin’s cache, and reload.

If the option is missing your saved values OR doesn’t exist at all — options.php genuinely rejected the post. Move to Probe 2.

### Probe 2: Watch the save in DevTools

Open the affected tab. Open browser DevTools → Network tab (filter to `Doc` or `options.php`). Click **Save Changes**. Inspect the POST request to `/wp-admin/options.php`:

- **Form Data** should contain your field values + a hidden `option_page` equal to `seobolt_settings_group`
- The response should be a **302 redirect** back to the settings page with `?settings-updated=true` in the URL
- The redirected page should show the **Settings saved** green notice

If any of these are different (404 instead of 302, missing `option_page` field, missing field values in form data), email priority support with the request payload — that points us at a different bug than the 2.4.127-129 trio.

Object-cache gotcha

If you use Redis / Memcached / a managed-host object cache, the option might be saved correctly in the DB but the UI reads a stale cached value. Try `wp cache flush` after the save (or use your host’s “clear object cache” button) and reload the page. If THAT fixes it, the save was working all along.

## Why It’s Three Consecutive Releases

This class of bug is silent — the user sees “Settings saved” and the form reloads without errors, but the values aren’t persisted. None of the three bugs raised a PHP warning, none of them surfaced in the standard QA path (where the tester checks “does Save click without errors”), and the Settings API doesn’t emit any warning when an unregistered option posts to options.php.

The cluster of three consecutive bugs across 2.4.127-2.4.129 prompted us to add an explicit test that simulates a settings POST + verifies the option was actually persisted, run on every PR via PHPUnit (added 2.4.132). That regression guard catches future versions of the same class of bug at CI time instead of waiting for a customer report.

If you reported one of these and never heard back — sorry, we shipped the fix in the same release cycle but didn’t individually email everyone affected. This doc exists in part so future customers searching for “settings not saving SEObolt” land on a self-serve fix instead of needing to file a ticket.

## Still Not Saving on 2.4.129+? Email Priority Support

Email **[support@royalplugins.com](mailto:support@royalplugins.com)** with the diagnostic info below. Priority email support is included with your SEObolt Pro license — typical response within 24 hours.

#### Information we’ll need

- **SEObolt Pro version** + **WordPress version**
- **Which tab** isn’t saving (be specific: Settings → WooCommerce, Tools → Schema Builder, Settings → AI, etc.)
- **Probe 1 result**: output of `wp option get seobolt_ --format=json` immediately after a Save click
- **Probe 2 result**: from DevTools Network tab, the POST request payload + the response status code
- **Object-cache info**: are you running Redis / Memcached / managed-host object cache? Did clearing it help?
- **Active plugins**: `wp plugin list --status=active --format=csv` — some security plugins filter options.php submissions

[Back to SEObolt Support](https://royalplugins.com/support/seobolt/)
[AI Generation Fails](https://royalplugins.com/support/seobolt/ai-generation-failed-model-not-recognized/)