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.

Los errores SIGSEGV en PHP aparecen una mañana

Durante unos días libres que tuve, realice una actualización de PHP desde 7.2.12 (aproximadamente) a la ultima versión disponible de PHP: 7.3.1

Todo salio bien en ese momento. Incluso las cosas funcionaban sin problemas, pero eso cambiaría a la mañana siguiente.

Fue entonces cuando este sitio web me arrojo un error 503. Así como otros más en esta VPS corriendo ubuntu.

Al revisar en los archivos de errores, en busca de alguna causa, solo encontraba lo siguiente:

(104)Connection reset by peer: [client XX.XX.XX.XX:XXXX] AH01075: Error dispatching request to : 

AH01067: Failed to read FastCGI header

Al mirar más de cerca, resulto que Apache servia contenido estático sin problemas. Solo las páginas generadas por PHP mostraban el error.

Cuando revise en los registros de PHP, la siguiente línea aparecía múltiples veces:

WARNING: [pool XXXXX] child XXXX exited on signal 11 (SIGSEGV - core dumped) after 30.977656 seconds from start

Este error de SIGSEGV en PHP significaba que había sucedido una Violación de Acceso de memoria (segfault o segmentation fault) por parte de PHP.

¿Cómo era esto posible? ¿Qué lo estaba causando?

Una de las soluciones temporales que encontré fue el usar el siguiente comando:

systemctl restart php7.3-fpm

Pero esta era una solución temporal. Ya que al poco tiempo el problema volvía a suceder. En algunos casos tan pronto como a los pocos segundos.

Esto se estaba volviendo una pesadilla.

Apache2, prefork y el modulo PHP7.3: ¿Origen del problema?

Durante mi investigación, detecte algo que pase por alto cuando actualice PHP a su versión 7.3: Me había agregado un nuevo módulo y cambiado el modo MPM de Apache.

El modo lo podemos ver con el siguiente comando en ubuntu:

apache2ctl -V

¿Eso explicaba el problema?

De lo primero que me percate es que ese nuevo módulo, llamado solamente «PHP7.3», necesitaba que Apache2 corriera en modo Prefork.

No entendí por que de este movimiento, pero no era el cual había configurado en el servidor: Event.

Por lo cual procedí a desactivar PHP7.3 y cambiar Prefork por Event, ejecutando lo siguiente:

sudo a2dismod php7.3
sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
systemctl restart apache2
systemctl restart php7.3-fpm

De lo primero que me pude percatar, es que los errores de SIGSEGV en PHP bajaron dramáticamente con esto.

Aunque pronto descubriría que estos estaban lejos de desaparecer.

El error SIGSEGV en PHP da tregua, pero no por mucho

PHP 7.3 funciono de forma normal por algunos días. Pero eventualmente el error volvió a aparecer.

En los registros volvía a ver la señal 11 de SIGSEGV en PHP, lo cual me indicó que el problema tenia muchas posibilidades de seguir apareciendo.

Aunque era menos común, esto significaba que podía suceder en cualquier momento.

Buscando más a fondo, encontré quizá lo más profundo del origen del problema:

segfault at 6c6f4320 ip b4b92b37 sp bfe93df0 error 4 in opcache.so[b4b82000+6d000]

Por fortuna, comencé a notar que no era el único con este problema. Usuarios del panel Plesk también reportaron este problema. E incluso dicha empresa no está recomendando PHP7.3 por el momento.

Lo cual, parece indicar que no hay una solución definitiva por ahora.

Entonces, ¿Cómo solucionar las caídas de PHP?

Como comenté antes, PHP constantemente arroja un error segfault o SIGSEGV el cual interrumpe la ejecución de cualquier recurso dinámico.

Sin embargo, esto se soluciona cuando se reinicia el servicio. Hacerlo manualmente no es una solución aceptable. Y crear un cronjob no me parece una buena idea.

Pero hay alternativas que ya ofrece PHP de forma nativa.

Por ejemplo, nosotros podemos editar el archivo php-fpm.conf (ya que es el modo FPM el cual fallaba para mi) y configurar lo siguiente:

/etc/php/7.3/fpm/php-fpm.conf :
emergency_restart_threshold = 3
emergency_restart_interval = 1h
process_control_timeout = 10s

Con esto, hacemos que PHP este al pendiente por errores. Y cuando sucedan 3 errores en una hora, se reiniciará automáticamente.

De esta forma, el servicio se restablecerá de forma automática sin necesitar nuestra intervención.

Estos valores pueden ser fácilmente cambiados de acuerdo a tus propias necesidades. Solamente recuerda reiniciar el servicio de php-fpm una vez hagas cambios.

