Rozwiązywanie ostrzeżeń mixed content w WordPress

Ostrzeżenia mixed content to jeden z najczęstszych problemów, z jakimi właściciele witryn WordPress spotykają się po przejściu z HTTP na HTTPS. Występują, gdy Twoja witryna jest ładowana przez bezpieczne połączenie HTTPS, ale niektóre zasoby na stronie (obrazy, skrypty, arkusze stylów, iframe) są nadal żądane przez zwykłe HTTP. Przeglądarki traktują to jako zagrożenie bezpieczeństwa i słusznie. Dobra wiadomość jest taka, że mixed content jest łatwy do naprawienia, gdy tylko zrozumiesz, skąd pochodzi.

Jak wyglądają ostrzeżenia mixed content w przeglądarce

Gdy strona zawiera mixed content, przeglądarki reagują na różne sposoby w zależności od typu zasobu. Dla "aktywnego" mixed content (skrypty, iframe, arkusze stylów) większość przeglądarek całkowicie blokuje zasób i pokazuje ostrzeżenie w konsoli developer. Dla "pasywnego" mixed content (obrazy, audio, wideo) zasób może się nadal załadować, ale ikona kłódki w pasku adresu znika lub pokazuje trójkąt ostrzegawczy.

W Chrome zobaczysz komunikaty takie jak "Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource" w konsoli. Firefox pokazuje szarą kłódkę z trójkątem ostrzegawczym. Safari może po cichu blokować niektóre zasoby bez wyraźnej informacji wizualnej, co utrudnia debugowanie.

Praktycznym rezultatem jest to, że Twoja witryna wygląda na zepsutą dla odwiedzających. Obrazy mogą się nie ładować, style mogą zniknąć, a skrypty mogą zawodzić. Co gorsza, Google traktuje HTTPS jako sygnał rankingowy, więc problemy z mixed content mogą pośrednio zaszkodzić Twojemu SEO.

Jak znaleźć każdy zasób mixed content na witrynie

Zanim cokolwiek naprawisz, potrzebujesz pełnej listy zasobów HTTP, które są ładowane. Jest kilka niezawodnych sposobów, aby to zrobić:

• Skan InspectWP: Uruchom skan na swojej witrynie. Sekcja HTML wymienia każdy niezabezpieczony URL znaleziony na stronie, dając Ci jasną inwentaryzację tego, co wymaga naprawy.
• Konsola DevTools przeglądarki: Otwórz narzędzia developerskie przeglądarki (F12 lub Cmd+Shift+I na Macu), przejdź do zakładki Console i przeładuj stronę. Każde ostrzeżenie mixed content pojawia się tutaj z dokładnym URL naruszającego zasobu.
• Narzędzie Why No Padlock: Odwiedź whynopadlock.com i wprowadź swój URL. Skanuje stronę i raportuje wszystkie niezabezpieczone zasoby w prostej liście.
• Test SSL Labs: Choć głównie służy do sprawdzania certyfikatu SSL, test Qualys SSL Labs może również oznaczać problemy z mixed content.

Dla witryn z wieloma stronami możesz chcieć sprawdzić więcej niż tylko stronę główną. Testuj ważne strony docelowe, wpisy blogowe (zwłaszcza starsze) i strony z osadzonymi mediami lub treścią zewnętrzną.

Najczęstsze przyczyny mixed content w WordPress

Mixed content rzadko pochodzi z jednego źródła. Oto najczęstsi winowajcy:

• Zakodowane URL HTTP w treści wpisów: Jeśli tworzyłeś wpisy i strony przed przejściem na HTTPS, wszystkie URL obrazów, linki i osadzone media w edytorze treści nadal używają http://. WordPress zapisuje je jako bezwzględne URL w bazie danych.
• Pliki motywu z zakodowanymi URL: Niektóre motywy zakodują na sztywno ścieżki obrazów lub zewnętrzne URL zasobów z http:// zamiast używać URL relatywnych protokołem lub funkcji WordPress.
• Zasoby wtyczek: Starsze lub źle utrzymywane wtyczki mogą ładować swoje pliki CSS i JavaScript przez URL HTTP.
• Zewnętrzne osadzenia i iframe: Osadzenia Google Maps, filmy YouTube (starsze kody osadzania), widgety mediów społecznościowych i skrypty reklamowe czasami używają HTTP.
• Niestandardowy CSS lub treść widgetu: Obrazy tła, importy czcionek lub inne zasoby określone w niestandardowych polach CSS lub widgetach tekstowych.
• Konfiguracja CDN: Jeśli używasz CDN, może być skonfigurowany do dostarczania zasobów przez HTTP zamiast HTTPS.

Krok 1: Zaktualizuj URL WordPress i witryny

Najpierw upewnij się, że Twoje główne URL WordPress są poprawne. Przejdź do Ustawienia, następnie Ogólne i sprawdź, czy zarówno adres WordPress (URL), jak i adres witryny (URL) zaczynają się od https://. Jeśli nadal pokazują http://, zaktualizuj je i zapisz. To mówi WordPress, aby generował wszystkie linki wewnętrzne przez HTTPS.

Krok 2: Znajdź i zamień URL HTTP w bazie danych

Najbardziej skutecznym rozwiązaniem dla zdecydowanej większości mixed content jest operacja wyszukiwania i zamiany w całej bazie danych. Obsługuje to zakodowane URL we wpisach, stronach, tekście widgetów, polach niestandardowych, opcjach motywu i danych serializowanych.

