Mixed content-waarschuwingen in WordPress oplossen

Mixed content-waarschuwingen zijn een van de meest voorkomende problemen waar WordPress-site-eigenaren tegenaan lopen na het overschakelen van HTTP naar HTTPS. Ze treden op wanneer uw site over een beveiligde HTTPS-verbinding wordt geladen, maar sommige bronnen op de pagina (afbeeldingen, scripts, stylesheets, iframes) nog steeds worden opgevraagd via gewone HTTP. Browsers behandelen dit als een beveiligingsrisico, en terecht. Het goede nieuws is dat mixed content eenvoudig op te lossen is zodra u begrijpt waar het vandaan komt.

Hoe mixed content-waarschuwingen eruitzien in uw browser

Wanneer een pagina mixed content bevat, reageren browsers op verschillende manieren, afhankelijk van het type bron. Voor "actieve" mixed content (scripts, iframes, stylesheets) blokkeren de meeste browsers de bron volledig en tonen ze een waarschuwing in de developer console. Voor "passieve" mixed content (afbeeldingen, audio, video) kan de bron nog steeds laden, maar het hangslotpictogram in de adresbalk verdwijnt of toont een waarschuwingsdriehoek.

In Chrome ziet u berichten als "Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource" in de console. Firefox toont een grijs hangslot met een waarschuwingsdriehoek. Safari kan sommige bronnen stilletjes blokkeren zonder duidelijke visuele feedback, wat het debuggen lastiger maakt.

Het praktische resultaat is dat uw site er kapot uitziet voor bezoekers. Afbeeldingen laden mogelijk niet, stijlen kunnen ontbreken en scripts kunnen falen. Erger nog, Google beschouwt HTTPS als een rankingsignaal, dus mixed content-problemen kunnen indirect uw SEO schaden.

Hoe u elke mixed content-bron op uw site vindt

Voordat u iets kunt repareren, hebt u een volledige lijst nodig van HTTP-bronnen die worden geladen. Er zijn verschillende betrouwbare manieren om dit te doen:

• InspectWP-scan: Voer een scan uit op uw site. De HTML-sectie somt elke onveilige URL op die op de pagina is gevonden, waardoor u een duidelijke inventaris hebt van wat moet worden opgelost.
• Browser DevTools console: Open de developer tools van uw browser (F12 of Cmd+Shift+I op Mac), ga naar het tabblad Console en herlaad de pagina. Elke mixed content-waarschuwing verschijnt hier met de exacte URL van de overtredende bron.
• Why No Padlock-tool: Bezoek whynopadlock.com en voer uw URL in. Het scant de pagina en rapporteert alle onveilige bronnen in een eenvoudige lijst.
• SSL Labs-test: Hoewel primair bedoeld voor het controleren van uw SSL-certificaat, kan de Qualys SSL Labs-test ook mixed content-problemen markeren.

Voor sites met veel pagina's wilt u mogelijk meer dan alleen de homepage controleren. Test belangrijke landingspagina's, blogberichten (vooral oudere) en pagina's met ingesloten media of content van derden.

Veelvoorkomende oorzaken van mixed content in WordPress

Mixed content komt zelden uit één bron. Dit zijn de meest voorkomende boosdoeners:

• Hardgecodeerde HTTP-URL's in berichtinhoud: Als u berichten en pagina's hebt aangemaakt voordat u overschakelde naar HTTPS, gebruiken alle afbeelding-URL's, links en ingesloten media in de contenteditor nog steeds http://. WordPress slaat deze op als absolute URL's in de database.
• Themabestanden met hardgecodeerde URL's: Sommige thema's hardcoderen afbeeldingspaden of externe bron-URL's met http:// in plaats van protocolrelatieve URL's of WordPress-functies te gebruiken.
• Plugin-assets: Oudere of slecht onderhouden plugins kunnen hun CSS- en JavaScript-bestanden laden via HTTP-URL's.
• Externe embeds en iframes: Google Maps-embeds, YouTube-video's (oudere embedcodes), social media-widgets en advertentiescripts gebruiken soms HTTP.
• Aangepaste CSS- of widgetinhoud: Achtergrondafbeeldingen, font imports of andere bronnen opgegeven in custom CSS-velden of tekstwidgets.
• CDN-configuratie: Als u een CDN gebruikt, kan dit zo zijn geconfigureerd dat assets via HTTP in plaats van HTTPS worden geleverd.

Stap 1: Werk WordPress en site-URL's bij

Zorg er allereerst voor dat uw WordPress-kern-URL's correct zijn. Ga naar Instellingen, dan Algemeen en controleer of zowel het WordPress-adres (URL) als het site-adres (URL) beginnen met https://. Als ze nog steeds http:// tonen, werk ze bij en sla op. Dit vertelt WordPress om alle interne links via HTTPS te genereren.

Stap 2: Zoeken en vervangen van HTTP-URL's in de database