Para concluir

Si bien actualmente PHP7.3 parece tener problemas con su sistema de cache interno, con las correcciones adecuadas es posible usarlo sin problemas.

Pero hay algo muy importante que resaltar. Por ahora es mejor el mantenerse en PHP7.2 o tener múltiples versiones instaladas si es posible.

Ya que, a diferencia de la versión más nueva, PHP7.2 está mucho más maduro y este tipo de problemas son mucho más raros.

En mi caso, todavía sigo buscando que es lo que causa el error de SIGSEGV en PHP 7.3, y aunque sospecho que puede causarlo… no tengo una solución definitiva.

Lo que si, espero que esta pequeña guía le sea de utilidad a alguien. Ya que encontrar una solución, aunque parcial, fue una búsqueda de varios días.

Actualización y solución definitiva

Tras haber estado sufriendo el problema de los errores SIGSEGV por mucho tiempo con PHP 7.3, estos finalmente dejaron e suceder.

Sin embargo, la solución puede no ser tan trivial.

Resulta que con PHP 7.4, los errores simplemente desaparecieron. He estado observando los registros de PHP de forma continua por este error desde la actualización, pero esta no ha vuelto a suceder.

Lo cual me hace pensar que el problema no esta presente en PHP 7.4.

Si esta dentro de tus posibilidades, actualizar hacia la versión 7.4 de PHP es lo mejor. No solo trae más características si no que es hasta más seguro.

En caso de que no sepas como actualizar, pregunta con quien lleva tu hospedaje, este debe de poder ayudarte.

The post Error SIGSEGV en PHP 7.3 [Solución definitiva] 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.

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.

Para quienes no lo sepan, un hook es básicamente un punto en el cual nos podemos colgar para realizar una acción. Normalmente una función.

En mi caso, yo necesitaba cambiar la apariencia de widget “Top Posts” de Jetpack.

Ya que el mismo no tiene forma de cambiar la forma en el cual se muestran las entradas. Y menos para cambiar el tiempo a considerar.

El objetivo es que se pareciera lo más posible al de “Entradas Recientes”.

Primero, investigamos

Después de estar revisando durante un buen rato, encuentre parte de mi solución en el sitio oficial de Jetpack.

En ella, simplemente debo de adjuntar dos funciones al archivo “functions.php” de mi tema. Una vez hecho el tema hijo, agrego los segmentos y ya tengo la primera parte del problema resuelto.

Con el hook “jetpack_top_posts_days” nosotros podemos modificar el número de días que se han de considerar para generar las entradas más populares.

Mientras que con “jetpack_widget_top_posts_after_post” podemos agregar cualquier dato que queramos. En este, igualmente aprovecho para agregar la fecha, aunque descubro que no puedo cambiar los tags del nombre de la entrada. Lastima, eso significa que una parte de la solución va a tener que ser puro CSS.

Termine agregando las siguientes funciones:

View the code on Gist.

Le agregue la clase «widgets-list-layout-links» al «Div» para que pudiéramos cambiar su apariencia vía CSS.

Escarbamos más dentro de Top Posts de Jetpack

Una de las grandes ventajas del Open Source es que podemos mirar el código fuente de las aplicaciones que queramos. En mi caso, encontré el código fuente del widget que quería. Pero, no encontré una forma de como cambiar el tamaño de las imágenes mostradas. Ni tampoco de como evitar que use el servicio Phonon.

Posiblemente hay alguna forma de evitar lo último, pero por ahora ese no era un tema de alta prioridad.

Por fortuna, veo que “jetpack_top_posts_widget_image_options” es lo que necesito para solucionar mi problema con los tamaños de la imagen.

Las imágenes aparecían con un tamaño de 40px, pero las necesitaba en al menos 150px para que se vieran “decentes”.

Tras escarbar un poco en que datos le pasaba a mi función, simplemente hago lo siguiente:

View the code on Gist.

Así es, simplemente sobre-escribo lo que tenga el array y ya estamos. Al menos con PHP.

Estilizando Top Posts de Jetpack con CSS

Imitar la apariencia en el widget Top Posts de Jetpack fue un tanto especial.

Tuve que usar mucho el Inspector de código de Google Chrome para darme una idea de donde se estaban estilizando las cosas.

El primer gran problema era que Top Posts usa “divs” internos. Por lo cual ordenar el contenido podía ser un poco difícil. Esto por que el tema original lo hacia diferente.

Pero con esto lo logré:

View the code on Gist.

Con este segmento, cambio la apariencia del icono mostrado para los Top Posts.

