Komunikat „Wybrany odnośnik jest nieaktualny”. Skąd się bierze i jak go usunąć?

Właściciel strony wgrywa paczkę z motywem albo wtyczką, klika „Zainstaluj” i zamiast potwierdzenia widzi niemal pusty, biały ekran z jednym zdaniem. W polskiej wersji WordPressa brzmi ono „Wybrany odnośnik jest nieaktualny.”, a pod spodem znajduje się odnośnik „Proszę spróbować ponownie.”. W wersji angielskiej ten sam ekran pokazuje zdanie „The link you followed has expired.”, które w sieci bywa tłumaczone jako „odnośnik, którego użyto, wygasł”. To zawsze ten sam komunikat.

Zdanie jest mylące, bo nikt w żaden odnośnik nie klikał, a ponowna próba kończy się tak samo. WordPress nie podaje przyczyny, więc łatwo stracić godzinę na powtarzanie tej samej czynności. Tymczasem przyczyn jest tylko kilka i każdą da się potwierdzić w parę minut, bez zgadywania.

Ta instrukcja jest przeznaczona dla osób, które same prowadzą stronę firmową lub sklep i nie są programistami. Po lekturze będzie wiadomo, skąd bierze się komunikat, jak ustalić, która przyczyna zachodzi w danym przypadku, jak ją usunąć na kilka sposobów oraz jak zainstalować motyw lub wtyczkę nawet wtedy, gdy limitów serwera nie da się zmienić.

Po czym rozpoznać ten komunikat i czym różni się od podobnych błędów?

Ekran jest bardzo charakterystyczny: białe tło, wąska ramka, jedno zdanie „Wybrany odnośnik jest nieaktualny.” i odnośnik „Proszę spróbować ponownie.”, który prowadzi z powrotem do poprzedniej strony. Nie ma menu kokpitu ani żadnej dodatkowej informacji. Serwer wysyła przy tym przeglądarce odpowiedź o numerze 403, czyli odmowę wykonania czynności.

Komunikat pojawia się najczęściej w trzech miejscach: po wysłaniu pliku z motywem w części „Wygląd”, po wysłaniu pliku z wtyczką w części „Wtyczki” oraz po kliknięciu przycisku w formularzu, który przez wiele godzin pozostawał otwarty w karcie przeglądarki. Zdarza się także przy imporcie dużego pliku w części „Narzędzia”.

Warto odróżnić go od kilku podobnych sytuacji, bo każda wymaga innych działań. Zdanie „Dodawany plik przekracza upload_max_filesize zdefiniowane w php.ini.” oznacza, że WordPress sam rozpoznał zbyt duży plik i mówi o tym wprost. Ekran z napisem „413 Request Entity Too Large” pochodzi od serwera, a nie od WordPressa, i wymaga zmiany po stronie hostingu. Okno „Sesja wygasła” z formularzem logowania to z kolei zwykłe wylogowanie po upływie czasu.

Skąd bierze się komunikat, skoro nikt nie klikał w żaden odnośnik?

Każdy formularz i każdy przycisk w kokpicie, który coś zmienia, zawiera ukryty kod zabezpieczający. Dokumentacja WordPressa nazywa go słowem „nonce”. Kod potwierdza, że polecenie rzeczywiście wysłała zalogowana osoba z kokpitu, a nie obca strona podszywająca się pod administratora.

Przy każdej takiej czynności WordPress sprawdza, czy razem z poleceniem dotarł poprawny kod. Jeśli kodu nie ma albo jest nieważny, system przerywa działanie i wyświetla opisany ekran. Komunikat mówi więc w rzeczywistości: „nie otrzymałem ważnego potwierdzenia, że to polecenie pochodzi z kokpitu”. Treść o nieaktualnym odnośniku jest tylko ogólnym sformułowaniem dla wszystkich takich przypadków.

Kod może nie dotrzeć albo stracić ważność z dwóch zasadniczych powodów. Pierwszy, zdecydowanie najczęstszy, dotyczy wielkości wysyłanego pliku. Drugi dotyczy czasu, jaki upłynął od otwarcia strony z formularzem, albo zmiany sesji logowania.

Za duży plik: serwer odrzuca całą przesyłkę razem z kodem

