Gestores de contenidos

A veces nos damos cuenta que no hemos incluido en el blog soluciones muy básicas, precisamente por ser tan básicas. Pero deberían estar aquí. Este es uno de esos casos, cómo añadir un favicon en una página de WordPress. ¿Qué es un favicon? Es la pequeña imagen que ves en las pestañas de los navegadores y que identifica el sitio. Parece una tontería, pero cuando, como yo, abres muchas pestañas, es útil para saber dónde está cada cosa. Y si tienes una página en WordPress, deberías tener un favicon. ¿Cómo se crea? Ya hemos compartido alguna vez generadores de favicons online. Lo mejor es que uses uno de esos, que ya te creará los iconos en varios tamaños para el navegador, los ipad, iphone etc. ¿Cómo se añade el favicon en tu página de WordPress? Tienes dos escenarios. Tu plantilla tiene un apartado para añadir el favicon. Es muy común en las plantillas comerciales. Normalmente junto al logo, y suele tener opciones para, como hemos dicho, otros tipos de iconos para tablets y móviles. Si es así, usa esta opción. Siempre será mejor y además es bueno tener todo en el mismo sitio. Tu plantilla no tiene un apartado para favicon. Es el caso más general, común en plantillas gratis o plantillas generales. En ese caso tenéis que ir a  Apariencia > Personalizar> Identidad del Sitio.  Ahí veréis un primer apartado con el título y la descripción del sitio. Después un segundo apartado que pone Icono del sitio. Ahí es donde tenéis que poner el favicon. Como dice WordPress, selecciona una imagen de “al menos de 512 píxeles de ancho y alto” y él sólo la pondrá como icono de la página.   Nota: esto es para versiones de WordPress 4.2 en adelante. Mucho más fácil que hace años que había que subir el icono por ftp al directorio raíz de la plantilla o del WordPress. Si es anterior (actualiza loco), tendrías que subirlo, y  a veces poner un código en el header.  

Hoy vamos a intentar explicar un error de WordPress que surge en determinadas ocasiones, si se dan varios casos, y que puede resultar extraño. Caso: Hemos programado una publicación de WordPress, o una oferta de WooCommerce, esperamos que se publique como siempre pero no aparece. Cuando entramos en el backend de vuestra tienda, aparece la publicación con una aviso en rojo: Programación perdida. Causa: ¿Por qué sucede esto? Vamos a intentar explicarlo. Cuando programas una entrada en WordPress, lo que hace el sistema es usar un pseudo-cron llamado wp-cron.php. Como no puede modificar el cron del servidor, deja las tareas pendientes hasta que se cargue un script, hasta que se carga página (porque un cliente ha visitado la web). Es decir, si no se cargan las páginas no se ejecutan las tareas programadas. ¿En qué casos no se cargan las páginas? Si se dan algunas de estas condiciones: No ha habido visitas a tu página en ese periodo de tiempo. Pero tu página tiene que tener pocas visitas para eso. Tienes un sistema de caché en tu web (como W3 Total Cache) que tiene caché de objetos. En ese caso, cuando los clientes solicitan visitar tu página, el sistema les proporciona un html generado, no la página php que dispara el cron wp-cron.php. El cliente visita la página, pero, al ser cacheada no dispara la tarea programada. Soluciones: Tienes tres soluciones posibles. En teoría podemos desactivar en los sistemas de caché la caché de objetos. En W3 Total caché está en Rendimiento>Objet Cache.   Pero nosotros lo teníamos desactivado y aún así no saltó el cron. Si pasa muy a menudo, y tienes acceso de gestión por ssh, o por panel al cron del servidor, puedes editar el cron del servidor para llamar (con fetch) cada cierto tiempo al wp-cron.php. (por la ruta http://www.tuweb.es/wp-cron.php?doing_wp_cron) . Con el tiempo que quieras, por ejemplo cada 15 minutos. Cómo hacerlo depende de cada servidor y el acceso que tengas. Con un plugin. Tienes plugins como Improved Cron, WP-Cron Control,  o WP-Crontrol.  Algunos lo gestionan ellos, otros puedes poner un hook y gestionar tu cuando quieres que se ejecute el código.    

Si gestionas una tienda en Prestashop con bastantes productos, o con un inventario que viene de otro software, estarás acostumbrado a importar productos a tu tienda. En ocasiones, si estás usando un fichero Excel (xslx) para realizar los cambios y luego importarlo a Prestashop, puede que obtengas un error de fecha al importarlos. Puedes tener el error en cualquier campo de fecha (date_add o date_upd). La razón del error es que Excel usa un sistema llamado valores de serie para almacenar las fechas. Almacena todas las fechas como enteros y todas las horas como fracciones decimales. Pero claro, nosotros estamos acostumbrados a verlos como dd/mm/aaaa o similar. Prestashop requiere las fechas en formato aaaa-mm-dd. La solución es sencilla. Tienes dos maneras de arreglar esto. Puedes exportar tu Excel a un fichero delimitado por comas, csv, antes de la importación a Prestashop. En la conversión te convertirá la fecha de serie a texto. Problemas: 1) Al pasarlo a cvs se te van también todas las fórmulas y modificaciones Excel que hayas hecho al fichero. El formato csv permite pocas cosas. Por lo tanto debe ser un fichero sólo de importación. 2) Tienes que asegurarte antes de pasar la fecha al formato que necesita Prestashop (aaaa-mm-dd). Entonces puedes requerir otro paso…y para eso haz el siguiente método y te quedas con el Excel. Si quieres mantenerte en el formato Excel, tienes que cambiar el formato de fechas de serie a texto, con el orden que requiere en Prestashop. Para ello vamos a usar la función TEXT (fecha;”formato”). Si tu Excel está en español la función es  TEXTO (fecha;”formato”). Os lo mostramos en el vídeo:  