Mientras que no soy fan del !important, parece ser la única manera en la cual se aplicaba el cambio en su tamaño. Todavía tenia que mover el texto adjunto un poco y darle mejor apariencia.

View the code on Gist.

Con estos ya estamos casi listos. Esto cambia la apariencia de los enlaces en el interior del espacio del widget de Top Posts. Cambiamos la fuente, así como el espacio, el color y el comportamiento cuando pasamos el ratón sobre ellos.

Incluso pegamos un poco más el texto a la imagen, para darle una mejor consistencia.

View the code on Gist.

Y con esto cambiamos la apariencia de la fecha mostrada. La hacemos más pequeña y cambiamos su color. Para que se parezca lo más posible al original.

Conclusión

Los cambios en el CSS mostrados aplican solamente al tema que uso actualmente, “Lovecraft”. Diferentes temas tendrán diferentes aspectos que deberás de cambiar para que se vean de la forma en la cual necesitas.

En mi caso, solo era emular. Y aun así tuve que meter mano para realizar varios cambios.

Lo que si me quedo claro, es que siempre será mejor el crear un tema hijo. Aun cuando no juguemos con el código HTML o PHP del tema.

¿Esto por qué? Ya que no sabemos en que momento vamos a necesitar hacer cambios a la apariencia que requieran de hacer uso de un tema hijo. De esa forma ya estamos preparados de antemano.

Si bien existen formas de agregar el código mediante plugins, para mi es mejor hacerlo directamente en el tema.

Aunque bueno… los cambios hechos igual podrían agregarse como un plugin, eventualmente. Esa es la gran flexibilidad que WordPress da.

The post Modificando Top Posts de Jetpack appeared first on Endless Manifesto.

Revisando código «viejo», es que me encontré con una pequeña función que ciertamente me ayudó a sacarme de apuros en algún momento. Se trata de la función imagecreatefrombmp.

Para quienes hayan manejado imágenes en PHP 5, ya sabrán lo horrible que es lidiar con archivos BMP.

La necesidad de usarla nace debido a los propios usuarios del sistema. No les interesaba guardar las imágenes en un formato diferente al BMP o simplemente no sabían como hacerlo.

¿Qué es más fácil entonces? ¿Amansar al burro o adaptarte al burro?

El código de la función imagecreatefrombmp

Ciertamente tome el camino de adaptarme, probé muchas cosas hasta que encontré esta solución bastante creativa:

View the code on Gist.

En pocas palabras: Esa función abre la imagen, la «descomprime» y luego lee los datos para crear un lienzo en PHP que se pueda usar.

¿Pero por qué se necesita tanto? Sencillo, PHP no soporta las imágenes BMP. Al menos no hasta que PHP 7.2 esté disponible.

Cerrando sobre función imagecreatefrombmp

Si bien esta solución no es perfecta, ya que cada imagen toma mucho tiempo en ser procesada, si ayuda mucho en lograr el objetivo.

Ya hay versiones más «modernas» con mejor código, pero la que compartí es la que implementé en su momento.

Y es algo que se ha de tener bajo la manga ya que no siempre todos distinguen entre las diferencias de los archivos BMP, JPEG, GIF, TIFF o PNG. Cada formato, un reino diferente.

The post [Función] Código PHP: imagecreatefrombmp appeared first on Endless Manifesto.

So far, WordPress has been quite easy to manipulate. Extend and even update without any major issues. Something that I did not experienced with Drupal 6, back in the day.

That is why the more I mess with WordPress, the more I like it.

Keep building with WordPress

Rebuilding has been a pleasure so far. And that I have not yet got into code and extend some functionality myself. This using PHP or JavaScript. But I totally plan to do so.

Maybe this one will fit on what I do need. For now, a simple blogging platform that I can mess with at will. Not caring much of a dissaster happens.

But one thing is true, I need to wipe out properly some old installations and domains. Or probably give them a proper set up for its own.

One of the things that I have seen is that you can do Multisite installs. And that really sounds amazing. I had something like that when I was on Drupal.

But on Drupal it was like an administration nightmare. I hope it is much more easy with this CMS. With what I have been quite happy, and been seeing that some rumors I did read back in the day where not totally true. At least for now.

I mean, back in the day, I did not went the WordPress route because it was regarded as heavy and bloated. Maybe that was right back in 2010 or earlier, when I got this space.

But for today standards, almost any hosting space can deal with its needs quite easily. Despite that, there is a lot of work to do. A lot of optimizations that need to be done.

So, its time to move on.

The post WordPress: Setting up some websites appeared first on Endless Manifesto.