WordPress Mixed Content Breaks Admin Assets After HTTPS

The Problem

After an HTTPS migration, a WordPress admin screen may load as plain text, lose icons, fail to open media modals, or show editor controls that do not respond. The login still works, but CSS, JavaScript, fonts, REST requests, or plugin assets are blocked because the HTTPS admin page is trying to load one or more resources over plain HTTP.

This is mixed content. Browsers treat it seriously because an insecure script, stylesheet, font, iframe, or fetch request can be observed or modified in transit. MDN explains that browsers may auto-upgrade some lower-risk resource types, but scripts, stylesheets, iframes, fetch requests, XMLHttpRequest calls, and fonts are blockable mixed content. In wp-admin, those are exactly the asset types that make the dashboard usable.

Symptoms to Confirm

• wp-admin loads without normal styling, icons, dashboard layout, editor controls, or plugin admin UI.
• The browser console shows blocked mixed-content requests for CSS, JavaScript, fonts, REST API calls, admin-ajax requests, or plugin assets.
• The issue began after enabling HTTPS, changing CDN or proxy settings, moving hosts, restoring a backup, running search-replace, or changing WordPress Address or Site Address.
• Public pages look mostly fine, but logged-in admin screens, plugin settings pages, or the block editor break.
• Only one plugin screen fails because that plugin has a saved HTTP asset URL, API base URL, font URL, iframe URL, or custom admin script.
• The error disappears when the exact blocked URL is manually changed from HTTP to HTTPS and the secure resource responds.

Why wp-admin Breaks After HTTPS

WordPress uses the configured site URLs to generate many admin and front-end links. The WordPress migration documentation notes that WordPress Address and Site Address control where WordPress is located and where the site is reached, including admin display. WordPress also has HTTPS migration helpers that update `home` and `siteurl` to HTTPS when the site can actually recognize HTTPS.

Mixed admin assets usually come from one of four places: old `home` or `siteurl` values, constants in `wp-config.php`, saved plugin or builder options, or upstream CDN/proxy configuration. A fifth source is stale cache: a CDN, optimization plugin, object cache, browser cache, or generated asset file can keep serving the old HTTP reference after the correct setting has already changed.

The fix is not simply forcing every request through HTTPS. A redirect can hide the symptom for images, but blockable admin scripts and styles may still be refused by the browser before the admin page becomes usable. The source URL needs to be corrected.

How to Diagnose It

1. Open the affected wp-admin screen in a private browser window and open developer tools before reloading.
2. Filter the console and network panel for `mixed content`, `blocked`, ``, CSS, JS, font, REST, and admin-ajax requests.
3. Copy the first blocked URL, the source file or initiator, the status code, and the exact admin screen where it happened.
4. Check Settings > General, or use WP-CLI, to confirm both WordPress Address and Site Address use HTTPS and the expected host.
5. Check `wp-config.php` for `WP_HOME`, `WP_SITEURL`, `FORCE_SSL_ADMIN`, reverse-proxy HTTPS handling, and environment-specific URL constants.
6. Review CDN, load balancer, and host SSL mode. Make sure WordPress receives the correct HTTPS signal instead of thinking requests are HTTP behind a proxy.
7. Search only the likely owner first: theme customizer settings, page builder settings, plugin settings, upload paths, generated CSS, or CDN rewrite settings.
8. Retest after each change with cache bypassed so you know which correction fixed the admin asset.

How to Fix It Safely

1. Back up the database before changing URLs or serialized plugin options.
2. Correct WordPress Address and Site Address to HTTPS if they are wrong. Do not leave temporary hard-coded values in place without documenting them.
3. If a plugin or theme option stores an HTTP asset URL, update that setting through the plugin UI when possible.
4. Use a serialization-aware search-replace tool for database content and options. Avoid raw SQL replacement on serialized data.
5. Regenerate plugin or theme CSS only after the saved source URLs are corrected.
6. Fix CDN or reverse-proxy SSL mode if WordPress receives HTTP scheme data while visitors use HTTPS.
7. Purge page cache, object cache, CDN cache, browser cache, and generated optimization assets after the source has been corrected.
8. Retest the original admin screen, the block editor, media modal, plugin settings pages, REST API index, and any login or checkout pages affected by the HTTPS change.

