The nightmare that is wp-cron.php
Jedną z głównych bolączek, jakie mam z WordPressem, jest domyślna implementacja wp-cron.php. Jeśli jesteś zaznajomiony z tym, jak WordPress domyślnie używa wp-cron.php, możesz chcieć przejść do następnej sekcji tego artykułu.
Plik wp-cron.php jest częścią WordPressa, która obsługuje zaplanowane zdarzenia w witrynie WordPress. Wszystko, co ma do czynienia z planowaniem postów lub publikacji i naprawdę wszystko data / czas zorientowane jest regulowane przez wp-cron.php file.
W celu wp-cron.php do pracy prawidłowo, to musi być wykonywane często, ale nie więcej niż raz na minutę. Jednakże, domyślne zachowanie nie wymaga od Ciebie ustawienia prawdziwego zadania cron na poziomie systemu na Twoim serwerze. Zamiast tego, używa on metody piggyback na każdym przychodzącym żądaniu. Gdy żądanie przychodzi do witryny, WordPress będzie generować dodatkowe żądanie od siebie do pliku wp-cron.php przez HTTP(S). To brzmi całkiem niewinnie, prawda?
Dlaczego domyślne zachowanie wp-cron.php jest koszmarem?
Domyślna metoda działa doskonale na małej stronie z bardzo małą liczbą odwiedzających na godzinę. Jednak po wdrożeniu na średniej lub większej stronie lub nawet na stronie, która jest skanowana przez boty (co jest bardzo powszechne w dzisiejszych czasach), oznacza to, że dostajesz dwa razy więcej ruchu niż obecnie obsługujesz. To staje się rudymentarny atak DDoS przeciwko sobie. Dzieje się tak, ponieważ cron jest wykonywany wiele razy na minutę przy użyciu żądania HTTP. Żądanie HTTP generuje dodatkowy narzut poprzez konieczność wygenerowania, wynegocjowania i nawiązania połączenia przez gniazdo sieciowe. Wpływa to nawet na efektywną przepustowość bazowego serwera WWW. To rozwiązanie nie radzi sobie dobrze w większości sytuacji i szczerze mówiąc, powinno być usunięte jako domyślne zachowanie ze względu na jego skłonność do nadużywania lub przekształcenia w wektor ataku na serwer tylko z regularnego ruchu.
Cóż, jakie są alternatywy?
Jedyną prawdziwą alternatywą i znacznie lepszym rozwiązaniem jest skonfigurowanie regularnego systemowego cronjob, który wykonuje skrypt wp-cron.php bezpośrednio przez PHP co minutę. Zapewnia to, że wszelkie zaplanowane zadania są rzeczywiście wykonywane w zaplanowanym czasie. Nie powinno to również odbywać się poprzez żądanie HTTP, ale bezpośrednie wykonanie PHP, aby uniknąć utrudniania przepustowości serwera WWW lub generowania dodatkowego narzutu pamięci w warstwie sieciowej.
Jak wyłączyć domyślne zachowanie wp-cron.php?
Jest to dość uniwersalne i proste do zrobienia. Musisz zaktualizować swój plik wp-cronfig.php, aby zawierał następujące ustawienie:
define('DISABLE_WP_CRON', true);
- Zazwyczaj możesz znaleźć swój plik wp-config.php w katalogu public_html swojej witryny.
- To nowe ustawienie powinno być umieszczone w pliku zaraz za linią bazy danych DB_COLLATE, która wygląda jak poniższa
define('DB_COLLATE', '');
Jak ustawić systemowe zadanie cron?
To jest proste w cPanelu, zakładając, że twój dostawca hostingu włączył funkcję zadań cron na twoim koncie. The cPanel Cron Jobs Documentation goes into more details but essentially you do:
- Login to cPanel for your domain: yourdomain.tld/cpanel
- Input „cron” in the quick search box near the top of the page.
- Click „Cron Jobs” icon that appears.
- Jeśli się nie pojawi, twoje konto nie ma włączonej funkcji Cron Jobs i będziesz musiał porozmawiać ze swoim dostawcą hostingu o pomoc w ustawieniu crona lub przejściu na pakiet, który zawiera funkcję Cron Jobs.
- Zwróć uwagę na stronę Cron Jobs, dostarczy ci ona dokładną lokalizację twojego binarnego PHP. Będziesz musiał skopiować tę ścieżkę do pola komend na dole strony i zmienić plik wykonywany przez PHP, aby był to twój plik /home/username/public_html/wp-cron.php. Używając pełnej ścieżki.
- Wybierz pierwszą pozycję („*”) dla każdego parametru. Spowoduje to wykonanie pliku wp-cron.php co minutę.
- Kliknij ten przycisk add cron i gotowe.
Dlaczego jesteś tak surowy dla tej praktyki, wydaje się ona rozsądna i łatwa do naprawienia?
Wierzę, że to do inżynierów oprogramowania, którzy rozwijają nasz cyfrowy świat, należy wpojenie sobie poczucia odpowiedzialności za swoje produkty. WordPress jest wszechobecny w dzisiejszych czasach, a dzięki oprogramowaniu autoinstalacyjnemu, takiemu jak Softaculous, WordPress instaluje się na bardzo dużej większości stron. Są one instalowane z domyślnym zachowaniem włączone, co jest w zasadzie wektor ataku na każdym serwerze. Teraz z branży hostingowej jest tak powszechne w naszym życiu, wiele osób ma witryn WordPress i nie wiem o tym problemie, dopóki nie paraliżuje ich witrynę. Domyślna integracja jest tak bardzo nieodpowiednia i powinna zostać usunięta. Dziś na jednym serwerze sam, znalazłem ponad 500 różnych instalacji WordPress i obserwowałem jak bot uderzył każdą witrynę na serwerze. Każda z tych stron nagle stała się odpowiedzialnością za stabilność serwera.
Zdaję sobie sprawę, że ten problem jest rozpatrywany indywidualnie dla każdego przypadku. Jednak z tak wielu instalacji na całym świecie, to byłoby lepiej adresowane przez WordPress, a nie każdy dostawca usług hostingowych, który musi skonfigurować specjalne warunki na swoim serwerze w celu ochrony przed dziurą to oprogramowanie generuje. Koszt usunięcia tego zachowania i zmuszania właścicieli witryn do generowania crona systemowego powinien być bazowy i zawiadomienie umieszczone w interfejsie administracyjnym WordPressa, że zaplanowane zadania nie będą wykonywane, dopóki zadanie crona systemowego nie zostanie utworzone prawidłowo. To jest w ramach moich umiejętności programowania, więc wiem, że to dobrze w ich.
WordPress ma na celu łatwość użytkowania, więc ich docelowych konsumentów są te, które zazwyczaj niewiele wiedzą o zastrzeżeniach hostingowych. Wierzę, że odpowiedzialność tutaj leży całkowicie z WordPress, aby naprawić i podjęli stanowisko przeciwko temu. W międzyczasie, administratorzy systemu w branży hostingowej muszą cierpieć przez tę straszną „funkcję” podczas badania serwerów, które wypadły spod kontroli z powodu bota działającego nad domyślną instalacją WordPress.
.