Serwer ma w ustawieniach PHP dwa limity związane z wysyłaniem danych. Pierwszy to upload_max_filesize, czyli największy dopuszczalny rozmiar jednego pliku. Drugi to post_max_size, czyli największy rozmiar całej przesyłki z formularza: pliku razem z pozostałymi polami, w tym z kodem zabezpieczającym.

Dokumentacja PHP opisuje, co dzieje się po przekroczeniu drugiego limitu: jeśli przesyłane dane są większe niż post_max_size, do skryptu nie dociera nic, ani pola formularza, ani plik. WordPress otrzymuje wtedy puste polecenie bez kodu zabezpieczającego, uznaje je za niepotwierdzone i wyświetla komunikat o nieaktualnym odnośniku.

Stąd bierze się całe zamieszanie. Plik jest za duży, ale system o tym nie wie, bo nie zobaczył ani pliku, ani formularza. Widzi tylko brak kodu. Według tej samej dokumentacji domyślne wartości w PHP to 2 MB dla pojedynczego pliku i 8 MB dla całej przesyłki, a rozbudowane motywy i wtyczki w paczkach ZIP często ważą więcej. Firmy hostingowe zwykle ustawiają wyższe limity, ale nie zawsze wystarczające.

Za długo otwarta strona: kod stracił ważność

Kod zabezpieczający nie jest ważny bez końca. Dokumentacja WordPressa podaje, że domyślny czas życia kodu to jedna doba, a ze względu na sposób liczenia rzeczywista ważność wynosi od 12 do 24 godzin. Po tym czasie kod przestaje być przyjmowany, nawet jeśli wszystko inne się zgadza.

W praktyce wystarczy zostawić otwartą kartę z formularzem na noc i rano kliknąć przycisk. Strona wygląda normalnie, ale kod wpisany w jej treść jest już nieważny. To samo dotyczy linków do czynności skopiowanych z kokpitu i użytych następnego dnia.

Kody są też przypisane do konkretnej sesji logowania. Dokumentacja zaznacza, że wylogowanie i zalogowanie unieważnia kody widoczne na wcześniej otwartych stronach. Jeśli więc w jednej karcie nastąpiło ponowne logowanie, przyciski w drugiej, starszej karcie mogą skończyć się tym samym komunikatem.

Jak w pięć minut ustalić, która przyczyna zachodzi?

Zanim cokolwiek zostanie zmienione na serwerze, trzeba mieć pewność, z czym naprawdę jest kłopot. Wystarczy porównać dwie liczby: rozmiar wysyłanego pliku i limity serwera. Obie da się odczytać bez żadnych dodatkowych narzędzi.

1. Na komputerze należy odszukać plik ZIP z motywem lub wtyczką i odczytać jego rozmiar we właściwościach pliku. Wynik najlepiej zanotować w megabajtach.
2. W kokpicie WordPressa trzeba przejść do części „Narzędzia”, a następnie do pozycji „Stan witryny”.
3. U góry ekranu należy przejść na kartę „Informacja”.
4. Na liście trzeba rozwinąć sekcję „Serwer”.
5. W sekcji znajdują się wiersze „Maksymalna wielkość przesyłanego pliku” oraz „Maksymalna wielkość zapytania post w PHP”. To odpowiednio limity upload_max_filesize i post_max_size. Obie wartości należy zanotować.
6. Przy okazji warto odczytać wiersze „Limit czasu wykonania PHP” oraz „Limit pamięci PHP”, bo przydadzą się przy ustawianiu nowych wartości.
7. Na koniec zanotowane liczby porównuje się z rozmiarem pliku.

Jeśli plik jest większy niż wartość z wiersza „Maksymalna wielkość zapytania post w PHP”, przyczyna jest pewna: serwer odrzuca całą przesyłkę. Jeśli plik mieści się w tym limicie, ale przekracza wartość z wiersza „Maksymalna wielkość przesyłanego pliku”, WordPress zwykle pokazuje inne, bardziej zrozumiałe zdanie o przekroczeniu upload_max_filesize. Rozwiązanie w obu przypadkach jest takie samo.

Limit dla plików widać także w drugim miejscu. W części „Media”, na stronie „Dodaj plik mediów”, pod polem wysyłania znajduje się zdanie „Maksymalna wielkość dodawanych plików:” z konkretną wartością. To szybki sposób na sprawdzenie, czy zmiana ustawień w ogóle zadziałała.

