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.

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.

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.

Además, ofrece un importante número de opciones que se pueden configurar. Dependiendo de tus necesidades u objetivos. En mi caso, era el obtener un mejor rendimiento absoluto en varios frentes. Después de que los resultados en el PageSpeed Insights habían salido terriblemente mal.

Bueno, exagero un poco en ello. Pero al estar en un hospedaje compartido, es natural que ciertas cosas no corran de lo mejor. Yo espero poder migrar a un mejor ambiente en un momento cercano. Pero en lo que sucede, hay que trabajar con lo que se tiene.

Y un plugin de caché era la opción más natural para lograr los objetivos inmediatos.

¿Por que usar un plugin como W3 Total Cache?

La razón más sencilla es por que ya hay buenas alternativas que ya están correctamente escritas. De lo contrario, tendrías que reinventar la rueda. Dichos plugins ya toman en cuenta los problemas más comunes y los solucionan rápidamente.

Igualmente han tratado de seguir los lineamientos de Google, y otras plataformas similares, para realizar las mejoras. Esto buscando que los webmasters no tengan que estar instalando otras herramientas.

Por supuesto, esto no implica que sea la solución a todos los problemas. Hay casos en los cuales requerirás escribir tus propias soluciones, pero ese es un tema para otro día.

En mi caso, esta era la forma más viable de hacer las cosas.

Preámbulo a la optimización

Ten en cuenta que estas configuraciones funcionan en mi entorno de trabajo (Apache, PHP7, MariaDB). No necesariamente funcionaran en el tuyo. Hay muchas variables que están en juego, por lo cual al final lo que te funcione a ti pudiera ser diferente.

Ante de empezar, coloque el siguiente código en el footer de mi instalación. Con este, podría ver que tan mal estaba.

View the code on Gist.

Ya con ese código, pude ver resultados similares a este:

View the code on Gist.

Ouch, ¿De donde salían tantas consultas? ¿Como era posible que se consumiera tanto tiempo? Esos números indicaban que había un problema el cual tenia que ser solucionado.

Por supuesto, el primer lugar en donde tenia que mirar es en mi servidor e instalación. Eliminar los plugins innecesarios es algo que se tiene que hacer. Posterior, tuve que cambiar de PHP5 a PHP7. Esto debido a que PHP7 es mucho más rápido que PHP5, además de más seguro.

Por fortuna para mí, esto no generó problemas de compatibilidad. Pero es posible que tengas problemas si antes contabas con mensajes de «funciones obsoletas», ya que muchas de ellas fueron eventualmente eliminadas. Puedes solucionar ese tipo de problemas si no te importa ensuciarte un poco las manos con el código fuente.

Una vez limpiada mi instalación, ganando como 0.2 ms, solo quedaba optimizar lo que quedaba. Los plugins que quedaron eran los que consideré que eran de utilidad y necesarios.

Configuración de W3 Total Cache

Trataré de ser breve, ya que el compartir una configuración completa de W3 Total Cache puede ser extensivo. Aunque es bueno el tener una idea de todo lo que puedes lograr con dicho plugin. Aún para la versión gratuita.

Pero si haré incapie en aquellas características en las cuales logre observar una mejora.

Si vas a usar W3 Total Cache en una instalación multisite, lo primero que te recomiendo es activar el mismo para toda la red. Una vez que hayas configurado las opciones más comunes, como el Page Cache, Object Cache y Browser Cache; deberás encontrar la siguiente opción bajo Performance > General Settings y desmarcarla:

Esta es la opción que debe estar o mantenerse desmarcada

Una vez hecho hayas desmarcado «Use single network configuration file for all sites», podrás efectuar cambios «a medida» para cada sitio de tu red. Para ello, deberás de ir a «General Settings» dentro del Escritorio de cada sitio y buscar a la derecha el botón «Use Specific settings». Deberás de hacer clic sobre el mismo para poder editar las características a medida para ese segmento en cada sitio.

Por ejemplo, en mi caso, mi mayor problema fue con las opciones de Minify. Si bien estoy detrás de CloudFlare, el hacer uso de Minify era importante ya que las hojas de estilo CSS y JavaScript no se estaban combinando. Hacerlo eventualmente iba a ayudar mucho.

Pero aquí no había una solución que funcionase en todos los escenarios.

Peleándose con Minify en W3 Total Cache

La posibilidad de «minificar» las hojas de estilo CSS y JavaScript es algo muy importante. Pero, el problema de dicha utilidad es que muchas cosas pueden salir terriblemente mal.

Por ejemplo, compactar el HTML me es útil en este sitio web, pero no en otro. Esto debido a que puede romper el tema y sus características.

Algunas de las opciones activadas para minificar HTML

En el caso de Javascript, «defer» para compactar destruye las páginas hechas en Page Origin, mientras que la opción «async» destruye a Slider Revolution. ¿Que lio verdad? Dejarlos a todos con su gusto con una sola configuración es imposible. La tarea de optimizar se vuelve una de «prueba y error» en el mejor de los casos.

Las opciones de JavaScript pueden causar algunos problemas

