Pues no, este no es otro post sobre el wp-cron.php de WordPress que empieza explicando cómo desactivar el wp-cron.php de WordPress para ejecutar las tareas programadas con el CRON de Linux.
Existen MUY poca documentación sobre cómo funciona el wp-cron.php de WordPress, para qué podemos utilizarlo y la razón por la que causa tantos problemas que en la mayoría de blogs recomiendan desactivarlo.
Antes de nada, quiero explicar un poco de qué va el tema, ya que el wp-cron.php de WordPress es una parte bastante importante del CMS. Todo el mundo sabe que está ahí y que consume recursos, pero nadie sabe utilizar el wp-cron.php ni cómo funciona.
En este artículo, voy a intentar tratar TODOS los temas relacionados con el wp-cron.php de WordPress que se te puedan pasar por la cabeza y que aún no he visto ningún blog que no hable de lo mismo cuando se habla del wp-cron.php, es decir, de desactivarlo.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
¿Qué es el wp-cron.php y cómo funciona?
El wp-cron.php, como su nombre indica, es un archivo. Lo podemos encontrar en todas las instalaciones WordPress, al igual que el wp-config.php, del que ya hemos hablado anteriormente en este blog.
El wp-cron.php es el archivo que hace funcionar el WP-CRON, el equivalente al CRON de Linux dentro de WordPress. Permite ejecutar tareas programadas cada cierto tiempo de forma completamente automatizada.
En el wp-cron.php, los plugins y los themes cargan tareas programadas para ejecutar procesos, al igual que el núcleo de WordPress, ya que tareas simples como la publicación de post programados o la revisión de actualizaciones se realiza de forma automática con el wp-cron.php de WordPress.
Para hacer esto, el archivo wp-cron.php se ejecuta cada cierto tiempo y comprueba si tiene que ejecutar las tareas. Ahí es donde nos encontramos el problema.
En circunstancias normales, el wp-cron.php debería ejecutarse 1 vez cada minuto, pero el sistema no es perfecto y en lugar de eso WordPress utiliza un sistema bastante ABSURDO para ejecutar el wp-cron.php en periodos cortos de tiempo: cada visita que entra a la web, siempre y cuando no se cachee, ejecuta el wp-cron.php que, a su vez, comprueba si le toca ejecutar alguna tarea.
Eficiente, ¿eh? Pues no, la verdad es que no. Es un consumo de recursos innecesario y un sistema absurdo. Por esta razón, la gente desactiva el wp-cron.php y utiliza el CRON de Linux para hacer exactamente lo mismo.
¿Pero a que así explicado tiene lógica? Al desactivar el wp-cron.php siguiendo los manuales que podemos ver por ahí, lo que hacemos simplemente es desactivar la ejecución del wp-config.php en cada visita, para posteriormente ejecutar el archivo wp-cron.php cada minuto o cada cinco minutos con el CRON de Linux.
Te lo resumo. La gente desactiva el wp-cron.php a favor del CRON de Linux porque consume recursos, pero desconocen el motivo: el wp-cron.php de forma normal NO se ejecuta cada minuto, sino que se ejecuta con las visitas.
Si tienes un sitio web WordPress con miles de visitas concurrentes o un sitio muy dinámico (que no se puede cachear mucho) como una tienda online, le estás metiendo una paliza al wp-cron.php ejecutándolo una y otra vez. Lo que provocas es la sobrecarga de PHP y un excesivo consumo de recursos. No provoca ralentizaciones directamente porque el wp-cron.php se ejecuta en background, aunque puede causar ralentizaciones indirectas si nos quedamos sin recursos para cargar la web.
Y este es un ejemplo claro visualizado desde la consola de peticiones realizadas cada segundo al wp-cron.php de una instalación de WordPress debido a que se está ejecutando con cada vista:
Incluso te lo voy a explicar de una forma más directa con un ejemplo: si tienes 1000 visitas por minuto y todas entran sin cache, estás ejecutando el wp-cron.php de WordPress 1000 veces por minuto, pese a que solo te hace falta ejecutarlo 1 vez por minuto.
En sitios web con muy poco tráfico ocurre justo lo contrario. A veces no se ejecutan las tareas CRON porque tienen que ejecutarse con las visitas… pero no las hay.
¿Ahora entiendes cómo funciona el wp-cron.php y la razón por la que recomiendan desactivarlo a favor del CRON de Linux?
Al final, tenemos dos factores que hacen que el wp-cron.php consuma tantos recursos y que ralentice la carga de todo el sitio web (sobretodo de las zonas no cacheadas, como el panel de control):
- Cada vez se instalan más plugins que añaden más tareas al wp-cron.php y eso hace que la comprobación de tareas que hay que ejecutar sea más pesada y consuma más recursos durante más tiempo.
- Cuantas más visitas sin cachear tenga tu sitio web, más veces ejecutara el wp-cron.php y más veces se realizarán las consultas para ver qué tareas hay que ejecutar en cada momento.
¿Qué se provoca con esto? Pues una bola de nieve que va creciendo y consumiendo más y más recursos mediante la ejecución de PHP.
Al final, la desactivación del wp-cron.php de WordPress se convierte en una técnica WPO aplicable a cualquier instalación de WordPress y que hace más efecto en casos de webs muy dinámicas como tiendas online WooCommerce o áreas privadas creadas con MemberPress o S2Members.
Revisar el WP-CRON de WordPress
Sin utilizar un plugin es un lío comprobar qué tareas están “declaradas” en el CRON de WordPress y cada cuánto se ejecutan, pero existe un plugin gratuito llamado Advanced Cron Manager que nos sirve.
Y justo después de instalar y activar el plugin, en la sección “Herramientas” del panel de control de WordPress nos aparecerá una nueva sección llamada “Gestor del cron”. Abrirá esta ventana:
Creo que, al ver la imagen anterior, es fácil entender el wp-cron.php de WordPress.
Para que te sirva de ejemplo, en el pantallazo anterior puedes ver el nombre del evento (normalmente, todos ejecutados por plugins o por el propio núcleo de WordPress). También cada cuánto se ejecuta el evento y cuándo será la siguiente ejecución.
Podemos modificar las tareas programadas existentes en el WP-CRON. También podemos eliminarlas o crear nuevas tareas.
Además, desde el plugin podemos recibir instrucciones para desactivar la ejecución del wp-cron.php por visitas y activarlo mediante el CRON de Linux:
Me encanta el plugin Advanced Cron Manager. Puedo revisar qué es lo que se está ejecutando periódicamente en mi WordPress y desactivar alguna tarea si yo creo que está abusando con sus ejecuciones.
Como nota final, quiero que revises la captura de tareas que hay en el WP-CRON de la instalación de WordPress de esta misma web:
Y la compares con esta otra del WP-CRON de una instalación WordPress vacía recién instalada en un hosting.
¿A que hay diferencia? Pues la diferencia son las tareas ejecutadas por los plugins y el theme activo, que son la gran mayoría.
Si quieres ver cómo utilizar el plugin Advanced Cron Manager en tu WordPress para gestionar las tareas CRON y tenerlas controladas, puedes ver el siguiente vídeo que he grabado para ti:
Puedes encontrar más información sobre el plugin Advanced Cron Manager en el repositorio oficial de plugins de WordPress: https://es.wordpress.org/plugins/advanced-cron-manager/
Si quieres una alternativa sólida a Advanced Cron Manager, también puedes probar el plugin WP Control, que es gratuito y es bastante utilizado: https://es.wordpress.org/plugins/wp-crontrol/
WP-CRON no funciona: no se ejecutan las tareas
En algunas ocasiones podemos encontrar casos donde, por alguna razón, no se ejecutan las tareas programadas del WP-CRON de WordPress.
¿Cómo se detectan estos errores? Normalmente, la gente se da cuenta por el típico error “Programación perdida” que aparece cuando tienes programado el publicar un artículo y este no se publica, mostrando ese error.
Como he dicho anteriormente, en la mayoría de los casos, cuando vemos un error de programación perdida es porque el wp-cron.php de WordPress no se ha ejecutado.
Normalmente, el wp-cron.php no se ha ejecutado porque ninguna visita lo ha activado.
Simple, ¿no? Sí, es simple, pero por esta razón es necesario conocer el funcionamiento exacto del wp-cron.php de WordPress.
Normalmente, cuando se explica cómo solucionar el error “Programación perdida” o “Missed sheduled” en WordPress, se explica directamente cómo desactivar wp-cron.php y activar el CRON de Linux, sin explicar la razón exacta de este problema.
Desactivar el wp-cron.php y activar el CRON de Linux
Quiero decir antes de empezar que este es un proceso OFICIAL, es decir, es un proceso / configuración que podemos encontrar en la documentación oficial en el CODEX de WordPress. No es ninguna “ñapa”.
También quiero decir que esta configuración que se basa en desactivar la ejecución del wp-cron.php por petición HTTP y activar la ejecución directamente desde el intérprete PHP o mediante petición programada. Es la única forma de “solucionar” el “problema” del wp-cron.php de WordPress y deshacernos del método de ejecución tan absurdo que trae de forma nativa.
Te voy a enseñar cómo hacer este proceso paso a paso y sin complicarte la vida, válido para cualquier hosting o servidor.
1 – Cómo desactivar el wp-cron.php de WordPress
Como dije antes, el proceso para desactivar el wp-cron.php es oficial y WordPress ofrece documentación para hacerlo.
Debemos ir al archivo wp-config.php de nuestro WordPress y añadir esta línea:
| 1 | define('DISABLE_WP_CRON', true); |
Justo después de esta línea:
| 1 | define('DB_COLLATE', ''); |
Si quieres ver el proceso de una forma más animada, puedes ver la edición del wp-config.php de WordPress con un cliente FTP como Filezilla en el siguiente vídeo:
Y si quieres ver cómo editar el wp-config.php de WordPress utilizando el File Manager o Administrador de Archivos de cPanel, puedes ver este otro vídeo:
Después de hacer esto, el archivo wp-cron.php ya no se seguirá ejecutando por HTTP (o HTTPs) con cada petición, pero estaremos sin WP-CRON y debemos hacer algo más para tener tareas programadas en WordPress otra vez.
Yo personalmente te recomiendo NO quedarte sin tareas programadas, ya que procesos importantes como las actualizaciones, las copias de seguridad programadas o la contabilización de estadísticas (en casos donde se necesite) se hacen utilizando el wp-cron.php, por lo que debe ejecutarse SÍ o SÍ.
2 – CRON de Linux en WordPress
Tras el paso anterior, tenemos que configurar algo que ejecute el wp-cron.php de WordPress directamente en el intérprete PHP, sin ser mediante una petición HTTP o HTTPs o, al menos, mediante una petición programada, no circunstancial.
Si configuramos una tarea programada en el CRON de Linux de nuestro servidor, podemos hacer esto.
Podemos configurar la tarea CRON de dos formas, ejecutando el archivo wp-config.php desde rutas internas o desde el dominio externo. Mi recomendación es ejecutarlo desde rutas internas porque nos ahorramos la conexión por HTTP, pero si es muy difícil para ti o no puedes consultar con tu proveedor de hosting para que te ayude, puedes hacerlo desde el dominio (rutas externas).
Mediante rutas internas, debes ejecutar algo similar a esto, aunque adaptado a las rutas del servidor donde se aloja tu web (tanto la ruta al intérprete PHP como la ruta al archivo wp-cron.php). El siguiente ejemplo es para la mayoría de servidores cPanel:
| 1 | /usr/local/bin/php /home/miusuariodecpanel/public_html/wp-cron.php >/dev/null 2>&1 |
Mientras que si haces la petición desde rutas externas para que se ejecute en CRON, debes hacerlo con el comando WGET y quedaría algo similar a esto:
| 1 | wget -q -O /dev/null -t 1 "https://tusitioweb.es/wp-cron.php?doing_wp_cron" >/dev/null 2>&1 |
Debes tener cuidado, ya que si tienes un proxy inverso puede llegar a no funcionar, como por ejemplo CloudFlare.
Por si no te ha quedado claro, en servidores cPanel como los que tenemos en el hosting compartido de Raiola Networks, puedes ver el siguiente vídeo donde te digo cómo hacer el proceso de configurar el CRON de Linux en WordPress:
Y la recomendación general es ejecutar una de estas tareas (debes elegir uno de los dos métodos) cada 5 o 15 minutos. Aunque si queremos podemos configurarlo para que se ejecute cada minuto, creo que se desperdician bastantes recursos y no es necesario. Con ponerlo cada 5 o 15 es suficiente.
¿Quieres
recibir mis articulos?
No te pierdas todos mis trucos para WordPress, CMS, Marketing Digital y WPO.
36 Responses
Hola, la version Pro del plugin tiene unas caracteristicas. Pero no creo que mucha gente lo use en version Pro ya que la Free se hace mucho.
La verdad es que no he usado la Pro, precisamente por eso, la versión Free es buena y esta bastante completa.
Muy interesante el artículo Álvaro.
Investigaré un poco más el wp-cron a ver que le saco de provecho.
Gracias!
Me alegro de que te sirva Jacobo 🙂
Buenas Álvaro, en el artículo dejas claro que debería desactivar el cron de wordpress y activar el de linux si se trata de un sitio no cacheado, pero en el caso de un sitio estático y que está todo en caché ¿Desactivar el cron de wordpress significaría alguna ventaja?
PD: Seguro te estaré dejando muchas preguntas en distintos posts del blog hoy, es que ando retocando uno de mis proyectos y quiero estar seguro de hacer cada cosa porque es correcto y no termine restando en lugar de sumar.
Hola Eudis, yo SIEMPRE recomiendo desactivar el wp-cron de WordPress, aunque cuando se trata de un sitio web no cacheado, lo recomiendo mas aun.
Ten en cuenta que wp-cron.php se ejecuta con cada visita no cacheada, es decir, en un sitio web con trafico se ejecuta muchísimas veces que no tiene que ejecutarse y eso consume recursos.
Un saludo.
Muchas gracias Alvaro, como siempre gran información !!
Como usuario de Raiola, no paro de leer y aplicar tus consejos para WPO en todos mis clientes.
Muchas gracias Jordi!!
En base a tu vídeo de configurar desde CPanel.. si tienes varios sitios en el mismo servidor, no haría falta (en cada tarea nueva cron) cuando se realiza de forma interna, especificar algo.. para diferenciar de una url a otra por ejemplo si tienen frecuencias de revisión o versiones php diferentes? Gracias de antemano
No entiendo exactamente tu pregunta, ya que la diferenciación ya la haces en la ruta de llamada, ya que cada WordPress tiene su wp-cron.php al que hay que llamar.
En cuanto a versión de PHP diferentes…yo nunca lo he probado, ya que en Raiola Networks no lo soportamos al utilizar CloudLinux con su selector de versión de PHP y no el de cPanel.
Un saludo.
Gracias por la explicación, no me quedaba claro lo de que cada Wordpress tiene su wp-cron.php. Me queda otra duda… creando en cpanel nuevas tareas cron.. y no recibir las notificaciones vía mail para comprobar el buen funcionamiento… he probado a poner solamente en wp-config.php: 1
define(‘DISABLE_WP_CRON’, true); sin el siguiente… define(‘DB_COLLATE’, ”); buscando soluciones y comparando hay otras personas que indican colocar el primer comando, no se si esto es correcto e incompleto.. y debe ser tal como lo planteas tú, qué función tiene este ultimo comando: define(‘DB_COLLATE’, ”)…? si se prescinde de él da error?
Disculpa, porque acabo de entender el significado correcto, … colocar define(‘DISABLE_WP_CRON’, true) justo debajo de este comando… define(‘DB_COLLATE’, ”) …. no este último también…. mil disculpas…
Exactamente, simplemente tienes que poner el parámetro una vez en el wp-config.php
Hola Alvaro
Estoy recibiendo mensajes de advertencia sobre el cron en mi herramienta de salud del sitio de mis dos instalaciones de wordpress.
He decidido desactivar el cron virtual y configurar el cron de Linux para ejecutar el wpcron.php mediante rutas internas, según aconsejas en éste post; pero me queda una duda, a pesar de que ya lo habéis tratado en éstos comentarios.
Yo tengo un plan de hosting en Raiola con dos instalaciones wordpress. Si deshabilito la ejecución de wpcron.php en el archivo config. php de cada una de las instalaciones
¿cómo puedo después configurar diferentes rutas para las diferentes instalaciones si el comando que debo usar /usr/local/bin/php /home/miusuariodecpanel/public_html/wp-cron.php >/dev/null 2>&1 sólo admite como ruta el usuario de cpanel, que es el mismo para ambos dominios?
Un saludo y gracias por tan buenos tutoriales
Hola Joaquin, cada wp-cron.php tiene una ruta completamente diferente y tienes que configurar dos wp-cron.php diferentes.
De todas formas, si me mandas por el formulario de contacto de esta web tu email con el que estas registrado en Raiola Networks y el plan de hosting (el dominio principal) te hago el cambio yo personalmente 🙂
Un saludo.
Hola Álvaro,
¿cómo podemos comprobar que tras el cambio, las tareas siguen programadas igualmente?
Plugins como este te ayudaran 🙂
https://wordpress.org/plugins/wp-cron-status-checker/
¡Gracias!
Otra cuestión, si no te importa:
A la hora de añadir el comando WGET en Cpanel, ¿debemos poner exactamente el que pones tú en el artículo, o el que nos da el propio plugin de cron manager? Porque a mí el plugin me da este, que difiere del tuyo: wget -qO- h.t.t.ps://miweb.com/wp-cron.php &> /dev/null
Ostras, perdona que me olvide de contestarte.
Yo con el de Cron Manager nunca he probado, solo he probado el que pongo yo.
De todas formas, el que pongo yo es mas completo y cubre mas casos.
mi hosting por alguna razón no soporta los caracteres / dev / null2> & 1 en su panel de tareas programadas, me sugieren que coloque el comando en un archivo .sh y posteriormente en el panel invocar su ejecución.
por supuesto me lié
Hola Eduardo, me ha descolocado un poco lo que me dices, ya que…es raro que te permitan la ejecución de archivos bash, pero no te permitan mandar a “null” un resultado.
Puedes usarlo sin /dev/null, lo único que te devolverá una “salida” de datos.
Si trabajo con CloudFlare ¿Qué es lo que debería hacer?
El procedimiento es exactamente el mismo con CloudFlare que sin CloudFlare, ya que esto es código PHP, CloudFlare en eso no tiene nada que ver.
Excelente explicación y bien detallada, no sabía que existía esto en wp lo aplicaré en mis sitios web; todos los días se aprende algo nuevo. Muchas gracias!
Gracias a ti Pablo 😉
Buenas tardes Álvaro, estoy creando una intranet en la cual se de antemano que va a tener pocas visitas, pero me interesa enviar unos correos electrónicos en fechas programadas, de hecho serán avisos, que se enviaran un mes antes y otro quince días antes, para ello quiero utilizar bookly o booked, entonces interpreto por tu artículo que como no se van a realizar visitas periódicas en mi intranet estos correos no van a salir, siguiendo las consejos de tu artículo he añadido (‘DISABLE_WP_CRON’, false), en wp-config, pero, lo que no me queda muy claro es en donde he de poner: wget -q -O – ht.t.ps://alvarofontela.com/wp-cron.php?doing_wp_cron.
En el archivo wp-cron? En que parte del archivo ha de figurar dicha instancia? Y por último, como se configuran los tiempos en los que me interesa que haya la “visita” para que dichos avisos se envíen?
Hola Lidia, eso va en el hosting, quizas este video te pueda solucionar la duda: https://www.youtube.com/watch?v=ZQaFcGLx9_w
Evidentemente si no usas cPanel y usas otro panel de control, tienes que buscar donde ponerlo en ese panel de control específico. Pero ya te adelanto que todos tienen para programar tareas CRON.
Excelente tutorial Álvaro, muchas gracias por tu trabajo
Gracias a ti por el comentario Daniel 😉
Hola Álvaro.
¿Cómo haría para que wp-cron se ejecutara con Vesta panel?
Gracias de antemano
Fantástico tutoria Álvaro.
Tengo varias páginas alojadas en Raiola, unas con servidores compartidos y con su c-panel y otra en un VPS optimizado con VESTA panel
Mi pregunta es la siguiente:
¿Cuál es el código que hay que añadir en los trabajos cron de Vesta panel para cargar wp-config.php?
Y una duda respecto a los dos códigos que nos indicas para c-panel: ¿Pueden convivir los dos?
Gracias de antemano
Hola Jesus, independientemente de si uso cPanel, VestaCP o cualquier otro panel, yo siempre uso el segundo código que he dejado en el punto número 2 del post, es decir, el que hace la llamada a través del dominio.
He dejado 2 porque son dos opciones, pero solo se debe elegir 1.
Hola Álvaro, tengo una duda, hay manera de eliminar crones que no sean necesarios en wordpress, por ejemplo, si no envió ni recibo correos, no me sirve tener ese cron y, por lo tanto, me está consumiendo al fin de cuentas recursos. Al igual que ese cron puede haber otros como los que checan las actualizaciones de themes y plugins, que quizás por mi configuración no me interesa tenerlos. La finalidad de lo que quiero lograr es minimizar el consumo de recursos al servidor para que los procesos disponibles puedan aceptar más visitas simultáneas por minuto. Quizás estoy equivocado, es por ello que te pregunto si hay alguna manera de optimizar lo que no se usa, sin afectar el funcionamiento de wordpress.
Hola Sr.1, el problema es que WordPress no tiene CRONs para enviar emails, ya que esas funcionalidades se ejecutan con el wp-cron.php, pero no están registradas junto con el resto de tareas programadas, sino que están directamente en el núcleo de WordPress.
Los únicos que puedes “borrar” son los de los plugins, y puedes detectarlos y listarlos con un plugin como este: https://alvarofontela.com/limpiar-base-de-datos-wordpress/
Hola! Entonces, si desactivo Desactivar el wp-cron.php y activo Advanced Cron Manager, estarían cubiertas estas tareas? De todos modos, si la web no tiene apenas tráfico, ni se trata de una tienda online, sería necesario tener alguno de los dos activado? En mi caso, me da error al actualizar el plugging de GRavity Forms por problema en WP-Cron. ¿Qué me recomiendas? Gracias!
Hola Aida, no, tendrías que desactivar el wp-cron.php y después añadir en el gestor de tareas CRON de tu hosting la tarea correspondiente que puedes copiar desde este post o directamente la que te da Advanced CRON Manager desde su interfaz.
Si la web no tiene tráfico y no tienes problemas de recursos en el hosting, puedes optar por no hacerlo.
Sobre el tema de Gravity Forms, con datos tan abstractos, no sabría qué decirte.