Jeżeli plik jest wyraźnie mniejszy od obu limitów, kłopot nie leży w rozmiarze. Wtedy najbardziej prawdopodobna jest druga przyczyna: nieważny kod z powodu długo otwartej karty albo zmiany sesji. Jej usunięcie zajmuje minutę i od niej opłaca się zacząć, gdy komunikat pojawił się po kliknięciu zwykłego przycisku, a nie po wysłaniu pliku.

Co zrobić, gdy przyczyną jest długo otwarta karta albo zmiana sesji?

W tym przypadku na serwerze nie trzeba niczego zmieniać. Wystarczy sprawić, by przeglądarka pobrała świeżą stronę z nowym, ważnym kodem. Sam odnośnik „Proszę spróbować ponownie.” nie zawsze to zapewnia, dlatego lepiej wykonać pełną kolejność czynności.

1. Należy zamknąć kartę z komunikatem oraz wszystkie inne karty z kokpitem tej samej strony.
2. W nowej karcie otwiera się kokpit przez wpisanie adresu, a nie przez cofanie się w historii przeglądarki.
3. Jeśli pojawi się formularz logowania, trzeba się zalogować. Jeśli kokpit otworzy się od razu, warto wylogować się i zalogować ponownie, aby sesja była na pewno aktualna.
4. Do właściwej strony przechodzi się z menu kokpitu, na przykład „Wtyczki”, a potem „Dodaj wtyczkę”.
5. Czynność wykonuje się od początku, bez przerw trwających wiele godzin.

Jeżeli komunikat dotyczył długiego formularza, na przykład ustawień wtyczki, wpisane wcześniej wartości przepadają. Dlatego przy dłuższej pracy radzę zapisywać zmiany na bieżąco, a obszerne treści przygotowywać w osobnym pliku i wklejać je do formularza tuż przed zapisaniem.

Gdy komunikat wraca przy formularzu na publicznej części strony, na przykład w panelu klienta, przyczyną bywa pamięć podręczna. Strona zapisana w pamięci podręcznej zawiera stary kod, który dawno stracił ważność. Należy wtedy wyczyścić pamięć podręczną we wtyczce lub w panelu hostingu i sprawdzić, czy strony z formularzami dla zalogowanych osób są z niej wyłączone.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Sprawdzę limity serwera, ustawię je bezpiecznie, zainstaluję motyw lub wtyczkę i upewnię się, że komunikat nie wraca.

Jak zwiększyć limity serwera, gdy przyczyną jest rozmiar pliku?

Trzeba podnieść dwie wartości jednocześnie i zachować między nimi właściwą zależność. Dokumentacja PHP wymaga, aby post_max_size było większe niż upload_max_filesize, i zaleca, aby memory_limit było większe niż post_max_size. Podniesienie tylko pierwszej wartości jest najczęstszym powodem, dla którego naprawa nie działa.

Jako punkt wyjścia dla typowej strony firmowej proponuję poniższy zestaw. Pierwsza wartość powinna być wyraźnie większa od największego pliku, jaki będzie wysyłany, a kolejne odpowiednio wyższe.

upload_max_filesize = 64M
post_max_size = 128M
memory_limit = 256M
max_execution_time = 300

Ostatni wiersz dotyczy czasu pracy skryptu w sekundach. Rozpakowanie dużej paczki na wolniejszym serwerze trwa dłużej niż domyślne 30 sekund, więc ten limit także warto podnieść. Osobny wpis wyjaśnia, co oznacza błąd przekroczenia czasu wykonania i jak go rozpoznać.

Istnieją cztery drogi wprowadzenia tych wartości. Kolejność poniżej nie jest przypadkowa: zaczyna się od sposobu najbezpieczniejszego, a kończy na takim, który przy pomyłce potrafi wyłączyć stronę. Przed edycją jakiegokolwiek pliku na serwerze trzeba mieć aktualną kopię strony, a przynajmniej kopię zmienianego pliku. Sposób przygotowania opisuje wpis o tym, jak zrobić i sprawdzić kopię zapasową WordPressa.

Panel hostingu: najprostsza i najbezpieczniejsza droga

