W skrócie: Błąd „failed to open stream" oznacza, że PHP nie mógł odczytać ani otworzyć pliku, który spodziewał się znaleźć. Najczęstsze przyczyny to nieprawidłowe uprawnienia plików, brakujący lub usunięty plik, ograniczenie
open_basediru Twojego hosta albo zakodowana na stałe ścieżka bezwzględna pozostała po migracji witryny. Skorzystaj z tabeli decyzyjnej poniżej, aby przejść od razu do rozwiązania dla Twojego dokładnego komunikatu o błędzie.
Błąd WordPressa „Failed to Open Stream" pojawia się, gdy PHP nie może otworzyć pliku, który Twoja witryna spodziewa się znaleźć. Objawia się jako ostrzeżenie PHP w dzienniku błędów i może uniemożliwić poprawne ładowanie stron, wtyczek lub motywów.
Contents
Zrozumienie błędu „WordPress Failed To Open Stream"
Gdy WordPress lub wtyczka wywołuje fopen(), include() lub require() PHP na ścieżce pliku, PHP zwraca ten błąd, jeśli nie może ukończyć operacji. W WordPressie 6.7 i nowszych błędowi zwykle towarzyszy ślad stosu w wp-content/debug.log, gdy WP_DEBUG_LOG jest włączony.
Dokładne brzmienie błędu zależy od przyczyny, a sufiks mówi dokładnie, co poszło nie tak:
failed to open stream: No such file or directory— plik nie istnieje pod tą ścieżką.failed to open stream: Permission denied— plik istnieje, ale PHP nie ma dostępu do odczytu.failed to open stream: Operation not permitted— ograniczenieopen_basedirna poziomie serwera blokuje dostęp.
Co powoduje błąd Failed To Open Stream w WordPressie?
Skorzystaj z tej tabeli, aby dopasować swój dokładny sufiks błędu do właściwego rozwiązania:
| Sufiks błędu | Przyczyna źródłowa | Przejdź do |
|---|---|---|
No such file or directory |
Brakujący lub usunięty plik; ścieżka bezwzględna zakodowana na stałe ze starego serwera | Metoda 4 lub Metoda 6 |
Permission denied |
Zbyt restrykcyjne uprawnienia pliku lub katalogu | Metoda 1 |
Operation not permitted |
Ograniczenie open_basedir u Twojego hosta |
Metoda 5 |
| Brak wyraźnego sufiksu / ogólny | Konflikt wtyczki lub motywu | Metoda 2 lub Metoda 3 |
Częste przyczyny źródłowe:
- Nieprawidłowe uprawnienia plików: Pliki powinny mieć
644, a katalogi755. Bardziej restrykcyjne ustawienia blokują PHP przed odczytem potrzebnych plików. - Konflikty wtyczek lub motywów: Wtyczka lub motyw odwołujący się do ścieżki, która już nie istnieje, albo dwie wtyczki wywołujące ten sam plik w niezgodny sposób.
- Brakujące lub uszkodzone pliki: Pliki usunięte podczas aktualizacji lub uszkodzone przez częściowe przesłanie.
- Ograniczenia
open_basedir: Niektórzy hości ograniczają, do których katalogów PHP może uzyskać dostęp. Każde wywołaniefopen()lubinclude()poza dozwoloną ścieżką natychmiast kończy się niepowodzeniem. - Niezgodność ścieżki bezwzględnej po migracji: Jeśli Twoja witryna została przeniesiona na nowy serwer, stare ścieżki bezwzględne zapisane w bazie danych (na przykład opcja wtyczki zawierająca
/var/www/old-host/wp-content/...) sprawiają, że każde wskazujące na nierequire()kończy się niepowodzeniem na nowym serwerze.
6 skutecznych rozwiązań pozwalających pokonać ten błąd
We wsparciu WP STAGING najczęstszym wyzwalaczem, jaki widzimy, są nieprawidłowe uprawnienia plików lub wtyczka przechowująca nieaktualną ścieżkę pliku po migracji. Zacznij od metody pasującej do Twojego sufiksu błędu powyżej i postępuj dalej.
Metoda 1: Sprawdź uprawnienia plików
Pliki w Twojej instalacji WordPressa powinny mieć 644, a katalogi 755. Możesz zweryfikować i dostosować uprawnienia za pomocą klienta FTP lub Menedżera plików Twojego hosta. W WordPressie 6.7+ możesz też skorzystać z ekranu Stan witryny (Narzędzia → Stan witryny → Informacje → Uprawnienia systemu plików), aby wykryć katalogi o nieoczekiwanych trybach.


