Ya sea usando un plugin o mediante código.

¿Por qué bloquear por país?

Una de las razones más importantes para bloquear países es para evitar ataques de bots.

Los bots intentan abusar de vulnerabilidades. Buscan por software que no ha sido actualizado. Buscan de cualquier agujero que exista para poder tomar control de un sitio web. Por lo cual bloquear ciertos países puede ayudar a mejorar la seguridad.

Pero a la vez, también se puede bloquear por país debido a cuestiones legales. O simplemente por que no queremos que nadie de dicho país pueda acceder a ciertos recursos, como la zona de administración de WordPress.

Todas estas son razones válidas. Pero, ¿cómo lo podemos lograr?

1. Mediante un plugin

Una de las formas mas sencillas de bloquear por país en WordPress es usando una solución ya desarrollada como un plugin.

Existen multiples soluciones como iQ Block Country o IP2Location Country Blocker. En ambos casos, usan bases de datos que provienen de servicios y que hay que descargar.

Con ambas soluciones, solo necesitas obtener una cuenta en los servicios que usan y descargar la base de datos apropiada. O en su defecto pagar para acceder a los servicios en línea.

Ambos son muy útiles si no existe inconveniente económico. O si no se desea hacer muchos cambios.

Sin embargo, existen otras formas de bloquear por país en WordPress.

2. Con un CDN como Cloudflare

Si el sitio web en WordPress se encuentra detrás de un CDN como CloudFlare, puedes fácilmente limitar el acceso a ciertos países solo agregando un pequeño código al archivo functions.php que usa tu tema o con un plugin a medida.

Así, por ejemplo, se puede usar esa característica usando el siguiente código:

Con ese pequeño código, se bloquearán todos los clientes que visiten páginas dinámicas y que sean de los países en la lista «negra».

Algo muy importante que hay que indicar, es que las soluciones de plugins o de código como el mostrado no funcionarán siempre si hay un plugin de cache activado.

Esto se debe a que los plugins de cache, en la mayoría de los casos, crean páginas estáticas para enviar en vez de las páginas dinámicas.

Debido a esto, el código no se ejecutará. Pero si ese mismo usuario intenta acceder a la página de login, entonces sí será bloqueado.

3. Mediante una consulta a AbuseIPDB

En una entrada anterior hablé de como agregar la lista negra de AbuseIPDB a un servidor. Pero dicho servicio ofrece mucho más que solo la lista negra.

Cuando se consulta una dirección IP a su check endpoint, nosotros obtenemos toda una serie de información del cliente.

Esta información incluye datos como país de origen e incluso una calificación de cual probable es que trate de abusar de algún recurso.

Toda esta información es útil para evitar ataques o incluso fraudes para las tiendas en línea.

Así, con el siguiente script, nosotros podemos bloquear a un visitante tanto por su país como por su puntuación (si esta es mayor a 50):

Igualmente, para evitar realizar consultas de forma constante, guarda los resultados en un transient de WordPress. Así le generamos la menor molestia a los usuarios legitimos.

Pero, como se menciono antes, esto solo funciona en las páginas dinámicas. Aquellas que se encuentran servidas por el caché aún pueden ser visitadas por personas de los países bloqueados.

4. Bloquear por país usando la base de datos de GeoIP2

MaxMind ofrece la base de datos GeoIP2 Lite de forma gratuita. La cual se puede descargar desde su sitio web con tan solo registrarse.

Igualmente, ellos proporcionan un paquete con el cual se puede acceder a su base de datos usando PHP. Con la cual se vuelve muy sencillo el acceder a los datos.

Solo hace falta descargar el archivo phar o usar composer para agregar el proyecto a un plugin. Tras lo cual se puede agregar y usar de la siguiente manera:

De esta forma, estaríamos usando entonces ya usando la base de datos para bloquear a los visitantes de los países deseados.

Plugin de WordPress con GeoIP2

He desarrollado un plugin sencillo, el cual usa la base de datos de GeoIP2 para bloquear a los visitantes de los países seleccionados:

Su uso es extremadamente sencillo y viene tanto en español (España y México) como en ingles.

Para usarlo, solo hace falta instalarlo e ir a Herramientas > Bloquear por país. Solo debes de tener cuidado de no seleccionar el país en el cual te encuentras, o el sistema podría evitar que ingreses.

En caso de encuentres algún problema, puedes ponerte conmigo en contacto.

Conclusiones sobre como bloquear por país

Bloquear por país a un visitantes es relativamente sencillo. Aunque se necesita de herramientas adicionales para poder obtener la información necesaria para hacerlo.

La dirección IP por si misma no aporta esa información. Pero es fácil obtener detalles adicionales si se cuenta con los recursos necesarios.

Hoy en día prácticamente todo está a un API o Base de Datos de distancia.

The post [Guía] 4 formas de bloquear por país en WordPress appeared first on Endless Manifesto.

Hoy en día, ¿Quién no usa usa las herramientas que Google ofrece? Por eso le hecho un vistazo.

¿Qué es Google Site Kit?

Se trata básicamente de un plugin de WordPress, pero desarrollado por la propia Google con la cual implementa sus servicios.

De esta forma, puedes tener fácilmente en un solo lugar los datos de la Search Console, Google Analytics, PageSpeed Insights, AdSense y demás servicios.

En pocas palabras, en una solución robusta. Aún si no llegas a usar todo su potencial.

Veamos un poco de lo que nos ofrece.

Lo destacable del plugin de WordPress

Una de las grandes ventajas, que no está de más decirlo, es que trae toda la información que tiene Google hasta el Escritorio de WordPress.

Con este, es muy fácil el visualizar la información que se genera por la Search Console y Analytics de una forma condensada y fácil de entender.

Si bien no cuenta con todo el poder de dichas plataformas, nos permite ver los detalles más importantes.

Por ejemplo, en el panel principal del plugin, esta es la forma en la cual vemos como adquirimos tráfico:

Pero en esa misma página vemos inmediatamente como se está desempeñando el mismo sitio web en el buscador:

Es de esta forma que podemos obtener una imagen más clara del desempeño de un sitio web. Pero no es todo.

Ya que en la misma página principal podemos ver incluso cuales son las páginas más visitadas y las palabras clave más importantes que se usan para encontrarnos.

Junto a toda esa información, el plugin también nos permite ver información crucial para cada página o entrada.

Cuando vemos la entrada de forma individual, podemos encontrar una G en la parte superior y es que nos muestra lo siguiente:

Pero cuando hacemos clic en More details, es cuando las cosas se vuelven realmente interesantes. Ya que podemos ver la forma en la cual las personas encuentran dicha entrada.

Sobre todo, que palabras clave usan en especial. Ello permite saber, junto con otras herramientas como Yoast SEO, el saber si la estrategia está funcionando de forma correcta para una página en especifico.

Y eso es solo la superficie de lo que nos ofrece este plugin.

Lo menos atractivo del plugin

En lo personal, una de las cosas que no me han gustado mucho del Google Site Kit es la forma en la cual integra PageSpeed Insights.

Si bien tenemos un vistazo del desempeño del sitio web en la página principal del plugin, el mismo no nos da un reporte para cada página individual del sitio.