Common Sources to Check

• `home` and `siteurl` options still use HTTP or the wrong host.
• `WP_HOME` or `WP_SITEURL` in `wp-config.php` override the database with an old HTTP value.
• The site was cloned from staging and plugin settings still point at the staging HTTP domain.
• A page builder, optimization plugin, font plugin, map embed, analytics plugin, or custom admin plugin stores absolute HTTP asset URLs.
• Generated CSS or combined JavaScript files were not rebuilt after the HTTPS migration.
• A CDN rewrites public assets correctly but does not respect logged-in/admin exclusions.
• A reverse proxy terminates TLS but does not pass the expected HTTPS headers to WordPress.
• Browser, object, or CDN cache is serving an old admin page shell with stale asset references.

How Web Plura Diagnostics Helps

Web Plura Diagnostics is relevant because a mixed-content admin issue often crosses WordPress settings, hosting, CDN, cache, REST, and update context. The free plugin provides local Site Health-style checks, URL alignment signals, HTTPS status, hosting guidance, cache hints, front-end response checks, redirect signals, REST API response checks, Fix First prioritization, support-safe snapshots, JSON/CSV exports, scheduled local scans, multisite visibility, and WP-CLI output.

It does not rewrite your database, fix a CDN rule, or guarantee that every mixed-content URL has been found. Use it after capturing the blocked asset URL so you can add a clean local diagnostics snapshot to the support handoff. That is especially useful when the next owner may be the host, CDN provider, developer, or plugin vendor rather than the site owner.

A Practical Diagnostics Workflow

1. Install Web Plura Diagnostics from WordPress.org: download the free plugin on WordPress.org.
2. Run Diagnostics before making another URL or cache change so the baseline captures HTTPS, response, REST, hosting, and cache signals.
3. Open the Front-end Response and Hosting findings for home URL HTTPS, redirects, response code, cache-control, compression, and REST API response.
4. Use Fix First items to decide whether the next action belongs to the site admin, developer, host, CDN provider, or plugin vendor.
5. Export a support-safe snapshot, JSON export, or CSV export for the person who will update the URL source or proxy/CDN rule.
6. After the manual fix, rerun the same checks and keep the before/after notes with the HTTPS migration record.

The free plugin is local-first, does not require an external account for core diagnostics, and does not send diagnostics telemetry to Web Plura by default. Product details are available at WPlura product details and the main WPlura site is WPlura.

Prevent the Same Issue From Returning

• Document the canonical host, HTTPS policy, CDN SSL mode, and reverse-proxy HTTPS headers.
• Run HTTPS and mixed-content checks on staging before changing the production site.
• Keep a list of plugins that generate CSS, cache JavaScript, load fonts, or store absolute asset URLs.
• Use serialization-aware search-replace during migrations and keep a rollback-ready database backup.
• Exclude logged-in and wp-admin traffic from page cache and aggressive CDN optimization unless a tool is explicitly designed for admin use.
• Retest wp-admin, block editor, media modal, REST API, forms, checkout, and account pages after every HTTPS, CDN, host, or domain change.

Related WPlura Plugin Help

If wp-admin is broken by mixed content after HTTPS, finish the browser-console and URL-source checks first, then use Web Plura Diagnostics as the related WPlura support tool. Start with the free WordPress.org plugin download: download the free plugin on WordPress.org. For teams that need recurring comparison, connected reports, alerts, or portfolio oversight, use the WPlura Pro path after reviewing the free diagnostics first: WPlura Pro purchase and private download.

1. Install and activate the free Web Plura Diagnostics plugin from WordPress.org after you capture the original blocked asset URL.
2. Run the local diagnostic review to capture HTTPS, response, REST, cache, hosting, update, and plugin/theme impact context.
3. Use the support-safe snapshot, JSON export, or CSV export when a developer, host, CDN provider, or plugin vendor needs concise evidence.
4. After the source URL or CDN setting is fixed, rerun Diagnostics and keep the before/after result with the migration notes.
5. Review product details and Free versus Pro fit at WPlura product details.

References

Frequently Asked Questions