WordPress

„Object-cache.php” wyłącza wp_cron, a nawet wyłącza całą moją witrynę i pojawia się ponownie po jej usunięciu

  • 31 października, 2023
  • 5 min read
„Object-cache.php” wyłącza wp_cron, a nawet wyłącza całą moją witrynę i pojawia się ponownie po jej usunięciu


Mam naprawdę irytujący problem. Może to obejmować wtyczki (a może nie, nie wiem), ale uważam, że jest to na tyle techniczne, że można je tutaj dopuścić.

Kilka tygodni temu musiałem wrócić do kopii zapasowej i odkryłem, że moja kopia zapasowa UpdraftPlus przestała działać kilka tygodni wcześniej, narzekając, że wp_cron został wyłączony.

Po wielu godzinach w końcu wyśledziłem przyczynę jako plik o nazwie object-cache.php w moim folderze wp-content, który wyraźnie wyłączał wp_cron, więc nie mogłem w ogóle wykonać kopii zapasowej, nawet ręcznie. Nie mogłem (wówczas) ustalić, skąd pochodzi ten plik ani co to było. Usunięcie linii, która wyłączyła wp_cron, spowodowało krytyczny błąd wordpress. Próbowałem także zmienić zawartość pliku na just <?php exit; ?>i znowu błąd krytyczny.

Przeszukałem cały katalog WordPress pod kątem „object-cache” i „apcu” (które jest podane jako nazwa w komentarzach do tego pliku), aby sprawdzić, czy uda mi się znaleźć to, co go utworzyło. Nie ma kości.

Więc usunąłem plik.

Kilka dni później sytuacja znów się powtórzyła! Znów ten sam problem, kopie zapasowe przestały działać. Więc usunąłem go ponownie.

Mniej więcej w tym czasie moja witryna zaczęła działać godzinami dziennie, wszystko, łącznie z innymi witrynami, które hostowałem jako nazwane wirtualne hosty w podfolderach na tym samym współdzielonym koncie hostingowym. I nie tylko wordpress — żadne skrypty php na moim serwerze, nawet poza moimi witrynami wordpress, nie będą w ogóle działać. Zadzwoniłem do mojego dostawcy usług hostingowych, ale niestety korzystam z Bluehost. Jeśli wiesz, wiesz. Minęły trzy tygodnie wyprzedaży i wymówek, a oni nie znaleźli żadnego rozwiązania.

Warto przeczytać!  filtry - Przełamanie tajemniczej linii

Po kolejnej frustrującej rundzie bezużytecznych e-maili z moim gospodarzem, rozejrzałem się i odkryłem object-cache.php wrócił ponownie! Usunąłem go… i jakbyś nie wiedział, wszystko od razu zaczęło działać idealnie.

Sprawdziłem i moje dzienniki błędów są pełne PHP Fatal error: Maximum execution time of 60 seconds exceeded in /path/to/wp-content/object-cache.php on line 436.

Widzę też miliony WordPress database error User '[my database username]' has exceeded the 'max_questions' resource (current value: 1) for query SELECT * FROM `wpnf_wfblocks7` WHERE `type` IN (1, 8, 9, 2, 5, 6) AND `IP` = '\0\0\0\0\0\0\0\0\0\0ÿÿØø\Z' AND (`expiration` = 0 OR `expiration` > UNIX_TIMESTAMP()) ORDER BY `blockedTime` DESC LIMIT 1 made by require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('plugins_loaded'), WP_Hook->do_action, WP_Hook->apply_filters, wordfence::veryFirstAction, wfLog->firewallBadIPs, wfBlock::findIPBlock wpisy, których nie przypominam sobie, żebym kiedykolwiek wcześniej widział.

W tej chwili strona już działa, ale w tym momencie wiem, że za kilka dni ten grzyb w jakiś sposób powróci i nie mogę się tym dłużej opiekować.

Przeszukałem historię przeglądarki z ostatniego miesiąca, powiadomienia e-mail uptimeRobot o czasie działania moich witryn, wpisy w dzienniku błędów php, a nawet moje małe narzędzie do śledzenia czasu czytania ekranu na moim laptopie, próbując znaleźć korelację pomiędzy początkiem dowolnego awaria witryny i, szczerze mówiąc, wszystko inne, co zainstalowałem, zmieniłem, zrobiłem lub nawet po prostu otworzyłem, żeby obejrzeć. Nie ma kości.

Warto przeczytać!  jquery — Lista rozwijana kategorii wielu poziomów na trzech poziomach nie działa

Sprawdziłem każdą wtyczkę, która może instalować ten plik. Jakiś czas temu dezaktywowałem wszystkie wtyczki, które zostały wyraźnie opisane jako buforowanie stron (W3 SuperCache i kilka innych, których próbowałem wcześniej) i nie rozwiązało to problemu. Teraz wyłączyłem każdy rodzaj buforowania (buforowanie przeglądarki itp.), ale na dłuższą metę naprawdę nie chcę działać bez buforowania.

Sprawdziłem pliki .htaccess, aby upewnić się, że dezaktywowane wtyczki buforujące nie pozostawiły nic niepokojącego. Nie ma o czym mówić.

Napisałem nawet małe skrypty php „start” i „end”, aby zarejestrować aktualnie uruchomione __FILE__ i zapisz, czy obiekt-cache.php istnieje, czy nie, i ustaw auto_prepend_file i auto_append_file w moim php.ini, aby uruchamiały je na początku i na końcu każdego skryptu PHP, w nadziei, że złapiesz wszystko, co wstawia tego grzyba na moją stronę, ale oni nie przyniosło żadnego efektu, po prostu nie wiedziałem, jak sprawić, by działały. Skrypty działają, gdy wywołuję je z poziomu interfejsu CLI, ale dodawanie i dołączanie nie dzieje się.

Ustawiłem mój plik php.ini max_execution_time = 300 I max_input_time = 600 dziś wieczorem, gdzie byli wcześniej 30 I 60 odpowiednio. Zobaczymy, co Bluehost o tym myśli. Jeszcze nie jestem pewien, czy pomogło.

Warto przeczytać!  Najlepszy czas na publikowanie postów na LinkedIn (dane za 2024 r.)

Nie chciałem przedłużać tego posta, ale na wypadek, gdyby ktoś chciał sprawdzić, czy potrafi wykryć potencjalnych podejrzanych, zamieściłem listę wtyczek, które mam obecnie aktywne, w PrivateBin pod adresem

A zatem: wszelkie sugestie, w jaki sposób mogę dowiedzieć się, co jest tego przyczyną i/lub wrócić do działającej witryny z działającą wtyczką do buforowania, która działa dłużej niż kilka godzin bez mojej opieki nad nią lub konieczności dzwonienia Bluehost co dwa dni?

Z góry dziękuję.


Źródło