Większość firm hostingowych pozwala zmienić ustawienia PHP w panelu klienta, bez dotykania plików. Nazwy pozycji różnią się między dostawcami, dlatego nie podaję jednej ścieżki. Zwykle trzeba odszukać część poświęconą ustawieniom lub konfiguracji PHP dla wybranej domeny.

W formularzu należy znaleźć pola o nazwach upload_max_filesize, post_max_size, memory_limit i max_execution_time, wpisać nowe wartości i zapisać zmiany. Jeśli panel podaje wartości bez litery, najczęściej chodzi o megabajty, ale trzeba to potwierdzić w opisie pola. Zmiana zaczyna zwykle działać po kilku minutach.

Niektóre pakiety mają górną granicę, powyżej której panel nie przyjmie wartości. To ograniczenie dostawcy i żaden plik na serwerze go nie obejdzie. Wtedy pozostaje prośba do pomocy technicznej albo instalacja z pominięciem formularza, opisana w dalszej części.

Plik .user.ini: gdy w panelu nie ma takich ustawień

Na serwerach, na których PHP działa w trybie CGI lub FastCGI, ustawienia można podać w pliku o nazwie .user.ini. Dokumentacja PHP zaznacza, że takie pliki są odczytywane wyłącznie w tych trybach. Tryb pracy PHP można sprawdzić w sekcji „Serwer” na karcie „Informacja”, w wierszu „PHP SAPI”.

1. Należy otworzyć menedżer plików w panelu hostingu albo połączyć się z serwerem programem FTP.
2. Trzeba przejść do głównego folderu strony, czyli tego, w którym znajduje się plik wp-config.php.
3. W widoku plików należy włączyć pokazywanie plików ukrytych, bo nazwa zaczyna się od kropki.
4. Jeśli plik .user.ini już istnieje, najpierw pobiera się jego kopię na komputer. Jeśli nie istnieje, tworzy się nowy, pusty plik o tej nazwie.
5. Do pliku wkleja się cztery wiersze z podanego wyżej zestawu, każdy w osobnej linii, i zapisuje zmiany.
6. Następnie trzeba odczekać. Dokumentacja PHP podaje, że pliki tego rodzaju są odczytywane ponownie domyślnie co 300 sekund, czyli co 5 minut.
7. Po tym czasie należy odświeżyć kartę „Informacja” w części „Stan witryny” i sprawdzić, czy wartości się zmieniły.

Jeżeli strona korzysta z wtyczki zabezpieczającej, plik .user.ini może już zawierać jej wpis. Nie należy go usuwać ani zastępować. Nowe wiersze dopisuje się pod istniejącą treścią.

Plik .htaccess: tylko na serwerach z PHP jako modułem Apache

Wiele opisów w sieci zaleca dopisanie wierszy zaczynających się od php_value do pliku .htaccess. Według dokumentacji PHP ten sposób działa wyłącznie wtedy, gdy PHP jest uruchomione jako moduł serwera Apache, a serwer zezwala na takie zmiany w plikach .htaccess. Obecnie większość hostingów pracuje w innym trybie.

Na serwerze, który tych wpisów nie obsługuje, dopisanie ich zwykle kończy się natychmiastowym błędem 500 na całej stronie, łącznie z kokpitem. To droga ryzykowna i radzę z niej korzystać dopiero wtedy, gdy w wierszu „PHP SAPI” widnieje wartość wskazująca na moduł Apache. Bezpieczniejszy jest panel hostingu albo plik .user.ini.

Jeżeli warunek jest spełniony, na końcu pliku .htaccess, poza blokiem oznaczonym jako należący do WordPressa, dopisuje się poniższe wiersze. Wcześniej trzeba pobrać kopię pliku na komputer, aby w razie błędu móc ją od razu wgrać z powrotem.

php_value upload_max_filesize 64M
php_value post_max_size 128M
php_value memory_limit 256M
php_value max_execution_time 300

Gdyby po zapisaniu strona przestała działać, należy natychmiast przywrócić poprzednią wersję pliku. Więcej o ustalaniu źródła takiej awarii zawiera wpis o tym, jak znaleźć przyczynę błędu 500 w WordPressie.

Pomoc techniczna hostingu: gotowa treść zgłoszenia

