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

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.

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 → 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 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, 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