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 Admin Shows a Blank Page While the Website Still Works

The public theme and administrator execute different hooks, assets and permissions. A plugin can fail only in wp-admin, or one user profile can load a broken dashboard widget while anonymous pages remain cached and healthy.

Inspect the administrator response before changing the active theme or public site.

Check response status and body

Open Network tools for /wp-admin/ and record status, response length, redirects and content type.

Patterns:
500/empty -> PHP/server error
200/empty -> suppressed fatal or early exit
200/HTML -> CSS/JavaScript/overlay
403 -> security/capability/firewall
3xx -> authentication/domain

View source to distinguish blank HTML from hidden markup.

Read administrator-specific logs

Match the request timestamp with PHP and WordPress logs. Capture the first fatal and component path.

Enable protected WP_DEBUG_LOG with display off only if necessary. Do not expose errors in the browser.

Check whether the fatal occurs in admin_init, dashboard widgets, admin menu construction or a plugin update notice.

Compare admin routes

Try profile.php, edit.php, plugins.php and a direct plugin page. If one route works, the dashboard or particular screen hook is implicated.

Test a second authorised administrator. A user-specific failure can come from screen options, dashboard widgets, locale or corrupted metadata.

Do not create/share administrator accounts without normal identity and audit controls.

Check memory and execution time

Administrator screens often load more plugin code and data than public pages. Capture memory/timeout fatals and identify the consumer before raising limits.

Unbounded order/post counts or remote licence checks can stall one screen. Measure query/API time in staging.

Keep public PHP workers in mind; increasing admin timeouts can occupy the same pool.

Isolate admin plugins safely

Use WP-CLI to deactivate the named plugin or rename only its directory. Must-use plugins and drop-ins require separate inspection.

wp plugin deactivate example-plugin

Run as the correct site user/root. Preserve files/data and do not invoke uninstall.

Use a troubleshooting mode for session-only isolation where WordPress can still load enough administrator UI.

Inspect administrator assets

If HTML exists, read Console/Network for missing CSS/JS, CSP blocks and script exceptions. Optimisation plugins should generally avoid combining/delaying admin assets.

An overlay from an onboarding modal can cover the screen. Inspect computed styles and DOM before deleting settings.

Clear browser/admin asset cache after correction; do not purge unrelated customer sessions.

Repair user-specific state

Dashboard widget state and screen options live in user metadata. Compare the affected account with a working administrator via WordPress APIs.

Do not delete all user metadata. Remove or correct only the proven key after backup and let WordPress rebuild defaults.

Check locale-specific plugin translation errors if one user language fails.

Inspect custom admin menus and columns

Plugins can build dashboard menus, notices and list-table columns only for users with certain capabilities. A callback may query every post/order or call a remote service before rendering.

Disable the implicated admin module in staging and measure the specific screen. Batch-load required metadata and cache only non-personal reference data. Do not remove capability checks to make the page render; fix the callback for the expected role/context.

Check output and compression corruption

Whitespace, debug output or a broken compression handler can terminate/blank administrator HTML. Compare raw response and Content-Encoding with a direct origin request.

Inspect auto_prepend_file, PHP output buffering and optimisation/security plugins. Remove temporary echo/var_dump() from site-owned code. Do not disable TLS or compression globally without proving that layer caused the response.

Verify administrative work

Test dashboard, editor/save, plugin/theme pages, media, cron and logout/login. Check logs for new errors and confirm public pages remain unchanged.

Recurring care should monitor administrator PHP fatals and critical screen response time. The repair is complete when staff can perform their real tasks, not merely when /wp-admin/ displays a header.