Solamente podemos ver el reporte de velocidad para la página principal.

Nunca he sido un gran fan de este servicio, pero siento que es una oportunidad desperdiciada el solo mostrar el reporte para la página principal.

Obviamente nosotros podemos, en todo caso, usar un enlace directo a cada entrada o página y hacer la prueba directamente. ¿Pero no sería mejor tenerlo ya listo en un solo lugar?

Otro los detalles que encontré es que no es fácil desconectar algunos servicios incluidos. La única opción en esos casos es desconectar todo.

¿No quieres que se hagan pruebas de PageSpeed una vez activado? Mala suerte, el plugin no te permite desactivar la opción.

Lo cual, invariablemente, puede significar que verás un incremento de visitas a tu página de inicio por parte de Google.

Nada más que si se puede desconectar de forma individual a AdSense y Analytics, por lo menos.

Tampoco hay forma de configurar muchas opciones desde WordPress. Aunque en parte se entiende, ya que la mayoría de las opciones las controla directamente Google.

Problemas al conectar Google Site Kit con AdSense

Otro de los detalles que me llamó la atención es que, cuando quieres conectar Adsenses al Site Kit, a veces suceden problemas con este.

Por ejemplo, al momento de conectar el servicio, a veces veremos algo como lo siguiente:

Esto, a pesar de ya contar con una cuenta creada.

Una pequeña investigación reveló que este es de hecho un problema del lado de Google. Esto debido a que su propia API regresa un error y esto impide que se puedan obtener las cuentas.

Además hay que comentar que más de uno ha tenido este problema. Esto a pesar de que indican de que ya está resuelto.

Es posible que, debido a que se verifican las cuentas de AdSense de forma constante, la propia cuenta asignada para esto simplemente se vea saturada.

Tras varios intentos, finalmente me mostró lo siguiente:

Con lo cual ya sabemos que ha identificado la cuenta y es cuestión de tiempo para que sea validada.

Sin embargo, hay que tener en cuenta que es posible que nos siga mostrando el error en otro momento. Ya que, como mencione antes, se consulta la API de Google de forma constante.

Solo es cuestión de tener paciencia.

Conclusiones sobre Google Site Kit

Hay una cosa que es cierta, este plugin de Google es lo que muchas personas querían ver. El poder tener acceso a datos importantes de forma fácil.

Si bien el mismo apenas acaba de salir de su fase beta, es evidente que se encuentra prácticamente listo en sus funcionalidades básicas.

En lo poco que he podido usarlo, he quedado más que satisfecho. Y en el futuro se espera que la gente de Google agregue nuevas funcionalidades.

Podemos seguir el desarrollo del plugin directamente GitHub. En donde se menciona esto y podemos ver incluso la solución de problemas que aún tiene el software.

Personalmente, tras lo que me sucedió con tumblr, estoy más que contento del poder contar con esta herramienta. Para saber, aún más rápido, de que es lo que sucede con un sitio web.

Y, por lo menos para mi, este se volverá en un plugin imprescindible. Y posiblemente para muchos más.

The post [Review] Plugin Google Site Kit: Esencial para WordPress appeared first on Endless Manifesto.

Ampliar las funcionalidades de WordPress es realmente sencillo. Como todo framework, aprender como extenderlo puede ser intimidante. Pero una vez que se entiende su funcionamiento, todo se abre paso.

Entonces, desarrollar plugins o extender temas en WordPress se vuelve mucho más fácil.

Extender WordPress: Los filtros y acciones son tus amigos

La forma en la cual nosotros podemos agregar nuevas funcionalidades a WordPress es, normalmente, usando los llamados filtros y acciones.

Estos también son llamados hooks, o ganchos en español.

Los filtros y las acciones son, en esencia, lo mismo. Pero cambian en un aspecto fundamental: Que los filtros regresan datos y que las acciones nos permiten alterar el comportamiento.

Cada uno de estos hooks posee un nombre único, el cual describe de forma general en donde se encuentra, en que momento se ejecuta o el tipo de datos los cuales puedes cambiar.

Para poder usar un filtro o acción, nosotros debemos primero pegarnos a dicho hook. Esto se logra usando las funciones add_filter o add_action de WordPress.

Debemos usar add_filter si nos vamos a adjuntar a un filtro y add_action si se trata de una acción.

Con esas funciones, nosotros podemos declarar a cual hook queremos unirnos y cual será el código que queremos que se ejecute.

Esta es la forma en la cual lo hacemos:

En este ejemplo, adjuntamos una función a los filtros script_loader_src y style_loader_src. Cuando estos filtros se ejecuten, van a pasar un valor que tomará la función como la variable $cadena. La cual a su vez regresará un valor ya modificado.

De esta forma, podemos hacer prácticamente cualquier cosa con los datos que reciba nuestro código.

Hay que recordar que un filtro normalmente espera que se regrese algún dato. Por lo cual, de no hacerlo, es posible que suceda un comportamiento no esperado.

¿Que hay de las acciones?

En el caso de las acciones, las cosas son un poco diferentes.

Normalmente, las acciones se usan para agregar un comportamiento dentro de WordPress o un plugin.

Las acciones normalmente las usamos para imprimir HTML, agregar estilos o javascript, agregar páginas administrativas, entre otras tareas que no requieran regresar datos.

Un ejemplo de esto es la acción wp_enqueue_scripts, con la cual normalmente se agrega todo el Javascript y el CSS que se usará en el Front-end.

Pero incluso podemos ir más allá al extender WordPress.

Por ejemplo, podemos usar la acción admin_menu para crear páginas nuevas dentro del back-end de WordPress con la función add_submenu_page.

¿Qué hay de las funciones anonimas y clases?

Normalmente el código que nosotros adjuntaremos a los filtros o acciones, para extender WordPress, estarán dentro de una función.

Lo que normalmente implica que se deberá de crear una función dedicada totalmente a dicho filtro o acción. Misma que estará disponible para el resto de la aplicación.

Una forma de solucionar esto es declarando la función de callback de manera anónima al momento de pegarnos al filtro o acción.

Por ejemplo, podemos hacer lo siguiente:

De esta forma, la función estará solamente disponible para el filtro la cual la invocó.

Sin embargo, esto también implica que nuestro código se vuelve poco flexible.

Por ejemplo, una ventaja de usar el método tradicional, es que podemos usar remove_filter para quitar código que ya este adjuntado. Algo que no es posible con las funciones anónimas.

En el caso de las clases, nosotros debemos de dedicar el método __construct para definir las acciones y filtros que usaremos.

Recordando que, al momento de agregar los filtros o acciones, deberemos referenciar la propia clase:

Extiende tus temas o plugins con filtros y acciones

Los filtros y las acciones no son exclusivas del núcleo principal de WordPress, si no que estos pueden ser implementados tanto en temas como en plugins.

Con esas definiciones, nosotros podemos saber que datos podemos cambiar de otro software desarrollado para WordPress.

Incluso podemos indicarle a otros programadores donde pueden adjuntar funciones para extender la funcionalidad de nuestro software.

Por ejemplo, para agregar un filtro a un tema o plugin, solo hace falta agregar algo como esto:

En este caso se creo un filtro de nombre filtrar_valor con apply_filters al cual se pueden adjuntar otras piezas de software usando la función add_filter.

Debido a que se trata de un filtro, debemos asegurarnos de que el resultado sea asignado a una variable. Preferentemente la propia variable filtrada.

Pero eso cambia cuando se usa la función do_action, con la cual definimos acciones. En ese caso no hace falta asignar ningún valor.

Extender WordPress y plugins: Encuentra esos filtros y acciones

Otra de las cosas que puedes hacer con las funciones apply_filters y do_action es el encontrar donde podemos extender el software.

¿Quieres cambiar algo de un plugin pero no sabes donde se puede? ¿Quieres hacer algo pero solo se te ocurre el modificar el original?

La solución está en buscar por las funciones apply_filters y do_action en el código fuente.

Muchos desarrolladores agregan filtros y acciones a sus plugins o temas para permitirle a otros hacer más. Un buen ejemplo de esto es el caso que tuve con Swift Performance.

No siempre encontrarás documentación sobre estos hooks, pero ver la función en el contexto de la aplicación te ayudará a entender que es lo que sucede.

A veces, solo hace falta encontrar el hook correcto en el código para hacer las cosas.

Aprende a usar las prioridades y argumentos

Otra de las claves para extender WordPress correctamente es el saber en que momento debemos de ejecutar nuestro código.

Tanto add_filter como add_action tienen un parámetro de prioridad, el cual es muy importante para definir correctamente el orden de ejecución.

La prioridad está representada en un número, el cual mientras sea más bajo, más tarde se ejecutará el código que queremos. El default es 10.

Esta prioridad es de gran ayuda en casos en los cuales queremos hacer algo antes que los demás plugins, por ejemplo.

Con una prioridad de 5, podríamos entonces cargar nuestros scripts con la acción wp_enqueue_scripts antes de que otras librerías lo hagan.

Pero con una prioridad de 999, nos aseguramos de que todo lo demás ya haya terminado. Por si queremos filtrar los datos que otro plugin cambió, o asegurarnos de que una dependencia ya exista.

Finalmente, el último parametro de add_filter o add_action nos permite definir hasta cuantos parametros de entrada vamos a aceptar desde el filtro o acción.

Normalmente solo se pasa un parametro. Pero en algunas ocaciones, se pasan más datos desde las funciones apply_filters o do_action.

Cuando es así, y queremos usar esos datos, podemos indicarle a WordPress que queremos esos datos:

Para cerrar

Como se puede apreciar, el extender WordPress es ralmente sencillo. En especial cuando aprendes a usar y encontrar los puntos en los cuales puedes adjuntar tu propio código.

Personalmente, las acciones son las que más oportunidades ofrecen a la hora de personalizar las funciones. En especial por que se disparan en momentos clave.

Sin embargo, nosotros podemos personalizar practicamente todo. Solo hace falta ver la lista de acciones y de filtros disponibles en WordPress.

Solo es cuestión de invertir suficiente tiempo en leer el suficiente código e ir probando cual filtro o acción se ajusta alo que necesitamos.

The post Filtros y acciones: Como extender WordPress appeared first on Endless Manifesto.

Recientemente escribí sobre la migración que realice de W3 Total Cache a WP Super Cache. En el cual explique algunos problemas que tuve con W3 Total Cache.

Sin embargo, la solución de WP Super Cache + Autoptimize no me tenia del todo contento. Las cosas se podían mejorar. En especial, el rendimiento de ambos plugins. Ya que no era de mi completo agrado.

Es ahí que escuche de Swift Performance Lite y decidí probarlo.

Instalando y probando Swift Performance

Tras instalar Swift Performance Lite, una de las cosas que debemos de hacer primero es el ejecutar su Wizard de instalación.

La gran ventaja es que prácticamente todo esta automatizado. El plugin detecta correctamente muchas de las opciones del entorno. Además de que mostrará cualquier problema que tenga el servidor.

Con lo cual sabemos que debemos cambiar o instalar para mejorar el desempeño en general.

En el Wizard de Instalación podemos incluso elegir muchas de las opciones más importantes. Como la forma en la cual controlaremos cuando se expira el cache. O si queremos incluso purgar el cache de Cloudflare, si usamos esa solución.

Además incluye un minificador de código Javascript y CSS. Que si bien ya no es tan extremadamente necesario, siempre es bueno tener esas opciones.

Con la configuración detectada por Swift Performance Lite, se tiene una base sólida sobre la cual trabajar.

Dependiendo de las condiciones de tu servidor, el desempeño se puede sentir incluso mejor que con W3 Total Cache o WP Super Cache.

Personalmente, he encontrado que el desempeño puede ser mejor que con los plugins antes mencionados.

Afinando Swift Performance Lite

Sin embargo, en algunos casos, se necesita de realizar algunos cambios a la configuración. En especial si usamos software adicional o si observamos comportamientos erráticos.

En mi caso, me gusta combinar Javascript y CSS externo. Con lo cual están disponibles aunque el medio original tenga problemas.

Para activarlo, debemos de ir a Settings » Optimization » Scripts y asegurarnos de la opción de Exclude 3rd Party Scripts este desactivada.

Ahí mismo, debemos de indicarle a Swift Performance que recursos queremos omitir a la hora de combinar scripts. En mi caso, declaro los siguientes:

Como se puede ver, es relativamente sencillo el decirle que recursos no se han de combinar. Esto es realmente útil si encontramos problemas o si el cache crece demasiado rápido.

Otra de las opciones que ofrece Swift Performance es la posibilidad de usar el Lazyload de imágenes. Esta característica se encuentra bajo Settings » Media » Images.

Ahí podemos decidir si queremos usar esta opción y que condiciones causarán que se cargue la imagen completa.

Páginas 404, Archivos y Autores: ¿Agregarlas al Cache?

Otra de las opciones que permite Swift Performance Lite es la posibilidad de almacenar en el cache las páginas de error HTTP 404 (no encontrado), las páginas de los archivos o de los perfiles.

Si bien el guardar en cache estás páginas suena tentador, es algo que se debe de analizar profundamente.

Personalmente decidí no permitir que se agreguen estas páginas al cache, ya que pueden interferir con las re-direcciones o registros de apache.

Sin embargo, puedes encontrar esta opción en Settings » Caching » General.

Igualmente Swift Performance nos permite decidir si queremos guardar en el cache ciertas páginas como son end-points del REST API, Feeds, etc.

En Settings » Caching » Exceptions encontrarás estas opciones.

Si consideras que te será útil, puedes desactivar los casilleros. Pero personalmente he encontrado que pueden generar que el tamaño del cache crezca mucho.

Dependerá de cada caso si se ha de activar o no.

Otras opciones de Swift Performance Lite

Además de encargarse del cache, Swift Performance también nos permite realizar otras tareas. Como lo es el realizar un mantenimiento a nuestra Base de Datos de WordPress.

Si bien el tipo de herramientas que ofrece son básicas, como es Reindexar u Optimizar la Base de Datos, Eliminar Transients, Revisiones, Comentarios o Usuarios; estas son generalmente las que más se usarán para obtener una pequeña mejora en el desempeño. Especialmente notorio si la Base de Datos es grande.