Gdy panel nie daje dostępu do ustawień, a pliki nie przynoszą zmiany, najkrótszą drogą jest zgłoszenie do pomocy technicznej. Dobrze napisane zgłoszenie oszczędza kilku wymian wiadomości. Można użyć poniższej treści po uzupełnieniu nazwy domeny.

Dzień dobry, proszę o zwiększenie limitów PHP dla domeny [nazwa domeny]: upload_max_filesize do 64M, post_max_size do 128M, memory_limit do 256M oraz max_execution_time do 300 sekund. Przy instalacji motywu z pliku ZIP WordPress zwraca odpowiedź 403 z komunikatem o nieaktualnym odnośniku, ponieważ plik przekracza obecny limit post_max_size. Jeśli w moim pakiecie obowiązuje niższa górna granica, proszę o podanie najwyższych możliwych wartości. Proszę też o informację, czy na serwerze obowiązuje dodatkowy limit wielkości przesyłanych danych poza ustawieniami PHP.

Ostatnie zdanie zgłoszenia jest ważne. Na części serwerów własny limit wielkości przesyłki ma także oprogramowanie serwera lub zapora, niezależnie od PHP. Właściciel strony nie ma do niego dostępu i może go zmienić wyłącznie dostawca.

Jak zainstalować motyw lub wtyczkę bez zmieniania limitów?

Zwiększanie limitów nie jest jedyną drogą. Jeśli chodzi o jednorazową instalację, często szybciej jest ominąć formularz wysyłania w kokpicie. Poniższe sposoby są w pełni poprawne i nie wymagają zmian w konfiguracji serwera.

Instalacja z katalogu WordPressa

Motywy i wtyczki dostępne w oficjalnym katalogu nie wymagają wysyłania pliku z komputera. W części „Wtyczki” wybiera się „Dodaj wtyczkę”, wpisuje nazwę w polu wyszukiwania i klika „Zainstaluj” przy właściwej pozycji. Serwer sam pobiera wtedy paczkę, więc limity formularza nie mają znaczenia. Tak samo działa to w części „Wygląd”, w pozycji „Motywy”, po kliknięciu „Dodaj motyw”.

Wgranie rozpakowanego folderu przez menedżer plików lub FTP

Płatne motywy i wtyczki spoza katalogu można wgrać bezpośrednio na serwer. Limity PHP dotyczą formularzy, a nie plików przesyłanych programem FTP.

• Paczkę ZIP rozpakowuje się na komputerze. W środku powinien być jeden folder o nazwie motywu lub wtyczki.
• Ten folder wgrywa się w całości do katalogu wp-content/plugins w przypadku wtyczki albo wp-content/themes w przypadku motywu.
• Po zakończeniu przesyłania trzeba sprawdzić, czy przeniosły się wszystkie pliki, bez komunikatów o błędach.
• W kokpicie, w części „Wtyczki” lub w pozycji „Motywy”, nowa pozycja pojawia się na liście i czeka na kliknięcie „Włącz”.

Menedżer plików w panelu hostingu zwykle pozwala wgrać plik ZIP i rozpakować go na miejscu, co jest szybsze niż przesyłanie setek drobnych plików. Trzeba tylko dopilnować, aby po rozpakowaniu nie powstał folder zagnieżdżony w drugim folderze o tej samej nazwie, bo WordPress nie rozpozna wtedy motywu.

Sprawdzenie, czy wysyłany jest właściwy plik

Sprzedawcy motywów często udostępniają dwie paczki: pełną, z dokumentacją, plikami graficznymi i przykładową treścią, oraz samą paczkę instalacyjną. Pełna paczka bywa wielokrotnie większa i nie jest przeznaczona do wysyłania w kokpicie. Na stronie pobierania należy poszukać opcji opisanej jako plik instalacyjny dla WordPressa i wysłać tylko ten plik.

Po czym poznać, że naprawa zadziałała?

Pierwszym potwierdzeniem są liczby. W części „Narzędzia”, w pozycji „Stan witryny”, na karcie „Informacja”, w sekcji „Serwer” oba wiersze z limitami powinny pokazywać nowe wartości. Zgadzać się powinna także wartość w zdaniu „Maksymalna wielkość dodawanych plików:” na stronie „Dodaj plik mediów”.