De meest effectieve oplossing voor de overgrote meerderheid van mixed content is een database-brede zoek-en-vervang-operatie. Dit pakt hardgecodeerde URL's in berichten, pagina's, widgettekst, custom fields, thema-opties en geserialiseerde data.

Met WP-CLI (de aanbevolen methode voor wie comfortabel is met de commandoregel):

# Voer altijd eerst een dry run uit om te zien wat er wordt gewijzigd
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Controleer de uitvoer zorgvuldig en voer dan echt uit
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Als uw site ook het www-subdomein gebruikt, voer beide varianten uit
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

WP-CLI verwerkt geserialiseerde data correct, wat cruciaal is. Veel plugins slaan instellingen op als geserialiseerde arrays in de database, en een naïeve SQL find-and-replace zou het serialisatieformaat breken.

Mixed content oplossen met de Better Search Replace-plugin

Als u geen toegang tot de commandoregel hebt, biedt de plugin Better Search Replace een gebruiksvriendelijk alternatief:

1. Installeer en activeer Better Search Replace vanuit de WordPress plugin directory.
2. Ga naar Tools, dan Better Search Replace.
3. Voer in het veld "Search for" http://example.com in (uw werkelijke domein).
4. Voer in het veld "Replace with" https://example.com in.
5. Selecteer alle tabellen in de tabellenlijst (Ctrl+A of Cmd+A).
6. Vink eerst "Run as dry run" aan en klik op "Run Search/Replace".
7. Controleer de resultaten. Als de vervangingen correct lijken, vink "Run as dry run" uit en voer het opnieuw uit.

Wis na de vervanging eventuele caching-plugins en controleer uw site opnieuw.

Really Simple SSL gebruiken als snelle oplossing

De plugin Really Simple SSL hanteert een andere aanpak. In plaats van URL's in de database te repareren, herschrijft hij dynamisch HTTP-URL's naar HTTPS via output buffering en WordPress-filters. Installeer hem, activeer hem en hij regelt de rest automatisch.

Dit werkt goed als directe oplossing, maar voegt een kleine hoeveelheid verwerkingsoverhead toe aan elke pagina. Voor de beste prestaties is het beter om de URL's bij de bron (databaseniveau) te repareren en de plugin daarna uit te schakelen. Beschouw Really Simple SSL als een vangnet en niet als een permanente oplossing.

Thema- en pluginbestanden handmatig repareren

Sommige mixed content komt van hardgecodeerde URL's in thema- of pluginbestanden in plaats van de database. Doorzoek uw actieve themamap op verwijzingen naar http://:

# Zoek naar hardgecodeerde HTTP-URL's in uw thema
grep -r "http://" /path/to/wp-content/themes/your-theme/ --include="*.php" --include="*.css" --include="*.js"

Vervang hardgecodeerde HTTP-URL's door HTTPS, of nog beter, gebruik protocolrelatieve URL's (//example.com/resource.js) of WordPress-functies zoals esc_url() die de protocolinstelling van de site respecteren.

Bewerk voor externe plugins de pluginbestanden niet rechtstreeks (updates overschrijven uw wijzigingen). Neem in plaats daarvan contact op met de pluginauteur of zoek een nieuwere versie die HTTPS ondersteunt. Als een plugin consistent assets via HTTP laadt, overweeg dan deze te vervangen door een beter onderhouden alternatief.

Een HTTP- naar HTTPS-redirect toevoegen

Stel na het oplossen van alle mixed content in de database en bestanden een server-niveau redirect in zodat resterende HTTP-verzoeken automatisch worden doorgestuurd naar HTTPS:

# Voeg toe aan .htaccess (Apache)
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Voor Nginx-servers, voeg dit toe aan uw server block:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

HTTPS forceren in wp-config.php

Als uw site achter een reverse proxy of load balancer staat, detecteert WordPress mogelijk HTTPS niet correct. Voeg het volgende toe aan uw wp-config.php:

define('FORCE_SSL_ADMIN', true);

// Indien achter een reverse proxy of load balancer
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Uw oplossingen verifiëren en toekomstige mixed content voorkomen

Voer na alle wijzigingen een nieuwe InspectWP-scan uit. De lijst met onveilige URL's in de HTML-sectie moet leeg zijn. Open ook de developer console van uw browser en bevestig dat er geen mixed content-waarschuwingen verschijnen.

Om te voorkomen dat mixed content terugsluipt:

• Stel een Content-Security-Policy-koptekst in: Het toevoegen van Content-Security-Policy: upgrade-insecure-requests als responskoptekst vertelt browsers om HTTP-verzoeken automatisch op te waarderen naar HTTPS. Dit is een goed vangnet.
• Gebruik relatieve of HTTPS-URL's: Gebruik bij het handmatig insluiten van afbeeldingen of bronnen altijd https:// of protocolrelatieve URL's.
• Controleer embeds van derden: Controleer voordat u embedcodes van externe diensten plakt of ze HTTPS gebruiken.
• Audit regelmatig: Stel automatische InspectWP-rapporten in om mixed content op te vangen die verschijnt na content-updates of pluginwijzigingen.