Una opción, relacionada al mantenimiento, que es realmente bienvenida y que nos ahorra el tener que depender de otra herramienta adicional.

Finalmente, otra de las opciones adicionales en Swift Performante Lite, es la del Plugin Organizer.

Con esta, nosotros podemos indicar en que circunstancias se deben de desactivar ciertos plugins. Ya sea si se visita una página en especifico, si el usuario actual tiene un determinado nivel, si se está ejecutando en contexto AJAX, etc.

Esta opción, si es configurada correctamente, puede ayudar a mejorar el rendimiento del sitio web en ciertos escenarios. En especial es útil si se quieren optimizar los recursos en un entorno limitado o con alta demanda.

Problemas con Swift Performance Lite

Por desgracia, no todo es miel sobre hojuelas. Algo que en verdad ha de esperarse cuando se prueba un plugin nuevo.

Sin embargo estos problemas pueden ser solucionados relativamente fácil, ya que solo hace falta aplicar pequeños parches de código. He visto buen potencial en este plugin que he decidido seguir adelante con este a pesar de esos pequeños detalles.

Esto son algunos de los problemas que he encontrado y como puedes solucionarlos:

1. Swift Performance guarda en cache páginas de error

Si tienes soluciones de seguridad para WordPress como Wordfence, es muy posible que en algunos escenarios te encuentres con problemas si usas Swift Performance Lite.

Además de Wordfence, yo también cuento con soluciones de seguridad adicionales creadas a medida.

En ambos casos, observe que los errores 503 de Wordfence y los 403 de mi solución eran guardados en el cache de Swift Performance Lite.

Peor aún, las páginas de error generadas y guardadas en el cache le eran mostradas a los visitantes como si fuera la correcta.

En casos como este, normalmente buscarías los códigos de error en el Log de Apache. Pero estos no aparecian por ningún lado. Resulto que estaban en el registro con códigos HTTP 200.

Eventualmente encontré el origen del problema en Swift Performance y tras revisar su código también la forma de solucionar ese tipo de problemas:

En este ejemplo, usamos el filtro swift_performance_is_cacheable junto con la función http_response_code para obtener el estado actual de la petición y saber si se debe de permitir que se almacene en el cache.

En este caso, use una lista predeterminada de códigos de error típicos, pero se puede comparar solamente contra el código HTTP 200:

Sin embargo, en este caso en especifico, se requerirá realizar pruebas para saber si genera los resultados deseados.

2. Swift Performance agrega páginas inesperadas al warmup

Otro mal hábito de Swift Performance Lite es el hecho de que agrega a su tabla de warmup recursos como el robots.txt e incluso end-points del REST API, sitemaps, entre otros.

Además, cuando algún bot intenta acceder a un recurso vulnerable, también se agrega esa página a la tabla de warmup de Swift. Esto si se regresó un error diferente al de no encontrado.

Si queremos evitar que Swift haga esto, podemos definir que clase de urls se deben de excluir desde el back-end de WordPress.

Pero también lo podemos hacer usando un poco de código:

En este caso, se usó de nueva cuenta el filtro swift_performance_is_cacheable para filtrar si Swift Performance deberá de guardar la página en el cache.

Entonces se compara la variable $_SERVER['REQUEST_URI'] contra un array pre-definido.

La ventaja de este método es que la lista no puede ser modificada desde el plugin, con lo cual prevenimos que la lista sea eliminada si se restauran los valores por defecto de Swift Performance.

Otra alternativa a esta solución es el usar la propiedad $wp->request que ofrece WordPress. Sin embargo, esto solo funcionará en el front-end.

Una limitación que puede ser problemática, en especial si queremos filtrar resultados que incluyan páginas del back-end.

Finalmente, también puedes obtener el valor original usando  filter_input(INPUT_SERVER, 'REQUEST_URI'). En especial si sospechas que otro plugin manipula esta variable global.

3. No se eliminan algunos de los archivos del Cache de Swift Performance Lite

Otro de los problemas de Swift Performance, e incluso de W3 Total Cache, es que una vez que ha expirado un elemento del cache, este no siempre se elimina.

Estos archivos pueden permanecer guardados ahí por tiempo indefinido.

Si tenemos muchos visitantes o múltiples páginas, esto puede hacer que el cache crezca muy rápido a un tamaño excesivo.

En este caso, el cache llego a ser de casi 2GB. Lo cual claramente muestra un problema por que solo se tienen 79 páginas en la tabla de warmup.

¿De donde ha salido todo los demás?

Una solución rápida es simplemente limpiar el cache manualmente a intervalos regulares. Pero puede ser tedioso después de un tiempo o si se tienen múltiples sitios web que administrar.

Una solución más práctica es el definir un Cron Job de WordPress y que este haga el trabajo por nosotros:

En este caso, se están usando las propias clases de Swift Performance para saber el tamaño actual del cache, calcular cual debería de ser su tamaño y eventualmente limpiarlo si es necesario.

Adicionalmente, también se puede limpiar el cache una vez al día. En ese caso, se define un cron job el cual solamente haría lo siguiente:

Hay que tener en mente que, debido a que es un trabajo cron de WordPress, es posible que no siempre se ejecute. Esto en especial en sitios web con poco tráfico.

Para esos casos, es posible el crear un script especial y agregarlo a los trabajos cron del servidor. Pero ello está un poco más allá del alcance de esta entrada.

4. Multiples Hosts en el cache de Swift Performance Lite

Cuando se cuenta con una instalación de multisitios, es de esperarse que un plugin como Swift genere una carpeta por cada dominio que sirve contenido desde una instalación en especifico de WordPress.

Sin embargo, a veces esto también sucede con las instalaciones regulares, bajo ciertas condiciones.

Por ejemplo, si cuentas con una instalación de WordPress en un VPS y Apache ha definido a ese servidor virtual como el principal… entonces es posible que te encuentres con una sorpresa.

Swift Performance crea una carpeta en su directorio de cache por cada dominio que accede a la instalación en donde esta presente. Pero cada una de esas carpetas solo se puede acceder desde el dominio que la creo.

Así, si cuentas con una instalación que se puede acceder desde www.ejemplo.com, ejemplo.com y una IP como 123.456.789.012, entonces terminarás con 3 carpetas.

Pero para limpiar el cache generado para 123.456.789.012, deberás de ingresar directamente en esa dirección. No puedes limpiar ese cache desde www.ejemplo.com. Pero tampoco la de ejemplo.com.

Sin embargo, puedes mostrarle a Swift cuales son los hosts y carpetas que puede ver haciendo uso del filtro swift_performance_enabled_hosts:

En este caso, nosotros obtuvimos todas las carpetas en root del cache de Swift Performance y los regresamos como si fueran nombres de dominio.

De esta forma, el cache generado para otros dominios se puede ver, administrar y purgar desde el back-end.

Hay que tener en cuenta, por supuesto, que en el caso de las instalaciones multisitio; esta solución puede generar problemas. Por lo cual pudiera necesitar validaciones adicionales.

5. Problemas cuando se corre WP-CLI con Swift Performance

Una de las herramientas más importantes para administrar WordPress, desde la línea de comandos, es la de WP-CLI.

