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.

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.

During such time, I have learned PHP, MySQL, some Javascript and whatever I have come across with it. Of course, back in the day, you did not have anything named «Joomla», «Drupal» or «WordPress». If you wanted a CMS, you either spend a bunch of bucks or ended making one by yourself. I mostly did stuff with my bare hands.

While doing stuff yourself seems nice, there is a moment where you eventually grow tired. You just want to add content and have everything work without issues.

While adding stuff was not hard… it was not really efficient, in the way I did stuff… so, with the time you simply stopped to do so.

Retaking the network

Somewhere in 2010, I started to be serious about retaking and having a much more professional site and so on. I had a bunch of experience with a website from back 2004, but I was more than sure that did not want to go all the same road all once again.

Gathered then some of my pieces around: Plain HTML is a big NO NO. It is going to be a pain to keep such things. Have you tried to edit 10 HTML files? When you are at the 5th one, you already want to do something else.

The second way to go was PHP again with some tricks, but NO. It was very unprofessional. While I for sure were able to make it look nice and such… in the long run, it was falling into the same pitfall than before… or worst… maybe open a random bug can.

What was the solution then? At that time, there were now some names and the CMS started to take everything around.

One of the first considerations I had was the PHP-Nuke CMS, that I remembered seeing from somewhere, but do not remember what exactly made me not to give it a try.After some extra search eventually had a few names to give it a try: Joomla,

After some extra search eventually had a few names to give it a try: Joomla, Drupal and WordPress.

Joomla

I am not going to be fair with this engine as I do not remember giving it enough chances.

When I installed and give it a test run, I felt like that Joomla was quite fitting to what I needed back in the day: A simple blogging platform.

Played with it a few hours until I went ahead to try and customize it. There is where I found the very first problem with it.

Maybe my reaction if I did it today

I ended having no idea how to modify the themes I had downloaded for it.

Maybe if I see the code today, I would be like «why I was so derp?». But back at that day, I spend a fair amount of hours trying to make it look nice and other stuff… just to give up eventually.

So, moved on.

Drupal

I did not give WordPress a try during the 2010-2011 because… well… a bunch of people was like «It is really bloated, avoid it at all costs». Since the CPU use and memory was a concern for me, back at that day, I decided not to question that, so moved to the next one in the line: Drupal.

At that moment, Drupal was in its version 6. Installing was… easy… configuration was not all that bad. Adding and editing a theme was relatively easy after a few hacks here and there… urg… really bad habit from that day.

While for sure getting used to the administration and blocks was… hard… I felt like that it had a lot of potential. Of course, if you did not mind to get messy with the code.

One thing that I do remember is that a bunch of pluggings did not work on it. So setting up the installation was like a trial and error process… because you never had any indication from the Drupal website if the plugin you downloaded might work on your site or version.

Struggles with it

And as the days went on, stuff started to surface and become more and more annoying.

For example, keeping Drupal updated was a struggle on itself… as I needed to re-do some of my changes into it… or something random did broke… you never knew. The experience was not really pleasurable after a couple of years… and that is what you earn when you mess with the code.

Also, it did not help, I think, that I had a multisite install on it. Heck, even doing that multisite install was rough and messy. Create databases, re-do installs, move files and hope for the best.

Eventually, my installation did fall to the hands of hackers given that I was unable to keep it updated and was avoiding to move to Drupal 7 the most I could because… it was going to break many things.

I for sure will give the new Drupal 8 a try sometime soon, but it is clear that it needs full-time attention. Something that I can’t afford most of the time until a good change happens here.

WordPress

Like mentioned before, back in 2010-2011, I simply discarded this one because… well… people said it was boatled. But now in 2016, computing power is better suitable than what it was at 2010. And of course, had now access to better hardware at this host too.

My first «official» contact came during the set-up of a website that is hosted alongside this one. that person insisted on making a WordPress install, so it happened.

After being moving it for a few minutes, it was clear that it was like nothing else that I had tested before. Was so surprised that I ended doing an install on my own space too.

It was clear why it is used on 1 of every 4 websites on the internet.

Remember, not everyone knows PHP, HTML, CSS and such to be able to modify a website. Most people just can have a bad day and a very steep learning curve ahead with CMS.

And even if you do know such things, then you can modify themes and what not quite easily. I have been having a lot of fun doing that recently. It is enjoyable like never before. Still, I want to someday design my own theme rather than modify one.

Maybe someday.

Just my experience

While there are a bunch of articles there out talking about what system is better, I really can only say that is better just to give it a try to any of them.

But one thing is sure: WordPress is really way too easy to use and maintain, while Drupal is just really more powerful, but requires a lot more of dedication.

I am sure of a few things: I’ll keep using WordPress, but will try and tame Drupal eventually.

The post Self history with: Joomla, Drupal and WordPress appeared first on Endless Manifesto.