Metoda 2: Wyłączanie wtyczek
Gdy napotykasz problemy z konkretnymi wtyczkami, dezaktywuj je pojedynczo, aby wyizolować konflikt. Dezaktywacja wtyczek pozwala zidentyfikować tę problematyczną bez wpływu na resztę witryny.
Oto jak możesz wyłączyć wtyczki:

Metoda 3: Przełączanie na domyślny motyw
Przełącz się na domyślny motyw WordPressa (taki jak Twenty Twenty-Five), aby wykluczyć błąd ścieżki specyficzny dla motywu. Jeśli błąd zniknie po przełączeniu, źródłem problemu jest Twój aktywny motyw.
Oto jak to zrobić:

Metoda 4: Ponowna instalacja plików rdzenia WordPressa
Jeśli przyczyną są brakujące lub uszkodzone pliki rdzenia, ponowna instalacja rdzenia WordPressa zastępuje je w czysty sposób. Najpierw wykonaj kopię zapasową witryny, a następnie postępuj zgodnie z poniższymi krokami.
Pamiętaj: Przed przystąpieniem do jakichkolwiek modyfikacji kluczowe jest utworzenie pełnej kopii zapasowej Twojej witryny WordPress. Ta kopia zapasowa gwarantuje, że masz kopię wszystkich swoich plików i baz danych, zapewniając siatkę bezpieczeństwa na wypadek, gdyby coś poszło nie tak podczas procesu ponownej instalacji.
Niezbędne przygotowania do ponownej instalacji plików rdzenia WordPressa
- Utworzenie pełnej kopii zapasowej witryny przed cofnięciem WordPressa
- Utworzenie witryny testowej na potrzeby obniżenia wersji WordPressa
Postępuj zgodnie z tymi szczegółowymi krokami, aby ponownie zainstalować pliki rdzenia WordPressa i odzyskać kontrolę nad swoją witryną:
Krok 1: Pobierz najnowszą wersję WordPressa
Odwiedź oficjalną witrynę WordPressa (https://wordpress.org) i pobierz najnowszą wersję WordPressa. Zapisz pakiet instalacyjny na swoim lokalnym komputerze.
Krok 2: Wypakuj pakiet instalacyjny WordPressa
Po zakończeniu pobierania wypakuj zawartość pakietu instalacyjnego WordPressa na swoim komputerze za pomocą narzędzia do archiwizacji, takiego jak WinRAR lub 7-Zip. Będziesz mieć teraz folder zawierający wypakowane pliki.
Krok 3: Połącz się ze swoją witryną przez FTP
Aby kontynuować ponowną instalację, musisz połączyć się z serwerem swojej witryny za pomocą FTP (File Transfer Protocol). Do nawiązania połączenia możesz użyć klienta FTP, takiego jak FileZilla. Jeśli nie masz pod ręką swoich danych logowania FTP, pobierz je od swojego dostawcy hostingu.

Krok 4: Usuń istniejące pliki WordPressa
W widoku zdalnego serwera w kliencie FTP przejdź do katalogu głównego swojej instalacji WordPressa. Usuń wszystkie pliki i foldery z wyjątkiem folderu „wp-content" i pliku „wp-config.php". Ten krok zapewnia czysty punkt startowy dla procesu ponownej instalacji.

Krok 5: Prześlij nowe pliki WordPressa
W widoku lokalnym w kliencie FTP przejdź do wypakowanych plików WordPressa z Kroku 2. Zaznacz wszystkie pliki i foldery wewnątrz wypakowanego folderu i prześlij je do katalogu głównego swojej instalacji WordPressa na serwerze. Ten proces może chwilę potrwać, w zależności od prędkości Twojego połączenia internetowego.

Krok 6: Uruchom skrypt instalacyjny WordPressa
Po zakończeniu przesyłania plików otwórz przeglądarkę internetową i odwiedź swoją witrynę WordPress. Zostanie wyświetlony skrypt instalacyjny WordPressa. Postępuj zgodnie z instrukcjami, aby skonfigurować ustawienia bazy danych, utworzyć konto administratora i ukończyć proces instalacji.

Krok 7: Zweryfikuj i przetestuj
Po instalacji zaloguj się do kokpitu WordPressa i sprawdź, czy cała zawartość, motywy i wtyczki Twojej witryny są nienaruszone. Przetestuj różne funkcje, aby upewnić się, że wszystko działa sprawnie.
Metoda 5: Rozwiązywanie ograniczeń open_basedir
Niektórzy hości internetowi ograniczają, do których katalogów systemu plików PHP może uzyskać dostęp, za pomocą dyrektywy open_basedir. Gdy wtyczka lub rdzeń WordPressa próbuje otworzyć plik poza dozwoloną ścieżką, PHP zgłasza failed to open stream: Operation not permitted, niezależnie od tego, czy uprawnienia pliku są poprawne.
Jak to naprawić:
- Skontaktuj się ze swoim hostem i poproś o rozszerzenie ustawienia
open_basedir, aby objęło ścieżkę, do której PHP próbuje dotrzeć. Podaj dokładną ścieżkę ze swojego dziennika błędów. - Przenieś plik do ścieżki, na którą
open_basedirjuż zezwala — na przykład przenieś własne skrypty dowp-content/zamiast do katalogu powyżej katalogu głównego witryny. - Jeśli zarządzasz własnym serwerem, edytuj dyrektywę
open_basedirwphp.inilub w swojej konfiguracji per-vhost i zrestartuj PHP-FPM.
Metoda 6: Naprawianie niezgodności ścieżek bezwzględnych po migracji witryny
Jeśli niedawno przeniosłeś swoją witrynę WordPress na nowy serwer lub do nowego dostawcy hostingu, stare ścieżki bezwzględne zapisane w bazie danych mogą powodować ten błąd. Wtyczka mogła zapisać ścieżkę swojego pliku w momencie instalacji — na przykład /var/www/old-host/wp-content/... — i każde require() lub fopen() wskazujące na tę ścieżkę kończy się niepowodzeniem na nowym serwerze, ponieważ katalog już tam nie istnieje.
Jak to naprawić:
- Włącz rejestrowanie debugowania: dodaj
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);dowp-config.php. Przeczytajwp-content/debug.log, aby znaleźć dokładną nieaktualną ścieżkę, którą PHP próbuje otworzyć. - Użyj narzędzia do wyszukiwania i zamiany, aby zaktualizować zapisaną ścieżkę w całej bazie danych. Za pomocą WP-CLI (dostępnego na większości hostingów zarządzanych) możesz uruchomić:
wp search-replace '/old/absolute/path' '/new/absolute/path' --all-tables. Uruchom to najpierw na kopii testowej. - Po zamianie wyczyść wszelką pamięć podręczną obiektów, aby usunąć buforowane wartości zawierające starą ścieżkę.
Co zrobić, jeśli żadne z rozwiązań nie działa
Jeśli wypróbowałeś wszystkie sześć metod, a błąd nadal występuje, przejdź przez tę listę kontrolną:
- Przeczytaj pełną linię błędu w
debug.log— ścieżka, którą PHP próbował otworzyć, mówi, którą metodę powtórzyć. Ścieżka wewnątrzwp-content/plugins/wskazuje na Metodę 2; ścieżka wskazująca na nieistniejący katalog wskazuje na Metodę 6. - Wyłącz wszystkie wtyczki naraz — nie tylko pojedynczo. Jeśli błąd ustanie, włączaj je z powrotem parami, aby szybciej zawęzić konflikt.
- Przełącz się na domyślny motyw — jeśli jeszcze tego nie zrobiłeś, przełącz się na Twenty Twenty-Five, aby wykluczyć motyw jako źródło.
- Zapytaj swojego hosta — podaj dokładną linię błędu z
debug.log. Hości mogą potwierdzić, czy przyczyną jest politykaopen_basedir, czy zmiana uprawnień po stronie serwera. - Przywróć z kopii zapasowej — jeśli błąd zaczął się po aktualizacji lub zmianie konfiguracji, użyj procesu przywracania WP STAGING, aby cofnąć się do ostatniego działającego stanu, gdy badasz przyczynę źródłową.
Podsumowanie
Aby rozwiązać „WordPress Failed to Open Stream Error", zidentyfikuj sufiks błędu w wp-content/debug.log, a następnie zastosuj odpowiednie rozwiązanie: sprawdź uprawnienia plików (Metoda 1), wyłącz konfliktujące wtyczki (Metoda 2), przełącz motyw (Metoda 3), zainstaluj ponownie pliki rdzenia (Metoda 4), rozwiąż ograniczenia open_basedir (Metoda 5) lub popraw niezgodności ścieżek bezwzględnych po migracji (Metoda 6). Zawsze twórz kopię zapasową przed wprowadzeniem zmian. WYPRÓBUJ WP STAGING ZA DARMO