Con ella podemos hacer una infinidad de tareas para administrar las instalaciones  el software. Sin embargo, Swift Performance parece emitir ciertas advertencias cuando es ejecutado en este tipo de entorno.

Por ejemplo, emite un error cuando intenta usar el indice HTTP_HOST. El cual no se define en contexto de línea de comandos.

Por lo cual, para evitar algunos problemas, o que la salida de la consola pierda formato; siempre es bueno desactivarlo con el siguiente parámetro:

wp plugin list --skip-plugins=swift-performance-lite

Solo con el agregar la opción --skip-plugins, se puede corregir el pequeño problema. Ya que si no se ejecuta Swift Performance Lite en el entorno CLI, entonces este no tratará de optimizar esas salidas.

Conclusiones sobre Swift Performance Lite

Si bien, como cualquier plugin nuevo, todavía tiene mucho que mejorar; Swift Performance me ha dejado sorprendido en muchas áreas.

Por ejemplo, este es uno de los resultados que he obtenido usando este plugin como solución de cache:

Para nada despreciable. Incluso ya por debajo de un segundo de carga. Algo que invariablemente buscaba lograr, pero me era algo elusivo con otras soluciones.

Claro, siempre ayuda mucho el contar con un servidor optimizado.

Vale la pena el tomarse el tiempo probar este plugin, el cual ofrece buenos beneficios por default. Aunque obtienes mucho más de este una vez sabes donde tienes que apuntalar.

¿Ustedes que opinan al respecto?

The post Swift Performance Lite: Acelera tu Sitio Web appeared first on Endless Manifesto.

Antes de continuar, es importante notar que esta entrada la escribo directamente en Gutenberg. Y que no es la primera vez que escribo sobre este editor.

Sin embargo, esta vez se encuentra mucho más maduro. Aunque todavía le hace falta mucho.

Gutenberg: Impresiones de la última versión

Con relación a lo ultimo que había probado. El cambio es muy significativo.

En especial a lo que respecta a los bloques. A la forma tan natural en la cual se les puede editar, manipular o crear. De todas las posibilidades.

Se siente como un editor visual, pero mucho más ligero. Ofreciendo un set de opciones base para poder crear entradas y páginas visualmente ricas.

Por supuesto, no remplaza a los constructores visuales más completos como DIVI o Visual Composer. Aunque se vuelve una alternativa y comparte algunas cosas de estos.

Por ejemplo, puedes crear bloques reusables e incluso clonarlos. Estas son algunas funcionalidades básicas que es bueno ver en Gutenberg.

Lo cual facilitará la creación.

Lo mejor de todo está en que podemos ver como será nuestro contenido mientras editamos. No hay necesidad usar el botón de Preview constantemente.

Casi no hay diferencias entre lo que vemos y obtenemos. Esto permite enfocarnos más en escribir y menos en solucionar problemas.

Detalles a mejorar en Gutenberg

Sin embargo, no todo es miel sobre hojuelas con el nuevo editor.

Una cosa es muy obvia, y es que cuenta todavía con mucho camino por recorrer para poder remplazar definitivamente a TinyMCE como el editor por defecto.

Por ejemplo, a veces el comportamiento es un poco errático al tratar de agrear bloques. Ya que no aparece el símbolo de «+» en donde debería.

Hay que entender que para agregar un bloque hay que presionar enter al final de un párrafo. O usar un botón que está en la parte superior izquierda.

Pero a veces uno no quiere terminar un bloque de forma arbitraria.

Otros problemas surgen de la integración de otros proyectos, como lo es el Visual Composer. El cual, al menos en los sitios que manejo, muestra los shortcodes en vez del editor.

No hay forma de editar los contenidos cuando Gutenberg está activo, ya que hasta el editor Front-End no funciona de forma adecuada. Puede ser un problema del propio Visual Composer, pero es un ejemplo de lo que puede pasar con otras piezas de software.

DIVI no parece estar tan afectado, ya que muestra una advertencia al querer editar contenido mediante el nuevo editor. Y hay otros como Elementor, Beaver Builder o Page Origin que quizá pruebe después.

Otro problema está a la hora de agregar imágenes.

Por ejemplo, no podemos seleccionar que tamaño queremos que tenga la imagen. Antes podíamos seleccionar un thumbnail, la imagen completa, o otra opción generada por el tema. Eso no está presente cuando se agregan imágenes desde la librería.

Detalles con las entradas y sus datos

Más problemas están a la hora de tratar de cambiar más datos de las entradas. En mi caso, estoy acostumbrado a crear entradas y cambiarles el autor antes de publicar.

Eso no está disponible en Gutenberg. Al menos no por el momento. Ya que tampoco parece estar disponible en algún lado en el editor. Ni se puede activar.

Como sucede con el editor clásico.

Todos son pequeños detalles que muestran que todavía hay camino por recorrer. Que el software no está del todo listo.

Conclusiones sobre Gutenberg

Personalmente, yo creo que el editor tiene mucho potencial.

La experiencia de escribir ha sido placentera. Se siente fluido y en general bastante intuitivo. Mucho más moderno a la hora de generar contenido.

Tiene el potencial de hacer del escribir toda una experiencia. Pero no es un software que esta listo para la mayoría de los sitios web.

Aunque posiblemente para la próxima versión grande de WordPress, ya este listo.

Yo nunca he sido muy fan del editor TinyMCE y de lo rígido que puede ser con el contenido y el HTML. Poder usar un editor liviano para agregar HTML fácilmente y poder moverlo es un gran plus.

Quienes usamos más los elementos de este tipo, lograremos más. Pero como mencione, no es para todos. Ni todos están listos para Gutenberg.

Solo el tiempo dirá si ha sido una buena idea. Pero en especial espero que así sea.

Pero en lo que WordPress 5.0 llega, dale una oportunidad a Gutenberg.

The post Gutenberg: Opinión del nuevo editor de WordPress appeared first on Endless Manifesto.

Estas son mis razones.

Anteriormente había hablado de W3 Total Cache. De como me estaba ayudando mucho mejorando el sitio web.

Debo de admitir que este plugin era prácticamente mi favorito para realizar la tarea de caching. Algo importante si realmente quieres tener un sitio web rápido, además de que me ahorraba tiempo de procesador.

Sin embargo, recientemente comencé a notar problemas. Mismos que me hicieron mirar a WP Super Cache de nueva cuenta.

Errores en todas partes con W3 Total Cache

Una de las cosas que más me agradaban de este plugin de WordPress, es que podía configurarse de acuerdo a mis necesidades. El gran número de opciones abría grandes posibilidades de optimizaciones. De mejoras puntuales de acuerdo a mis necesidades.

Sin embargo, siempre hay cosas que salen mal. Y eso es en verdad cierto con software complejo.

El primer síntoma estuvo en las entradas programadas. Comencé a notar que estas arrojaban el error missed schedule con frecuencia. Molesto, pero nada más que eso… e incluso errores esporádicos que parecían no tener sentido.

Todas las soluciones en la web indicaban que debía de instalar algún plugin.

No. No lo iba a hacer. No tenia sentido que algo así sucediera, ya que el servidor no tenia razón de estar comportándose de forma errática.

