Do you ask for passwords in the form?

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

WordPress Cannot Save Posts, Settings or Plugin Options

A save button can fail before the request leaves the browser, at a security/proxy layer, inside PHP validation or during a MySQL write. The interface may also report success while persistent object cache serves an older value.

Preserve one controlled change and follow it through the request. Do not repeatedly edit live content while the final database state is uncertain.

Define which writes fail

Test a draft post, a harmless core setting and the affected plugin option. Record URL, user role, time, browser message and HTTP response.

Compare:
block editor REST request
classic/admin POST
admin-ajax request
media metadata write
scheduled/background write

Use a controlled draft and avoid exposing unpublished content in logs.

Inspect the browser request

Open Network tools and submit once. A request that never leaves may indicate JavaScript or client validation. A 403 points toward nonce, permission or firewall; 500 toward PHP; a JSON error can name validation or database failure.

Read the response body without publishing nonces, cookies or form values. Start with the first Console error.

Do not disable browser security or all plugins just to make the button appear active.

Check WordPress permissions and nonces

Confirm the user has the capability needed for the post type or settings page. Role editors and membership plugins can change capabilities.

Login cookies and nonces expire; sign in again in a clean session. If the problem returns immediately, inspect canonical domain, HTTPS and cache rather than extending nonce lifetimes.

Never bypass current_user_can() or nonce verification in production code.

Correlate PHP and MySQL logs

Match the request timestamp with WordPress/PHP and MySQL errors. Look for table full, disk full, deadlock, read-only mode, missing column or fatal inside a save hook.

Custom validation may deliberately reject the value. A helpful application error is different from a database failure.

Protect logs because option values can contain API keys or personal data.

Check read-only and locking states

Managed databases can enter read-only mode during failover, replica promotion or storage protection. Confirm WordPress connects to the writable primary, not a read replica.

Inspect InnoDB lock waits and deadlocks around the save. A request may be rolled back even though the connection remains healthy. Identify the competing import, backup or plugin transaction before retrying, and keep custom save hooks short so they do not hold locks while calling remote APIs.

Verify database writes directly

After backup, read the specific post/option through WordPress APIs or a precise read-only query. Do not assume the screen value is authoritative.

$value = get_option( 'example_option', null );
error_log( 'Option type: ' . gettype( $value ) );

Log type/presence, not the secret value. Remove temporary diagnostics afterward.

Check object and page cache

Persistent object cache can return stale options after a successful write, especially when sites share an incorrect cache prefix. Flush only the relevant cache through supported controls after preserving evidence.

Test a direct database read versus WordPress API in staging. Confirm all web nodes use compatible Redis/Memcached configuration.

Administrator and REST responses must not be publicly page-cached.

Review save hooks and schema

Plugins can intercept save_post, REST callbacks or option sanitisation. A callback may recurse, throw a fatal or return the previous value.

Search site-owned code and the PHP stack. Under HPOS/custom tables, verify the extension’s schema migrations completed.

Do not edit core or vendor files; correct maintained custom code or update the component.

Repair and verify persistence

Correct the permission, nonce/domain, firewall, PHP, MySQL, cache or callback issue demonstrated by evidence. Save a controlled value, reload in a new request and confirm the database contains it.

Test revision/autosave, scheduled tasks and another user role. Recurring care should alert on database write errors and REST 4xx/5xx; a repair is complete when changes persist across cache, process and login boundaries.