Mixed Content w WordPressie pojawia się wtedy, gdy strona działa przez HTTPS, ale część zasobów – na przykład obraz, skrypt lub arkusz CSS – nadal jest ładowana przez HTTP. Najtrwalsza naprawa polega na zamianie adresów w bazie danych z http:// na https://, najlepiej po wykonaniu kopii zapasowej.
Dlaczego SSL działa, ale przeglądarka ostrzega?
Sam certyfikat SSL nie poprawia automatycznie wszystkich adresów zapisanych wcześniej w WordPressie. Po migracji witryny na HTTPS w bazie danych, treści wpisów, ustawieniach motywu albo plikach wtyczek mogą pozostać odwołania zaczynające się od http://. Przeglądarka widzi wtedy połączenie szyfrowane i nieszyfrowane na tej samej stronie, czyli Mixed Content.
Problem może dotyczyć obrazów, plików JavaScript, arkuszy CSS, filmów, ramek iframe lub zewnętrznych skryptów. Pasywna treść mieszana zwykle powoduje brak obrazu albo niepełny wygląd strony. Aktywna, na przykład skrypt lub arkusz stylów, jest poważniejszym problemem, ponieważ przeglądarka może ją zablokować, a niezabezpieczony zasób może zostać zmodyfikowany podczas ataku typu man-in-the-middle.
Jak znaleźć źródło błędu?
Najpierw sprawdź konkretny adres zasobu. Nie zmieniaj jeszcze masowo danych, dopóki nie wiesz, co powoduje ostrzeżenie:
- Otwórz problematyczną podstronę w Google Chrome, Firefoxie albo Edge i naciśnij F12 lub Ctrl+Shift+I.
- Przejdź do zakładki Console. W razie potrzeby odśwież stronę, aby ponownie wyświetlić komunikaty.
- Poszukaj czerwonych błędów zawierających frazę „Mixed Content”. Zwykle komunikat pokazuje adres strony oraz konkretny plik ładowany przez HTTP.
- Otwórz wskazany adres po zmianie początku na
https://. Jeśli zasób nie działa przez HTTPS, trzeba go przenieść na serwer obsługujący szyfrowane połączenie albo zastąpić innym.
Czerwony komunikat najczęściej oznacza aktywną treść mieszaną zablokowaną przez przeglądarkę. Żółte ostrzeżenia mogą dotyczyć zasobów pasywnych, ale ich także nie należy pozostawiać bez sprawdzenia. Przetestuj kilka podstron, ponieważ błąd może występować tylko w konkretnym wpisie, szablonie lub formularzu.
Wtyczka tymczasowa czy trwała zmiana w bazie?
| Metoda | Zalety | Wady | Trwałość |
|---|---|---|---|
| Really Simple Security | Szybka konfiguracja i automatyczna obsługa części odwołań | Naprawa odbywa się w działającej witrynie i może zwiększać zależność od wtyczki | Rozwiązanie tymczasowe lub pomocnicze |
| Better Search Replace | Zmienia zapisane adresy bezpośrednio w bazie danych | Wymaga kopii zapasowej i ostrożnego wpisania adresów | Rozwiązanie właściwe dla linków zapisanych w bazie |
| Ręczna edycja plików motywu | Usuwa adres zapisany na stałe w kodzie | Wymaga znajomości plików PHP, CSS lub JavaScript | Trwała, jeśli zmiana trafi do właściwego pliku |
Wtyczka działająca „w locie” może szybko ukryć problem, ale nie usuwa starych adresów z treści i bazy. Dlatego przy typowej stronie WordPress lepiej potraktować ją jako rozwiązanie awaryjne, a właściwą naprawę wykonać przez wyszukanie i zamianę adresów.
Jak trwale naprawić Mixed Content w WordPressie?
Przed rozpoczęciem wykonaj pełną kopię zapasową bazy danych. Operacja obejmuje wiele tabel, a błędna zamiana może zmienić nieprawidłowe dane lub utrudnić działanie witryny. Kopię warto zapisać poza serwerem i upewnić się, że można ją przywrócić.
Po zabezpieczeniu strony wykonaj następujące czynności:
- Zainstaluj i aktywuj wtyczkę Better Search Replace z panelu WordPress.
- Przejdź do Narzędzia → Better Search Replace.
- W polu wyszukiwania wpisz pełny adres witryny z protokołem HTTP, na przykład
http://twojadomena.pl, a w polu zamiany wpiszhttps://twojadomena.pl. - Zaznacz wszystkie tabele WordPressa. Najczęściej problematyczne adresy znajdują się między innymi w tabelach wpisów i metadanych, ale wybór wszystkich tabel zmniejsza ryzyko pominięcia zasobu.
- Uruchom najpierw tryb testowy, jeśli jest dostępny, aby sprawdzić liczbę znalezionych wystąpień. Po potwierdzeniu danych wyłącz opcję
Run as dry run?i uruchom właściwą zamianę.
Nie zamieniaj bez potrzeby samego ciągu http:// na https:// w całej bazie. Pełny adres własnej domeny ogranicza ryzyko naruszenia odnośników do zewnętrznych usług. Zewnętrzne zasoby trzeba sprawdzać osobno, ponieważ ich właściciel musi udostępniać działającą wersję HTTPS.
Po operacji wyczyść pamięć podręczną WordPressa, wtyczki cache i przeglądarki. Sprawdź kilka podstron oraz konsolę. Jeśli wszystko działa poprawnie, możesz wyłączyć i usunąć Better Search Replace, ponieważ do tej jednorazowej zmiany nie musi stale działać na stronie.
Co zrobić, gdy błąd nadal występuje?
Jeśli konsola nadal wskazuje adres HTTP, sprawdź, gdzie został zapisany. W przypadku Elementora użyj menu Elementor → Narzędzia → Zastąp adres URL i zamień adres domeny z wersji HTTP na HTTPS. Zrób to dopiero po wykonaniu kopii zapasowej.
Niektóre odwołania mogą znajdować się bezpośrednio w plikach motywu lub wtyczki. Dotyczy to szczególnie adresów wpisanych na stałe w plikach PHP, CSS albo JavaScript. Taką zmianę najlepiej wykonywać w motywie potomnym lub po konsultacji z autorem komponentu, ponieważ aktualizacja motywu może nadpisać edytowany plik.
Sprawdź także zewnętrzne czcionki, skrypty analityczne, reklamy i multimedia. Jeżeli dostawca nie udostępnia zasobu przez HTTPS, zamień go na bezpieczną alternatywę albo usuń. Samo przekierowanie nie naprawi problemu, jeśli zewnętrzny serwer nie ma poprawnie skonfigurowanego certyfikatu.
Po usunięciu wszystkich odwołań HTTP strona powinna ładować zasoby wyłącznie przez HTTPS, a ostrzeżenia Mixed Content powinny zniknąć.