Tras investigar un poco, resultó que el Object Cache estaba causando problemas en mi back-end. Tras desactivar esa característica, los problemas cesaron… al menos temporalmente.

Las cosas se complican todavía más

El segundo gran problema sucedió con admin-ajax.php. Comencé a notar un número inusual de errores 403 sin una explicación clara.

Me arrojaba el error a mi, a visitantes al azar, e incluso a los bots de google. Esto último imperdonable.

Debido a que las instalaciones que manejo contienen más o menos los mismos plugins… detectar al culpable seria relativamente sencillo. Tras un análisis, solo se limitaba a W3 Total Cache o a uno de seguridad.

Para agravar más la situación, el problema de missed schedule había regresado.

Fue entonces que la opción de WP Super Cache se volvió mucho más viable.

Ya tenia experiencia con él y sabia que podía hacer el trabajo sin contratiempos.

WP Super Cache entra al relevo

A diferencia de W3 Total Cache, WP Super Cache tiene opciones muy minimalistas. No eres capaz de configurar absolutamente todo. Aunque no falla en su trabajo: Mejora el rendimiento del sitio web. Sin complicaciones.

Pero para tener una solución completa con WP Super Cache, se requiere de un aplicativo que haga minificación. Ahí es en donde entra Autoptimize. Esto para comprimir las hojas de estilo y los scripts de javascript.

Esto lo debemos de hacer si queremos mejorar aún más el rendimiento y experiencia del usuario.

Aunque si contamos con un servidor rápido, la ganancia puede ser marginal. Pero menos consultas por visita siempre es bueno. En especial si sumamos muchas visitas al día.

El modo experto de WP Super Cache

Si bien cuenta con muchas menos opciones, hay algunas cosas que si se pueden hacer. En especial en lo que respecta a activar el uso de reglas en el .htaccess. Esto permite que se pueda saltar parcialmente la ejecución de PHP en algunos casos.

Mientras menos veces se tenga que invocar a PHP, mejor.

Activando el modo experto, y asegurándose de activar los casilleros deseados, da un rendimiento que hace que no extrañe W3 Total Cache. Aunque lo único que no hace WP Super Cache es el asignar las cabeceras cache de Apache para los recursos estáticos.

Pero agregar ese tipo de cosas es trivial. Igualmente se puede agregar rápidamente las reglas que trae W3 Por defecto, dependiendo de las configuraciones.

Conclusiones sobre el regreso a WP Super Cache

Si bien soy fanático de tener una herramienta con cientos de opciones, es una pena que encontré que ella causaba más problemas que beneficios. Problemas que no parecían tener soluciones fáciles, o que hacían que no valiera la pena la solución.

Por lo cual el contar con una alternativa más sencilla fue la mejor idea.

Hay algunas cosas que todavía tengo que apuntalar, en especial del lado del servidor. Como son las cabeceras… aunque Cloudflare se encarga por mi de eso.

Pero establecerlas manualmente siempre será mejor para proporcionar una experiencia más uniforme.

Esperemos que no suceda nada inusual esta vez.

The post Adiós W3 Total Cache, Hola WP Super Cache appeared first on Endless Manifesto.

En pocas palabras, Cloudflare puede causar un ataque DDoS.

¿Qué sucede con Rocket Loader?

Rocket Loader es una característica en estado beta de Cloudflare. Su principal objetivo es mejorar la velocidad de un sitio web. Eso lo hace bien.

Sin embargo, recientemente he estado observando problemas con este.

Por ejemplo, cada vez que he enviado datos de formulario, he observado un número inusual de conexiones. Al principio pensé que se trataba de un ataque.

Pero mientras más busque, es que me fui percatando de que había un problema entre el plugin Wordfence y este servicio de Cloudflare.

¿Qué es lo que sucedía con WordFence?

Haciendo la historia corta, empece a ver que mis sitios web generaban errores y que el servidor en el cual estoy «colapsara». Al punto de que necesitaba el reiniciarlo a mano.

Algo que no debería de suceder.

Cuando finalmente comencé a ver los registros de apache, comencé a observar un alto número de llamados a un mismo URL con lo siguiente:

/?wordfence_lh=1&hid=...

Observé que se hacían estos llamados en oleadas de 20 a 50 conexiones por segundo. Algo que este servidor no podía aguantar.

Al menos no con la configuración presente.

Pero al estar indagando es que fui encontrando de que no era el único el cual estaba sufriendo de este problema de WordPress con Wordfence y Cloudflare.

¿Qué fue lo que pasó entre Rocket Loader y WordPress?

En un hilo de la comunidad de Cloudflare, se habla de cambios que se están haciendo a Rocket Loader.

Después de todo, se entiende debido a que es software en estado beta.

Sin embargo, en este caso esto significó problemas que causaron la caída de un servidor. Mientras no es grave, si implica que el riesgo existía todavía.

En su momento se menciono que el problema había sido resuelto. Eso era cierto, ya que desde la semana pasado no volví a ver el problema… hasta ayer.

¿Como soluciono la caída de WordPress por Rocket Loader?

La forma más sencilla de evitar este problema es desactivando por completo Rocket Loader. Como característica beta, no debería de ser usada indiscriminadamente.

Menos en entornos de producción.

La ventaja es que esta característica viene desactivada por defecto. Sin embargo, si la han activado por ti, puedes desactivarla así:

Ingresa a Cloudflare > Elige el Dominio > Speed > Rocket Loader

Ahí podrás apagar esta característica. De esta forma quizá ya no veas problemas en tu servidor.

Conclusiones sobre Rocket Loader

Cloudflare no me había dado grandes problemas desde que lo uso hace ya más de 5 años, si no es que más.

Sin embargo, esta característica, que promete mucho, me ha hecho tener que vigilar un poco mejor las opciones que tengo activadas en dicho servicio.

Todos queremos que nuestros sitios web sean rápidos… sin embargo, a veces eso nos hace el usar software en estado beta, como Rocket Loader, cuando no están listos para producción.

Yo ya sentí en carne propia algunos de sus problemas. Quizá la vuelva a activar cuando este más madura o con Page Rules.

Pero ya veremos.

Actualización sobre Rocket Loader

Recientemente volví a activar Rocket Loader tratar de obtener más datos sobre este problema. Y así poder reportarlo de forma correcta.

Y es que, tras mirar los registros del servidor, ya no encontré las referencias a Wordfence como antes. Pero a admin-ajax.php. Lo cual cambia un poco el panorama.

La última vez que sufrí el problema fue el pasado 27 de mayo.

Mi problema ahora es que no he podido duplicar este bug. No me ha vuelto a suceder. Es plausible de que necesite esperar un tiempo ante de poder reproducirlo. Aunque igualmente es plausible de que haya sido corregido correctamente.

Pero eso lo veremos en los próximos días.

The post Problemas con Rocket Loader de Cloudflare appeared first on Endless Manifesto.

Cambiar de servicio de hospedaje, para mi, era muy importante. Como parte de crecer y de aprendizaje. En especial por que tenia muy en claro lo que necesitaba. Además de que necesitaba mayor poder de procesamiento.