Drugim potwierdzeniem jest sama instalacja. W części „Wtyczki” należy kliknąć „Dodaj wtyczkę”, potem „Wyślij wtyczkę na serwer”, wskazać plik i kliknąć „Zainstaluj”. Poprawny przebieg kończy się ekranem z informacjami „Rozpakowywanie paczki…” oraz „Instalacja wtyczki…” i możliwością włączenia wtyczki. Dla motywu ścieżka prowadzi przez „Wygląd”, „Motywy”, „Dodaj motyw” i „Wyślij motyw na serwer”.

Przy wgrywaniu nowszej wersji motywu lub wtyczki, która jest już zainstalowana, WordPress pokazuje porównanie obu wersji i przycisk „Zastąp aktualny dodawanym” w przypadku wtyczki albo „Zastąp obecny wysłanym” w przypadku motywu. To prawidłowe zachowanie, a nie kolejny błąd. Przed zastąpieniem warto mieć kopię strony, bo poprzednia wersja plików zostaje nadpisana.

Co zrobić, gdy komunikat pojawia się nadal?

Jeśli po zmianach ekran wraca, należy przejść przez poniższe punkty po kolei. Każdy z nich odpowiada jednej, często spotykanej przeszkodzie.

• Wartości w kokpicie się nie zmieniły. Plik z ustawieniami leży w niewłaściwym folderze, ma literówkę w nazwie albo serwer go nie obsługuje. Trzeba sprawdzić nazwę, położenie i tryb pracy PHP, a przy pliku .user.ini odczekać co najmniej 5 minut.
• Zmieniła się tylko jedna wartość. Limit pojedynczego pliku wzrósł, ale limit całej przesyłki pozostał niższy od rozmiaru pliku. Trzeba podnieść post_max_size powyżej upload_max_filesize.
• Wartości są poprawne, a komunikat wraca. Możliwe, że dostawca stosuje górną granicę albo osobny limit poza PHP. Wtedy potrzebne jest zgłoszenie do pomocy technicznej.
• Komunikat pojawia się przy małym pliku lub bez pliku. Przyczyną jest nieważny kod: stara karta, zmieniona sesja albo pamięć podręczna. Należy wykonać czynności z sekcji o długo otwartej karcie.
• Komunikat pojawia się tylko przy jednej wtyczce. Jeżeli dotyczy wyłącznie przycisków jednego dodatku, błąd może tkwić w jego kodzie. Warto zaktualizować ten dodatek i zgłosić sprawę jego autorowi.

Na tym etapie nadal najszybszym wyjściem pozostaje wgranie rozpakowanego folderu przez menedżer plików. Pozwala dokończyć pracę od razu, a sprawę limitów wyjaśnić z dostawcą w spokoju.

Jakich błędów unikać przy usuwaniu tego komunikatu?

Pierwszy błąd to dopisywanie poleceń zmieniających limity wysyłania do pliku functions.php motywu albo do wp-config.php. Dokumentacja PHP zalicza upload_max_filesize i post_max_size do ustawień, których nie można zmienić z poziomu działającego skryptu. Takie wpisy niczego nie podnoszą, a pomyłka w pliku functions.php potrafi zablokować całą stronę.

Drugi błąd to ustawianie skrajnie wysokich wartości w rodzaju kilku gigabajtów. Limity chronią serwer przed przeciążeniem i przed wysłaniem ogromnych plików przez niepowołaną osobę. Wystarczy wartość z rozsądnym zapasem ponad największy plik, jaki faktycznie będzie wysyłany.

Trzeci błąd to instalowanie wtyczek, które obiecują podniesienie limitu jednym kliknięciem, bez sprawdzenia, co naprawdę robią. Dodatek działający wewnątrz WordPressa nie zmieni granicy narzuconej przez dostawcę. Może najwyżej dopisać wiersze do plików na serwerze, a to da się zrobić samodzielnie i pod pełną kontrolą.

Czwarty błąd to szukanie sposobu na wyłączenie sprawdzania kodów zabezpieczających albo znaczne wydłużenie ich ważności. Ten mechanizm chroni kokpit przed poleceniami podsuwanymi przez obce strony. Osłabienie go usuwa komunikat kosztem bezpieczeństwa całej witryny, dlatego stanowczo to odradzam.

