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.

Rolling Back a WordPress Update Without Losing New Content

Code and content have different rollback needs. Restoring yesterday’s whole database to undo today’s plugin files can delete posts, users, settings and submissions created since the backup. The safest rollback replaces only the implicated code unless its database migration also requires recovery.

Freeze unnecessary changes and document the incident window before choosing the rollback boundary.

Identify what the update changed

Record component, old/new versions, update time, PHP/WordPress version and any database migration message.

Classify:
files only
files plus options/schema
generated assets/cache
external integration state
user-created data since update

Read changelog/vendor downgrade guidance and logs. Do not assume a version number tells the whole migration state.

Preserve current data

Take a fresh files/database backup of the broken current state and retain the pre-update backup. Export critical new content separately where practical.

Record posts/users/submissions/orders created during the incident window. A rollback plan must explicitly preserve them.

Do not start another update or cleanup during evidence collection.

Roll back files narrowly

For a plugin/theme, replace only its directory with the trusted previous package after staging verification. Avoid merging old/new files.

For core, reinstall a supported intended version while preserving wp-content, uploads and wp-config.php.

component -> component.failed
trusted-previous -> component

Preserve ownership and clear OPcache. Never source packages from unofficial mirrors.

Assess database compatibility

If the update changed schema/options, old code may not understand the new database. Ask the vendor whether downgrade is supported.

Do not manually decrement a stored database version to force migrations. That can rerun destructive or duplicate operations.

When a database rollback is necessary, plan a merge/replay of new content through application-aware exports/APIs rather than raw row copying.

Protect background and external work

Pause cron, queues and integrations that may run incompatible callbacks during the rollback. Check whether the updated component already sent email, changed remote records or created scheduled tasks.

External effects cannot be undone by restoring WordPress. Reconcile them with stable references.

Resume queues only after the restored code can process their stored arguments.

Test on a production-like copy

Restore the current database to staging, apply the proposed file rollback and exercise the failing path plus saves/cron.

Disable outgoing email, indexing and live APIs. Confirm no automatic downgrade migration deletes current data.

Use representative recent content to prove it survives.

Plan a content merge when a database restore is unavoidable

Define the restore timestamp and enumerate every newer post, user, comment, form entry and operational record. Use the owning application’s export/import or API so relationships and sanitisation are preserved.

Do not copy rows by numeric ID without checking collisions, metadata and references. Rehearse on staging and freeze/queue new writes during the final restore/merge window.

Handle media created after the backup

New attachment records and filesystem uploads must stay paired. Inventory post IDs, _wp_attached_file paths and originals.

Copy files with checksums while preserving paths, then merge records through WordPress-aware tools. Do not regenerate metadata before originals exist. Verify private uploads remain protected.

Apply and verify

Take a last backup, perform the narrow rollback, clear relevant caches and test public/admin, editor, media, scheduled tasks and component features.

Compare content counts and newest timestamps with the pre-rollback inventory. Inspect logs for compatibility errors.

Monitor traffic before declaring recovery.

Prepare the forward fix

Document why the update failed, the temporary version/security risk and the tested remediation. Patch site-owned code, update dependencies or choose a supported PHP release in staging.

Recurring care should keep code packages/version control separate from database backups and rehearse downgrade compatibility. A professional rollback restores service without treating new business data as disposable.