Twój WordPress ma problemy z wysyłaniem sygnałów pingback? Zamiast publikacji zaplanowanych wpisów wyświetla tajemniczą informację o „przekroczonym planie” (ang. „missed schedule”)? Wtyczki nie działają jak trzeba?
Tak, możesz mieć problem z cronem.
…problemy z czym?
Bez zagłębiania się w zbędne pierdółki – cron to specjalne narzędzie, które znajduje się na serwerze hostingowym. Odpowiada ono za cykliczne wykonywanie określonych przez użytkownika zadań. (tekst zaktualizowano dzięki wskazówce Grześka – dzięki! :-)).
WordPress od wersji 2.1 wyposażony jest we własnego pseudo-crona (cron to specjalne narzędzie, które odpowiada za cykliczne wykonywanie określonych przez użytkownika zadań), dzięki któremu wykonuje takie operacje jak:
- wysyłanie sygnałów pingback/trackback
- sprawdzanie czy pojawiła się nowa wersja wtyczki czy skórki
- publikowanie zaplanowanych wcześniej wpisów
Jest on także używany przez wtyczki a w tym m.in przez WP Super Cache, WP-Polls, WordPress Database Backup, qTranslate, Google XML Sitemaps i wiele, naprawdę wiele innych.
Mimo iż problemy z cronem pojawiały się już wcześniej to dopiero przejście na WordPress 2.7 / 2.7.1 wywołało prawdziwą ich lawinę.
Symptomy problemów z cronem
Efekty problemów współdziałania WordPressa z cronem mogą być następujące:
- skrypt nie potrafi wykryć czy pojawiła się nowa wersja wtyczki lub skórki
- sygnały pingback i trackback nie docierają do adresatów
- zaplanowane wpisy nie są publikowane („przekroczono plan” / „missed schedule”)
- WP Database Backup – harmonogram tworzenia kopii zapasowych nie jest przestrzegany
- WP Super Chache – chache plików nie jest aktualizowany
- i wiele innych związanych głównie z używanymi wtyczkami
Instalując wtyczkę WP-Cron-Dashboard możesz upewnić się czy aby na pewno zadania zlecone cronowi stoją w miejscu. Poniżej dwa przykłady przeglądu harmonogramu:
- problemem z cronem
Terminy wykonania zadań zostały mocno przekroczone: - brak problemu z cronem
Zadania wykonywane są w ustalonym czasie:
Mając pewność co do źródła problemu możesz przystąpić do działania.
Tymczasowe rozwiązanie problemu
Rozwiązanie znalazłem na New Blog Help gdzie autor radzi aby zastąpić dwa pliki (wp-cron.php
oraz wp-includes/cron.php
) tymi pochodzącymi z WordPressa 2.6.5.
Jest to rozwiązanie raczej tymczasowe ale, co sprawdziłem u siebie, działa perfekcyjnie.
Komentarze
drobna niescislosc – ten fragment:
sugerujesz, ze WP korzysta z UNIXowego cron deamona, co jest nieprawda.
WP implementuje cos na ksztalt pseudo-crona i dziala to w ten sposob:
http://www.kminek.pl/jak-postawic-spambloga-na-wordpressie/#wordpressowy-harmonogram-zadan
pozdrawiam
odpowiedzTego akurat nie wiedziałem :-).
odpowiedzDzięki Grzesiek za zwrócenie uwagi i wyprowadzenie z błędu.
nie ma sprawy ;)
odpowiedzHmmm, w końcu jakiś ciekawy artykuł :)
odpowiedzCo nie oznacza, że inne były słabe :)
Aczkolwiek dzięki za poradę, bo na prawdę – przydała mi się ;] Sam MIAŁEM problemy z cronem, ale dzięki WPNinja zażegnałem go :)
Thx Szymon :P
Ja podobne problemy miałem jedynie na słabszych jakościowo hostingach. Na tych topowych zawsze zero problemów :)
odpowiedzJa problem wykryłem na razie tylko na hostingu linuxpl.com – nie miałem jeszcze okazji sprawdzić tego gdzie indziej.
odpowiedzJa również korzystam z linuxpl.com i nie mam w/w problemów.
odpowiedzpo aktualizacji wordpressa z 2.7 na 2.71 wyskoczylo mi takie cos przy logowaniu:
co zrobic ?
odpowiedz@Iwonka: Tomek podał już rozwiązanie w innym temacie:
odpowiedz@Iwonka: Pytałaś o to hasło i rozmowa trochę się rozwinęła. Przeczytaj ostatnie komentarze: https://wpninja.pl/wordpress-271/
odpowiedzA u mnie nie działa :/
odpowiedzWitam,
Uruchamiając poniższy kod zmienna licznik_koncert powinna być zwiększana o jeden co jedną godzinę. Niestety funkcja się nie uruchamia.
Sprawdzając za pomocą wtyczki Cron GUI polecenie jest dodawane i czas tak jak powinno być zmienia się co godzinę.
//cron***********************
add_action(’spamblog_dodaj_posty_hook1′, 'skan_koncert’);
function scan_koncert(){
$l=0; $l=get_option(’licznik_koncert’); $l++; update_option(’licznik_koncert’, $l);
}
if (get_option(’myPlugin_aktywny1′)==’1′ ) { }else{ update_option(’myPlugin_aktywny1′, '1′); spamblog_activate1(); } //register_activation_hook(__FILE__, 'spamblog_activate1′ );
register_deactivation_hook(__FILE__, 'spamblog_deactivate1′ );
function spamblog_activate1() {
wp_schedule_event( time(), 'hourly’, 'spamblog_dodaj_posty_hook1′ );
}
function spamblog_deactivate1() {
wp_clear_scheduled_hook(’spamblog_dodaj_posty_hook1′);
delete_option(’myPlugin_aktywny1′);
}
//cron**************************************
Funkcja register_activation_hook(__FILE__, 'spamblog_activate1′ ); też nie działa. Zastąpiłem ją następującym kodem:
if (get_option(’myPlugin_aktywny1′)==’1′ ) { }else{ update_option(’myPlugin_aktywny1′, '1′); spamblog_activate1(); }
Korzystam z najnowszego wordpressa. Czy ktoś może spotkał się z takim problemem?
odpowiedzCzy aby problemy z cronem nie sa spowodowane jego brakiem na serwerze hostingowy?
Tj. w niektórych ofertach zadania cykliczne są dodane do abonamentu (cPanel) za serwer a w niektórych ofertach tego dodatku brak.
Napisałeś, że WP posiada swój „pseudo cron” ale czy nie jest może tak, że wspomaga się tym, który dostarczany jest przez usługodawce serwera?
Chciałbym to zweryfikować dlatego, że zdarzyło się iż wtyczka WP Responder nie działała, nie wysyłała biuletynu z autorespondera i dziwnym zbiegiem okoliczności serwer nie posiadał cronów.
Czy możesz rozwiązać te wątpliwości?
odpowiedzPozdrawiam ;)
Nie, cron w WordPressie jest całkowicie niezależny. Możliwe, że autoresponder nie zadziałał poprawnie bo nikt strony akurat nie odwiedził (to jest zasada działania tego crona – uruchamia się on tylko podczas wczytywania strony).
odpowiedzDodaj własny komentarz