Piąty błąd to edytowanie plików na serwerze bez kopii oraz pobieranie motywów i wtyczek z nieoficjalnych źródeł tylko dlatego, że paczka jest tam mniejsza. Taka paczka może zawierać złośliwy kod. Pliki należy pobierać wyłącznie od autora lub z oficjalnego katalogu.

Najczęstsze pytania

Czy ten komunikat oznacza, że strona została zaatakowana?

Nie. Komunikat pochodzi od mechanizmu, który chroni kokpit, i oznacza tylko, że polecenie dotarło bez ważnego kodu potwierdzającego. W zdecydowanej większości przypadków powodem jest zbyt duży plik albo zbyt długo otwarta karta. Sama obecność tego ekranu nie świadczy o włamaniu ani o uszkodzeniu strony.

Dlaczego polska wersja komunikatu brzmi inaczej niż w opisach w sieci?

Większość opisów powstała na podstawie wersji angielskiej, w której zdanie brzmi „The link you followed has expired.”, i tłumaczy je dosłownie. Polski WordPress wyświetla własne tłumaczenie: „Wybrany odnośnik jest nieaktualny.”. Oba zdania oznaczają ten sam ekran i tę samą przyczynę, więc rozwiązania są identyczne.

Czy podniesienie limitów spowolni stronę albo zaszkodzi jej pozycji w Google?

Nie. Limity określają jedynie, jak duże dane serwer zgodzi się przyjąć z formularza i jak długo może pracować jeden skrypt. Nie zmieniają szybkości wyświetlania stron odwiedzającym i nie mają związku z oceną witryny przez wyszukiwarkę. Znaczenie ma tylko to, aby wartości nie były przesadnie wysokie.

Jakie wartości ustawić, jeśli plik ma kilkaset megabajtów?

Przy tak dużych plikach lepiej w ogóle nie korzystać z formularza w kokpicie. Kopie zapasowe, pliki importu i bardzo rozbudowane paczki bezpieczniej jest wgrać przez FTP lub menedżer plików, a import przeprowadzić narzędziem, które dzieli dane na mniejsze części. Podnoszenie limitów do kilkuset megabajtów bywa na hostingu współdzielonym niemożliwe i niepotrzebnie obciąża serwer.

Czy to samo rozwiązanie dotyczy wgrywania zdjęć i filmów do biblioteki mediów?

Przyczyna jest ta sama, czyli limity PHP, choć biblioteka mediów zwykle pokazuje inny, bardziej czytelny komunikat o przekroczeniu rozmiaru. Zwiększenie obu wartości rozwiązuje jeden i drugi przypadek. Szczegóły dotyczące samych plików multimedialnych zawiera wpis o tym, jak zwiększyć limit wgrywanych plików.

Ile trzeba czekać na działanie zmian?

Zmiany w panelu hostingu działają zwykle po kilku minutach, zależnie od dostawcy. Plik .user.ini jest według dokumentacji PHP odczytywany ponownie domyślnie co 5 minut, więc tyle należy odczekać przed sprawdzeniem. Zmiany w pliku .htaccess działają od razu po zapisaniu.

Czy komunikat może wracać regularnie mimo poprawnych limitów?

Tak, jeśli wynika z nieważnych kodów, a nie z rozmiaru plików. Dzieje się tak przy pracy na wielu kartach otwartych przez całą dobę, przy częstym przełączaniu się między kontami oraz wtedy, gdy pamięć podręczna zapisuje strony z formularzami. Pomaga odświeżanie strony przed wykonaniem czynności i wyłączenie takich stron z pamięci podręcznej.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

To zupełnie zrozumiałe. Ustawienia serwera nie są zajęciem, którym właściciel firmy powinien wypełniać sobie dzień, a jedna pomyłka w pliku potrafi wyłączyć stronę na dłużej, niż trwałaby sama naprawa. Chętnie przejmę tę sprawę w całości: sprawdzę, która przyczyna zachodzi, wykonam kopię, ustawię limity w najbezpieczniejszy dostępny sposób, w razie potrzeby porozumiem się z pomocą techniczną hostingu, zainstaluję motyw lub wtyczkę i potwierdzę, że wszystko działa.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz krótki opis tego, co nie chce się wgrać. Odpowiem, co da się zrobić i czego będę potrzebować, aby zacząć.