Z WP-CLI (zalecaną metodą dla osób komfortowych z linią poleceń):

# Zawsze najpierw uruchom dry run, aby zobaczyć, co zostanie zmienione
wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

# Dokładnie sprawdź wynik, a następnie uruchom na żywo
wp search-replace 'http://example.com' 'https://example.com' --all-tables

# Jeśli Twoja witryna używa również subdomeny www, uruchom obie warianty
wp search-replace 'http://www.example.com' 'https://www.example.com' --all-tables

WP-CLI prawidłowo obsługuje dane serializowane, co jest kluczowe. Wiele wtyczek zapisuje ustawienia jako serializowane tablice w bazie danych, a naiwne SQL find-and-replace zerwałoby format serializacji.

Naprawa mixed content z wtyczką Better Search Replace

Jeśli nie masz dostępu do linii poleceń, wtyczka Better Search Replace oferuje przyjazną dla użytkownika alternatywę:

1. Zainstaluj i aktywuj Better Search Replace z katalogu wtyczek WordPress.
2. Przejdź do Narzędzia, następnie Better Search Replace.
3. W polu "Search for" wprowadź http://example.com (Twoją rzeczywistą domenę).
4. W polu "Replace with" wprowadź https://example.com.
5. Wybierz wszystkie tabele z listy tabel (Ctrl+A lub Cmd+A).
6. Najpierw zaznacz "Run as dry run" i kliknij "Run Search/Replace".
7. Sprawdź wyniki. Jeśli zamiany wyglądają poprawnie, odznacz "Run as dry run" i uruchom ponownie.

Po zamianie wyczyść wszelkie wtyczki cache i sprawdź swoją witrynę ponownie.

Użycie Really Simple SSL jako szybkiego rozwiązania

Wtyczka Really Simple SSL stosuje inne podejście. Zamiast naprawiać URL w bazie danych, dynamicznie przepisuje URL HTTP na HTTPS poprzez buforowanie wyjścia i filtry WordPress. Zainstaluj ją, aktywuj, a ona zajmie się resztą automatycznie.

To działa dobrze jako natychmiastowe rozwiązanie, ale dodaje niewielką ilość narzutu przetwarzania na każdą stronę. Dla najlepszej wydajności lepiej naprawić URL u źródła (poziom bazy danych), a następnie wyłączyć wtyczkę. Traktuj Really Simple SSL jako siatkę bezpieczeństwa, a nie stałe rozwiązanie.

Ręczna naprawa plików motywu i wtyczek

Część mixed content pochodzi z zakodowanych URL w plikach motywu lub wtyczek, a nie z bazy danych. Przeszukaj aktywny katalog motywu pod kątem odniesień do http://:

# Wyszukaj zakodowane URL HTTP w swoim motywie
grep -r "http://" /path/to/wp-content/themes/your-theme/ --include="*.php" --include="*.css" --include="*.js"

Zamień zakodowane URL HTTP na HTTPS lub, jeszcze lepiej, użyj URL relatywnych protokołem (//example.com/resource.js) lub funkcji WordPress takich jak esc_url(), które respektują ustawienie protokołu witryny.

Dla zewnętrznych wtyczek nie edytuj plików wtyczek bezpośrednio (aktualizacje nadpiszą Twoje zmiany). Zamiast tego skontaktuj się z autorem wtyczki lub poszukaj nowszej wersji obsługującej HTTPS. Jeśli wtyczka konsekwentnie ładuje zasoby przez HTTP, rozważ zastąpienie jej lepiej utrzymywaną alternatywą.

Dodanie przekierowania HTTP na HTTPS

Po naprawieniu całego mixed content w bazie danych i plikach skonfiguruj przekierowanie na poziomie serwera, aby pozostałe żądania HTTP były automatycznie przekierowywane na HTTPS:

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

Dla serwerów Nginx dodaj to do bloku server:

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

Wymuszanie HTTPS w wp-config.php

Jeśli Twoja witryna znajduje się za reverse proxy lub load balancerem, WordPress może nie wykrywać HTTPS poprawnie. Dodaj poniższe do wp-config.php:

define('FORCE_SSL_ADMIN', true);

// Jeśli za reverse proxy lub load balancerem
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Weryfikacja napraw i zapobieganie przyszłemu mixed content

Po wszystkich zmianach uruchom nowy skan InspectWP. Lista niezabezpieczonych URL w sekcji HTML powinna być pusta. Otwórz także konsolę developer przeglądarki i potwierdź, że nie pojawiają się ostrzeżenia mixed content.

Aby zapobiec ponownemu pojawianiu się mixed content:

• Ustaw nagłówek Content-Security-Policy: Dodanie Content-Security-Policy: upgrade-insecure-requests jako nagłówka odpowiedzi mówi przeglądarkom, aby automatycznie podniosły żądania HTTP do HTTPS. To dobra siatka bezpieczeństwa.
• Używaj relatywnych lub HTTPS URL: Podczas ręcznego osadzania obrazów lub zasobów zawsze używaj https:// lub URL relatywnych protokołem.
• Sprawdzaj osadzenia zewnętrzne: Przed wklejeniem kodów osadzania z zewnętrznych usług sprawdź, czy używają HTTPS.
• Regularnie audytuj: Skonfiguruj automatyczne raporty InspectWP, aby wychwytywać mixed content pojawiające się po aktualizacjach treści lub zmianach wtyczek.