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.

Mixed-Content Warnings Remain After Moving WordPress to HTTPS

An HTTPS page becomes mixed when it requests an HTTP image, stylesheet, script, font, frame or API. Browsers block active content such as scripts more aggressively than images, so the warning can also break page features.

Use browser evidence to locate each source; an “SSL plugin” that rewrites output can hide stale URLs without correcting storage.

Inventory blocked requests

Open Console and Network on representative pages and record each HTTP URL, resource type, initiator and page.

Sources:
post/page content
theme/plugin files
inline/generated CSS
Customizer/builder settings
widgets/options
CDN/external integrations

Do not copy URLs containing private tokens or customer identifiers.

Confirm canonical HTTPS settings

Check home, siteurl and constants use HTTPS. Ensure proxy HTTPS detection is correct, otherwise WordPress can continue generating HTTP URLs.

Test wp_upload_dir()/media output and login/admin URLs. Fix the source setting before bulk replacement.

Do not create an HTTPS redirect loop while changing proxy/server rules.

Search database safely

Take a backup and run a serialisation-aware dry run:

wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --dry-run

Review table/count matches, then run the bounded replacement. Avoid altering GUIDs unless migration policy specifically requires it.

Do not replace every http:// globally; external resources may not support HTTPS and encoded/signature data may be damaged.

Inspect theme and plugin files

Search child theme/custom plugins for hard-coded HTTP URLs, protocol-specific API endpoints and inline style/script.

Use WordPress functions and https:// for known secure services. Protocol-relative URLs are less explicit and not a fix for an external host without TLS.

Do not edit parent theme/vendor files; update maintained custom code or vendor release.

Check generated CSS and builders

Builders often store absolute background/font URLs and compile CSS into uploads/cache. Update source settings, then regenerate CSS.

Clear relevant caches and ensure the generated directory is writable. Do not manually edit compiled files.

Test each language/template because translated builders may store separate values.

Inspect block and widget data

Navigation blocks, synced patterns, legacy widgets and Custom HTML blocks can retain HTTP resources separately from ordinary content.

Search their post types/options with a serialization-aware tool and review matches. Do not replace code examples or user text that intentionally contains http://. Republish the specific template/pattern and test every page reusing it.

Check email and feed output

Transactional emails, RSS/Atom feeds and sitemaps can contain old HTTP links even when browser pages are clean. Generate fresh examples after updating settings/templates.

Check SMTP/newsletter templates and cached feeds. Do not rewrite signed unsubscribe or tracking URLs without provider support.

Verify plain-text messages separately as well.

Review CDN and offload domains

The media/CDN hostname needs its own valid certificate and HTTPS origin/configuration. Update WordPress offload/CDN settings, not only page content.

Purge after switching and verify redirects do not bounce back to HTTP.

For custom fonts, check CORS as well as scheme; an HTTPS font can still be blocked by origin policy.

Handle external HTTP-only resources

Replace with an official HTTPS endpoint, host a licensed/local copy where permitted, proxy through a secure maintained service, or remove the dependency.

Do not disable browser mixed-content protection or add insecure CSP exceptions. Never proxy sensitive third-party APIs without understanding authentication and data handling.

Document any removed feature.

Verify all page types

Crawl representative posts, templates, CSS, feeds, emails and admin/editor assets. Test Console on desktop/mobile and after cache warm-up.

Use Content Security Policy report-only/upgrade-insecure-requests as an additional control only after source repair, not a substitute. Recurring care should scan for new HTTP resources after content/plugin changes; HTTPS migration is complete when requests are secure at their source.