Es por ello que un VPS (Virtual Private Server) era la solución correcta. Pero es implicaba el ensuciarse las manos un poco. ¿Por qué? Porque en la mayoría de los casos, solo se nos entrega el esqueleto sobre el cual trabajaremos.

El resto de software corre por nuestra cuenta. Igual la seguridad. Es por ello que administrar un Servidor Privado no es para cualquiera. Tienes que saber exactamente lo que estás haciendo.

¿32bits o 64bits para Virtualmin?

Antes que nada, quiero decir que primero probé Virtualmin con Ubuntu 16.04 a 64bits en una VPS con 2GB. No lo hagan. En especial si van a instalar la suite completa.

¿Por qué? Bien, un sistema de 64bits solo se necesita si van a tener un servidor con 4GB de ram o más.

Si tienen uno de 3GB o menos, con una distribución de 32bits tienen más que suficiente. En especial en lo que respecta al uso de memoria.

Las aplicaciones de 64bits usan mucha más memoria. En mi caso, llegue a observar que tanto MySQL y Virtualmin competían por los recursos después de algunas horas. Esto causaba que se necesitara reiniciar el servidor cada que sucedía.

Esto a pesar de tratar de reducir la memoria al mínimo. De todas las aplicaciones.

De entrada, en un sistema 64bits, MySQL usa cerca de 1GB de ram (con el caché incluido). Claro, esto con varios programas y sitios instalados. Contra los 508MB con la misma configuración en un sistema 32bits.

Vaya que hay una diferencia notable. Incluso en los procesos de apache y php.

Igualmente, en el sitio oficial recomiendan 32bits para cuando hay memoria limitada. Cuando es 3GB o menos. Hay que hacer caso.

Instalación de Virtualmin y configuración

El panel lo puedes instalar tan fácilmente como ejecutar esto en la consola de un servidor nuevo:

# wget http://software.virtualmin.com/gpl/scripts/install.sh
# sudo /bin/sh install.sh

Por supuesto, nosotros podemos seleccionar entre otras opciones como instalar una configuración LEMP (nginx) en vez de LAMP (apache). O un servidor con características mínimas.

Pero el LAMP es mejor, en especial si necesitamos correr aplicaciones como WordPress. Aunque todavía, quizá en un futuro, pueda tener un proxy inverso con nginx y apache.

Pero ya veremos.

Regresando a la instalación. La misma es prácticamente automática. Como lo es la de VestaCP. Otro panel que pude probar. Pero a diferencia de Vesta, prácticamente todas las funcionalidades funcionaban out-of-the-box. Lo cual ahorra mucho más tiempo.

En cuanto a la configuración, hay poco que hacerle. Pero quizá lo más importante es el cambiar el modo por defecto de la ejecución delos scripts PHP por apache.

Por ejemplo, la configuración por defecto usa FCGId como modo de ejecución para PHP-FPM. Pero si instalas los paquetes necesarios, puedes usar el modo FPM. Aunque después de estar realizando muchas pruebas… tal parece que el modo por defecto, el FCGId, funciona sin comerse tanta memoria. Lo cual es una buena ventaja en servidores con poca memoria.

Se pueden hacer ajustes finos. Como los que se mencionan en esta página de Linode. Aunque no los he probado, hasta el momento el servidor que he montado ha soportado la carga.

Al menos ya no me muestra la multitud de errores 525, 503 y 520 de antes. Eso ya es ganancia. Junto con la velocidad general adquirida.

Conclusiones sobre Virtualmin y Digital Ocean

Si bien apenas llevo poco tiempo usando Virtualmin, este ha sido un panel que es realmente maravilloso para administrar un servidor. Te permite instalar servidor de correo con un cliente. Servidor LAMP, firewall, administrador de archivos, administrador de base de datos, entre otras cosas.

Esta muy completo.

Esto si, la curva de aprendizaje esta muy empinada. Uno puede tardarse mucho tiempo en conocer todo lo que puede hacer el panel.

No es muy amigable con el usuario. Pero eso no quita que sea muy poderosa.

Otra de las desventajas es que no cuenta con todas las opciones posibles en el frontend. Por lo cual muchas veces necesitarás editar los archivos directamente en el servidor desde la consola.

No es una queja, pero cuando te acostumbras… suele ser más rápido editar las configuraciones directamente en al consola. En vez de estarla buscando entre un mar de opciones.

Pero eso no quita el hecho de que sigo más que satisfecho y recomiendo este panel.

The post Virtualmin en Digital Ocean: Experiencias appeared first on Endless Manifesto.

Agregar un script debería de ser fácil. Y así es en la mayoría de los casos. Sin embargo hay ocasiones en las cuales los desarrolladores nunca tuvieron en mente WordPress u otro CMS.

Es por eso que a veces se requiere de saber que tan compatible es un código.

Por ejemplo, el siguiente es uno que alguien quería incluir en una instalación de WordPress:

Parece simple, ¿verdad?

Pero al menos hay un problema evidente: Se necesita de jQuery para poder hacerlo, eso nos dice la primera línea.

Antes de siquiera agregar este código, es importante el tener al menos una idea de lo que hace y sus necesidades. Podemos ver tutoriales en la Internet, pero sin tener una idea será difícil el encontrar una solución real.

Si no tenemos dicha noción, no podremos agregar scripts externos a WordPress de una forma rápida y eficiente.

Solucionando el problema de agregar scripts externos a WordPress

Existen muchas formas de agregar un script en WordPress, sin embargo para este ejemplo hay que tomar ciertas consideraciones. Por ejemplo que la versión de jQuery que se usa en WordPress es diferente.

El jQuery que está instalado viene en modo de compatibilidad. Por lo cual el símbolo “$” no va a funcionar por defecto. Si el código no fue escrito para funcionar bajo dicho modo, es decir cambiando “$” por jQuery, simplemente este arrojará errores.

Es por ello que se necesita modificar una función alrededor del código para hacerlo funcionar. Debería quedar así:

De esta forma, debería de poder correr en cualquier instalación estándar de WordPress con el jQuery incluido por defecto. Solo se le hicieron algunos pequeños cambios a la función anónima para permitir usar “$” al resto del código dentro de ella.

Este segmento de código puede ser entonces agregado de múltiples formas, dependiendo de las necesidades. En cualquier caso, debe de ser agregado al footer.

1. Agregarlo directamente mediante un widget

Esta puede ser la forma más sencilla de agregar el código, pero con el inminente riesgo de que no funcione. Al menos no a la primera.

Pero eso se puede resolver si le añadimos una función que espere a que el documento esté listo. De esta manera el script se ejecutará una vez que el documento web se haya cargado por completo.

De esta forma, en el widget de HTML se podría poner lo siguiente:

No parece complicado. Además de que se puede editar directamente desde la interface web.

2. Agregarlo mediante un hook y función

Usando una función y el hook “wp_footer” podemos agregar el código que queramos al final de la página. Este código lo debemos de pegar dentro del functions.php o similar.

Gracias a esto, el código deberá de aparecer en la zona de pie de página. No es la forma ideal pero debería de funcionar relativamente bien. Aunque imprimir código así no es la forma más elegante de resolverlo.