En el caso de las hojas de estilo, el problema no es tan prominente. En la mayoría de los casos… las cosas simplemente funcionaron bien y se pudo optimizar sin mayor problema.

El único inconveniente de tener este tipo de configuraciones, es que deberás de «limpiar el cache» siempre que haya cambios. Eso puede ser un poco molesto cuando estás haciendo muchos cambios pequeños, pero se soluciona desactivando la opción de compactar o desactivando este plugin.

Activando Object Cache

Esta alternativa en W3 Total Cache es quizá la que mejor me ha resultado, después de la minificación.

Con los cambios antes mencionados y esta, logre tener entonces un tiempo re respuesta similar a este:

View the code on Gist.

Pasar de 101 consultas a 24 es muy bueno. Es decir que ahora se están realizando solo un cuarto de las consultas que se hacían antes. Eso le quite estrés al servidor de base de datos y se accede más rápido.

Para entenderlo mejor, el Object Cache almacena en disco las «consultas más comunes». Algo similar a lo que hace «Page Cache». Esto permite que ciertos valores sean accedidos de una forma mucho más rápida y ágil.

Mientras menos consultas sean realizadas, mejor. Eso siempre ayudará a que el sitio web sea más eficiente a la hora de tener mayor carga. Pero ten en cuenta que, al almacenar el cache en disco, es posible que esto genere muchos archivos adicionales. Eso hay que tenerlo en cuenta en especial si tienes el espacio o los inodes limitados.

Conclusión

Si la configuración de W3 Total Cache se hace bien, se pueden tener buenos resultados. En mi caso, pase de tener una respuesta promedio de +2 segundos a ~0.6 mili-segundos. Una mejora sustancial tomando en cuenta que todavía estoy algo limitado en este entorno.

También en este caso, es importante indicar que solo apuntale una parte del problema. El otro es del lado del servidor. Si se tiene acceso a un procesador más poderoso en el hosting, el tiempo de respuesta podrá verse mejorado.

Algunos incluso dirían que tener un VPS es casi una necesidad. Pero yo opino que todo depende de las propias necesidades y objetivos de cada persona. Un VPS es bueno para quien tiene el tiempo y recursos para administrar un servidor. Esa es una bestia completamente diferente. Y más si ponemos en la mezcla un servidor Varnish.

Encontrar el hosting adecuado resuelve una parte del problema. Con suficientes recursos se puede rentar un buen servidor, pero sin alguien que sepa como optimizar los programas que corren… pues, serán recursos desperdiciados.

Hay que tener un buen balance entre ambos, pero por ahora W3 Total Cache me ha sacado del apuro.

The post Mejorar WordPress con W3 Total Cache 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.

And all of that because I wanted to run WordPress locally. This, because I would need more computing power than I could get from a regular hosting account.

The Origin of the Problem

I have been using EasyPHP since earlier this decade. Found it to be quite easy to install, move and play with. I just copied over the whole «install» folder to an USB pen drive and I had a portable server.

Easy so far there.

Even deployed it into a very special project made for Quintana Roo’s state government, that has given some interesting results.

I trusted it because it could resist all sort of problems and because messing with it was very easy. At least for self-developed solutions.

Before giving it a new shot into windows, I installed a LAMP stack into my Kubuntu install. Loaded WordPress into it, and gave it a go.

Eventually, I found some problems like that I needed to change users for the folders (like setting «www-data» as the owner) and other issues.

Everything worked as it should. Even preventing me from doing silly unsafe things, but that meant also that I would need to spend extra time I did not have.

The solution? Go back to windows and use a solution I had there.

Updated EasyPHP and got it running as usual. Installed WordPress and when come to download the first plugins… oh problems.

Long history short: WordPress did not saw any transport. Activating cURL or SSH did not help. Neither FTP. Neither some voodoo magic I had at hand.

Aim for a solution

Spend a fair time of weekend searching for another solution to my problem. As I had spent already a lot on it.

Giving up was not an option at this point.

After some reading, apparently, I also needed an FTP server to be running in Windows to make stuff work.

In Linux, I just had used the FS_METHOD «direct» to make it work with no issues at sight. In windows, it just did not work. WordPress complained that there was no «transport available».

That is why then I needed to search for an alternative. There are plenty there.

XAMPP is found

After a couple of searches just came across XAMPP. And I almost did jump aboard when seeing what it does come bundled with.

Like any stack, it comes with Apache, MySQL/MariaSQL and PHP… and Perl and FTP! This last one is what made me jump on as it was bundled.

I am not going to bother explaining the steps on how to get yourself rolling into a local WordPress install, as there are plenty examples out there already. And because I installed it almost on automatic.

The control panel, with some of its options

Of course, I do not recommend to get the bitnami WordPress add-on. While installing WordPress is easy and is tempting to run another installer to do the work for you… the results are not always… nice.

Closing it

Being able to do certain things locally will always be nice. And much faster than reliying in a remote server to process our requests.

It is a great way to rush development, try new things and of course… have the whole potential of your computer in case you need extra power while testing.

I have done one of the first steps needed… now, let’s see how far I can start to go when things start to fall on its place.

The post Give XAMPP a try… if using WordPress appeared first on Endless Manifesto.