Vi è mai capitato di programmare la pubblicazione di un post su WordPress e scoprire qualche ora più tardi che qualcosa non è andato giusto e che la programmazione è saltata? Tranquilli, non siete i soli. Si tratta di un problema che capita spesso, soprattutto quando vi sono degli aggiornamenti software e OS da parte del vostro hosting provider.
In questo post vi spiegherò meglio i motivi di questo comportamento, e vi darò una soluzione efficace per eliminarlo.
I post schedulati non sono affatto “rotti”, e non lo sono mai stati. I programmatori di WordPress non devono sistemare questa funzione, perché non c’è nulla che non vada nel coding. Il problema risiede nel fatto che il tuo server di hosting non riesce, per svariati motivi, a eseguire il processo wp_cron. Questo processo è il meccanismo di timing di WordPress, gestisce di tutto dalla schedulazione dei post fino all’invio dei pingback in risposta ai ping XMLRPC.
Il modo in cui wp_cron funziona è molto semplice. Ogni volta che una pagina viene caricata, WordPress controlla internamente per vedere se c’è bisogno di lanciare il wp_cron, comparando l’orario attuale con l’ultima volta in cui il processo è stato eseguito. Se ha bisogno di eseguirlo, allora prova a fare una connessione HTTP a se stesso, chiamando il file wp-cron.php.
C’è un motivo per questo comportamento. wp-cron ha un sacco di lavoro da fare, e il lavoro richiede tempo. Dal punto di vista della user experience, non è una buona cosa ritardare la visualizzazione della pagina per aspettare l’esecuzione del processo, meglio farglielo eseguire su di un processo separato. Dato che WordPress stesso non si preoccupa del risultato, esso attende solo un secondo, poi restituisce comunque la pagina. Nel frattempo, dato che wp_cron è stato lanciato, esso fa quel che deve finché non è finito o si esaurisce la fase di esecuzione.
Fondamentalmente, WordPress si comporta come un browser web. Se il tuo sito è stato http://example.com/blog, allora WP chiamerà http://example.com/blog/wp-cron.php per avviare il processo. Tuttavia, alcuni server semplicemente non ci riescono per qualche motivo. Tra le possibili ragioni:
- Il Server non ha il DNS, e quindi non può capire chi è “example.com” è, anche se è se stesso.
- Gli amministratori dei server, in un maldestro tentativo di sicurezza, hanno bloccato le richieste di “loopback”, quindi non può effettivamente completare una chiamata a se stesso.
- Sul server è in esecuzione qualcosa chiamato mod_security o simili, che attivamente blocca la chiamata a causa di una configurazione.
- Qualcos’altro.
Il punto è che per qualsiasi ragione, il server Web è configurato in un certo modo non-standard che impedisce WordPress di fare il suo lavoro. WordPress semplicemente non può rimediare.
Tuttavia c’è una soluzione. Aggiungete questa riga nel file wp-config.php
define (‘ALTERNATE_WP_CRON’, true);
Si tratta di un metodo che a volte può non funzionare, ma che garantisce l’utilizzo di un approccio di reindirizzamento, che permette ai browser degli utenti di effettuare un reindirizzamento quando il cron deve essere eseguito, di modo che essi tornino sul sito immediatamente, mentre cron continua a funzionare nella connessione appena instaurata.