3. Agregarlo correctamente mediante wp_enqueue_script

Esta es la forma correcta de agregar un script jQuery, ya que incluso permite que se pueda “optimizar”. Usar correctamente el hook wp_enqueue_scripts permite hacer muchas cosas a la hora de manipular los script a agregarse.

Así es, esto es todo lo que se tiene que hacer para agregarlo. Con ello el script será incluido en el front-end para los visitantes, además de que podrá ser optimizado por los plugins de caché disponibles.

Pero para que funcione se debe de crear un archivo *.js y almacenarlo en un lugar accesible dentro del servidor web. O en su defecto se puede aportar una dirección URL completa.

Este método también permite convertir el código fácilmente en un plugin. Lo cual puede facilitar la vida a la hora de realizar actualizaciones. Permitiendo así mantener menos código.

¿Qué hay de los plugins para agregar scripts a WordPress?

Otra de las formas para agregar scripts externos a WordPress es el usar un plugin que facilite el trabajo. Hay muchos de ellos en el repositorio que permiten hacerlo. La mayoría con diversas opciones diferentes para cada caso.

Sin embargo, los plugins no siempre solucionan el problema. El cual se agrava si no sabemos como es que JavaScript funciona. Y aún más si no se sabe detectar errores.

Un script puede ser agregado mediante un plugin correctamente. Pero a la hora de ejecutarse, puede arrojar errores. Mismos que impiden su correcta ejecución. Estos errores muchas veces van más allá de lo que un plugin puede solucionar.

En esos casos, es importante mirar entonces a la consola del navegador. Muchas veces encontraremos ahí que es lo que está sucediendo. Como por ejemplo el caso de la «$» de jQuery, la cual ya había explicado. O incluso otros errores como contenido mixto o errores en el código.

Esas son cosas que requieren más pericia para ser corregidas.

Conclusiones sobre agregar scripts externos a WordPress

Agregar scripts de jQuery es relativamente sencillo en WordPress. Sin embargo se deben de tener ciertas nociones para evitar problemas.

En el caso de que algo suceda, siempre es bueno mirar la consola que ofrece el navegador web. Siempre nos dará pistas sobre lo que puede estar pasando. Para el desarrollador, la consola será siempre una de las mejores herramientas.

Además hay que recordar que la versión de jQuery que se incluye previene el uso de “$” en las funciones. Por lo cual hay que encapsular el código si nos muestra ese tipo de errores.

Y cuando todo haya fallado. Siempre será buena idea preguntar. Ya que puede haber alguien dispuesto a ayudar.

The post Formas de agregar scripts externos a WordPress appeared first on Endless Manifesto.

Saber PHP es algo que invariablemente te va a ayudar. Igualmente mirar el Codex de WordPress… pero al final del día, muchas cosas se condensan en una sola frase: Mira el código fuente.

Entendiendo los Hooks y Transients en WordPress

Hay quienes han hecho un esfuerzo para documentar que hooks se usan y en que momento. Incluso puedes encontrar infografías muy buenas que te dan una guía visual. Eso da mucha luz, pero siempre quedará la duda en algunos casos.

¿Qué es un hook o gancho?

Para ponerlo en palabras simples, es un punto en el cual vamos a “adjuntar el código que queramos”. ¿Eh? Sí. Básicamente llegamos y pegamos el código que queremos en el lugar al cual queremos.

Existen dos formas de hacerlo: Como filtro o como acción. Pero no te enredes con los términos, ya que su diferencia es prácticamente semántica. ¿Por qué? Porque la función para agregar acciones es un alias de la misma para agregar filtros.

Pero eso no significa que debas intercambiarlas a placer. Si cambias información, usa “add_filter”. Si cambias el comportamiento usa “add_action”. A la larga tu código se entenderá mejor.

Un ejemplo

Por ejemplo, la forma más fácil “pegar” código es con un tema y una función. Digamos que tenemos el archivo functions.php y que queremos probar los hooks. Por ejemplo, iniciaríamos con esto:

View the code on Gist.

Una vez que tengamos la función, la magia empieza cuando agregamos “add_filter”:

View the code on Gist.

Con ella, le decimos a WordPress que ejecute nuestra función (agregada como filtro) cuando le toque al hook indicado. En este caso, use uno arbitrario. Es muy probable que no funcione para nada.

Hasta ahí todo bien con el ejemplo. ¿Entonces como saber donde debo agregarla para que se ejecute? Aquí es donde las cosas se complican un montón y es importante mirar el código.

Como mencione en una entrada anterior, tuve que mirar el código para darme una idea. En ese caso, estuve buscando la función “do_action”. ¿Por qué? Porque ella es la que da la pauta de donde se van a realizar los cambios.

De esa forma sabemos exactamente en donde se va a “pegar” el código que queremos. Pero ten en cuenta que no podrás cambiar nada antes de ese punto (ni después, a menos que haya otro hook que te lo permita).

El ejemplo simple quedaría así para que funcione:

View the code on Gist.

Igualmente buscando y mirando el uso de “do_action” y “apply_filters”, obtendrás el nombre del hook el cual tienes que usar y que “variables” le pasará. Con ello tendrás el 90% del trabajo hecho.

Aunque google será tu amigo por un buen rato.

Recuerda, podemos agregar cuantas funciones queramos a un hook. Por ejemplo, con varios “add_filter” en diferentes momentos con diferentes funciones. Incluso podemos indicar en que orden se ejecutarán.

¿Qué hay de los transients?

Para hacer la historia corta con ellos, se trata básicamente de “variables”. Imagina que son como “cookies” o “sesiones”. Pero en vez de afectar a un solo usuario, podemos usar su contenido para todo el sitio. Son usadas especialmente para guardar consultas complejas.

Por ejemplo, aquí tengo el siguiente ejemplo:

View the code on Gist.

Eso se lo agregué a un tema para hacer “algo” una vez al día.

La gran ventaja, es que podemos recuperar el valor de un transitent fácilmente con “get_transient”. Solo necesitas el nombre y listo. Pero ojo, si este ya se encuentra expirado no regresará valor alguno. Esa es su naturaleza, temporal. No es buena idea usarlos para información permanente.

¿Por que expiran? Bueno, es una de sus características. Cuando asignamos su valor con “set_transient”, debemos de definir un tiempo tras el cual expirará (ok, podemos asignar “0” o no asignar nada para que jamás expiren, pero esa es otra historia… no deben de ser usados para almacenar información permanente).

Igualmente pueden ser fácilmente borrados con “delete_transient”, si queremos deshacernos de ellos antes de que expiren.

Estos son más fáciles de usar, pero abren un nuevo universo de posibilidades.

Conclusión sobre los Hooks y Transients en WordPress

He estado invirtiendo el tiempo que puedo para poder entender de fondo todas las características que tiene WordPress.

PHP me ha ayudado mucho, aunque me he topado con muchas entradas en blogs que dan por sentado que ya sabes como funciona lo expuesto aquí. Eso puede frustrar un poco, ya que a veces no se entiende el contexto.

Quizá sea idea tomar un curso que me facilite el camino. Solo es cuestión de hacerme del tiempo.

The post Hooks y Transients en WordPress appeared first on Endless Manifesto.