Ayer,  respondiendo a una pregunta de un cliente sobre spam en su web de WordPress, nos dimos cuenta que tenemos en el blog plugins de anti-spam, hemos comentado cómo manejar listas negras, pero no lo más sencillo: los Captcha.  Muchas veces publicamos lo complicado y nos olvidamos de lo simple. Así que hoy os hablamos de los Captcha y os recomendamos los plugins que usamos. ¿Qué son los Captcha? Son las imagenes que tenéis que identificar, o las operaciones que tenéis que resolver, o los puzzles que tenéis que montar antes de poner un comentario en una página web. ¿Por qué existen? Porque si no los administradores de páginas web tendríamos que estar borrando cientos de posts de spam al día. Hay robots en Internet que se dedican a plubicar en todos lados. Cuanto más gente lea tu web, más spam te llega. ¿Son eficaces 100%? No. Fueron uno de los métodos de intentar resolver el spam, pero los robots aprendieron a saltárselo. Cada vez que le pones una barrera a los hackers se deleitan en buscar maneras de saltársela. Pero si que es un primer filtro que quita una gran cantidad de publicaciones basura.   Así que recomendamos crear protecciones por capas. Es decir tener Captcha, tener listas negras, incluso tener pugins de anti-spam. Os dejamos los plugins que usamos normalmente con sus pros y sus contras. Captcha by BestWebSoft. Uno de los más usados y seguramente la primera opción si no queremos complicarnos. Permite texto, operaciones, configurar dónde tiene que aparecer y a quién etc. Google Captcha (reCaptcha) by BestWebSoft. Otro plugin de BestWebSoft, en este caso para implementar reCaptcha, el Captcha de Google. Personalmente me gusta mucho la versión de Google, que se puede implementar a mano, pero  siempre es más sencillo si te lo deja el plugin. Algunos plugins como Contact Form 7 se pueden integrar con reCaptcha. Captcha Code. Uno muy simple (con pocas opciones) para el que no quiera líos. Conditional Captcha. Un módulo “inteligente” que mira primero si la persona tiene un comentario aprobado, o según la puntuación de Askimet, y decide si presentar el Captcha o no. Math Captcha. Otra versión a probar.  

En ocasiones WordPress, y realmente todos los gestores de contenidos, tendrá un error que no produzca nada en pantalla. Sólo obtendrás una pantalla blanca. Puede ser al instalarlo, al ejecutarlo o al actualizarlo. En esas ocasiones debes poner WordPress en modo debug. Os lo hemos explicado antes para Prestashop , para Vtiger, y para Moodle. Con el módulo debug (desarrollador), aparecerán en pantalla errores que pueden darte una pista para encontrar el posible origen del error. Así puedes saber qué hacer para solucionarlo. Para poner WordPress en modo debug tienes que seguir los siguientes pasos: Tienes que acceder a los ficheros de tu web. Lo más común es por FTP, si no por ssh. Encuentra el fichero wp-config.php y ábrelo para editar. Tienes que encontrar la línea que pone define( ‘WP_DEBUG’, false ); Cambia la línea a (si no estaba por algún sentido añádela): define( ‘WP_DEBUG’, true ); Ahora refresca la página. Verás que aparecen errores en la página. Usa el buscador del blog y Google para encontrar la posible solución a ese error. Cuidado porque un mismo error puede ser debido a varias causas, todo lo que pruebes (y no te queda más remedio que probar) que puedas deshacerlo. Recuerda, una vez arreglado el problema, desactivar el modo debug poniendo la línea como estaba originalmente (en false). Más información aquí.