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.

A WordPress Plugin Update Breaks the Entire Site

An update can introduce incompatible PHP, depend on a newer component, fail midway or activate a database migration. The timing identifies the first suspect, but the PHP fatal and installed files show what actually broke.

Preserve the update version and error before disabling several plugins. A focused rollback is safer than restoring the whole website and losing new content.

Record the update and symptom

Note plugin name, old/new versions, update time, operator/method and whether public, administrator, cron or only one feature fails.

Check hosting/PHP logs for the first fatal at the same time:

Preserve:
fatal message and call path
PHP/WordPress versions
plugin package/version
HTTP status
last successful request

Redact paths, secrets and customer data.

Create a rollback point

Back up current files and database even though the site is broken. This preserves post-update migrations and content created since the previous backup.

Locate a trusted previous plugin package or backup and confirm its checksum/source. Do not download “older versions” from unofficial mirrors.

If disk/inodes caused partial extraction, free safe headroom before another package operation.

Deactivate without administrator access

Rename only the implicated directory inside wp-content/plugins through cPanel, Plesk, SFTP or SSH. WordPress will treat that plugin as unavailable.

example-plugin
example-plugin.disabled

Record the exact path and preserve the files. Do not rename the whole plugins directory unless logs provide no suspect and you have a controlled reactivation plan.

Must-use plugins load elsewhere and require separate inspection.

Check for incomplete files

Compare file count/checksums with the official package. A network, permission, disk or inode failure can leave mixed old/new files.

Reinstall the complete trusted new version in staging. Do not copy individual PHP files from another installation whose edition or licence differs.

Clear OPcache after file replacement so PHP does not execute stale bytecode.

Assess database migrations

Some updates alter tables/options on first load. Read release notes and plugin logs. Rolling files back after a non-reversible schema migration can create a second incompatibility.

Take a database backup before running repair/migration tools. Do not restore the entire database merely to reverse code when new posts, users or orders may exist.

Ask the vendor for documented downgrade compatibility when uncertain.

Reproduce in staging

Build a copy with the same PHP, WordPress, theme and relevant plugins. Test previous and updated versions against the failing feature.

Check dependency plugins and load order. An undefined function may indicate a required add-on remained old rather than a defect in the updated plugin.

Keep staging email, indexing and live external actions disabled.

Check dependency and edition mismatch

Premium add-ons often depend on a minimum free/base-plugin version, while licence expiry can prevent the companion update. Confirm both packages come from the same supported release family.

Also check whether a bundled theme copy overrides plugin templates or APIs. Update the dependency set together in staging, then test the exact integration. Do not activate two editions simultaneously if they declare the same classes or functions.

Choose rollback or forward fix

For an active outage, restore the last known compatible plugin files if the database remains compatible. Document security exposure and a deadline for the forward update.

Otherwise update the dependency, correct site-owned integration code or move to a supported PHP version based on evidence.

Never edit vendor plugin files as the permanent correction; the next update overwrites them.

Verify the whole application

Test public pages, login, editor, cron and every feature owned by the plugin. Check logs for new fatals and confirm caches regenerate.

Monitor after traffic returns. Recurring care should stage plugin updates, retain trusted rollback packages and run feature-specific acceptance checks; a homepage that loads does not prove the plugin’s business function survived.