If you worked for even just a little while with WordPress, then you must know by now that action and filter hooks are the cornerstone of its extensibility. Through the Plugin API, and using functions such as add_action(), do_action(), add_filter() and apply_filters() we can build almost any thing we can think of on top of the core, often in the form of plugins and themes, but there are still problems that can appear when we implement them.
Este viene siendo un año movido para la comunidad de WordPress en Argentina. Tan movido que, después de 5 años, se está organizando un nuevo WordCamp en Buenos Aires para el sábado 30 de mayo en el Centro Cultural San Martín.
El grupo organizador del evento es WordPress Argentina, del cual formo parte, y con el que venimos dando meetups mensuales desde agosto de 2014. De hecho, en la última meetup estuve dando una mini-charla sobre el WordCamp y de qué se va a tratar:
Además de andar corriendo por los pasillos del lugar, también voy a estar dando una charla orientada a programadores y gente que tiene que lidiar con ellos. Para los detalles, pueden ver el programa del evento.
La entrada cuesta 250 ARS (pesos argentinos), y se puede comprar acá. Teniendo en cuenta los costos de este tipo de eventos, es tan barata que corremos el riesgo de que la gente se pregunte si somos idiotas, pero la verdad es que privilegiamos que sea un evento lo más abierto y accesible que se pueda, y el precio de la entrada es fundamental. El valor para los asistentes es mucho mayor al costo, ya que se les da acceso a 16 charlas dictadas por profesionales de WordPress y de la web en general, muchísimo networking, desayuno y almuerzo incluido, y un mate y una remera de regalo. Todo eso por el mismo precio de dos combos en McDonald’s, o de un kilo y medio de helado.
Desde ya, muchas gracias a todos los que puedan pegarse una vuelta. Nos vemos en el WordCamp 🙂
My first publicly released theme, Follet (the one that powers this site right now), features my also first experiments working with the Customizer. This API offers a great way to see modifications to a theme in real time without actually having to apply those changes to the live site, and a large number of articles have been written about its benefits. What I learned while working on Follet was that sometimes is pretty difficult to manage some styling modifications for the customizable areas of the theme, and I particularly had a really nasty time with colours. However, I think I finally could solve that in an acceptably elegant way.
En el marco de las meetups mensuales que organizamos con los muchachos de WP Argentina, este pasado martes 3 de marzo estuve dando una charla sobre herramientas para desarrollo profesional orientado a WordPress. El evento fue en el Centro Cultural San Martín, un lugar muy pero muy representativo de la Ciudad de Buenos Aires, y la verdad que me llevé un balance muy positivo de toda la reunión, tanto por lo que significa estar presentando algo ahí, como por la charla, el feedback de la gente que vino y el rato que pasamos con los que se animaron a venir a tomarse unas cervezas con nosotros cuando salimos.
Además de mi charla, también contamos con la participación de Juan Francisco Garabato, dando una introducción a WooCommerce, y Serafín Danessa, quien nos habló del WordCamp que se viene en Buenos Aires para fines de mayo. Pueden ver los videos de sus presentaciones acá.
Un millón de gracias a todos los que vinieron, y a toda la gente de WP Argentina por la organización.
A continuación, la sinopsis y el video de mi charla y los slides de la presentación.
WordPress comes with a lot of handy tools that let you have URLs and paths to some folders without having to hardcode them, such as the content_url() and get_stylesheet_directory() functions for the URL to your content folder and the absolute path to your current theme folder, repectively. You can see a list of all these functions in the Codex.
However, if we search for some function to retrieve the absolute path of the admin folder, we’re lost. We have admin_url(), get_admin_url(), network_admin_url() and get_network_admin_url() but those only gives us URLs, not paths. Our only answer is to create our own function.
Of course you can use something like ABSPATH . '/wp-admin', but that doesn’t offer any guarantees in case the admin folder were to be renamed at some point, let’s say manually, by a plugin, or with some rewrite rule. There’s a lot of ways thing can go wrong using that method, especially if you’re distributing your code.
What I suggest as a more proper solution is to create a function like this inside your plugin or theme:
What we’re doing here is replacing the base URL of our site with the ABSPATH constant, which contains the full path to the root folder of your WordPress installation, thus leaving the /wp-admin part (or whatever it’s called) intact. We obtain the name of the admin folder dynamically, without the need to hardcode it at any point.
You can also get the path for the network admin by just replacing the call to get_admin_url() with get_network_admin_url().
Hope this helps 🙂
Finalmente, después de muchísimos meses de organización, el pasado 26 de agosto pudimos presentar nuestra primera meetup semi-formal sobre WordPress en Buenos Aires.
Los pormenores (imágenes, presentaciones, etc.) pueden encontrarse tanto en el grupo de Meetup como en el nuevo blog que lanzamos para ir dando a conocer lo que hacemos, así que en este espacio simplemente voy a limitarme a hablar de lo que representó esto para mí.
A nivel personal fue una gran experiencia. Más allá del enorme nerviosismo anterior a mi charla (y durante gran parte de ella), me sentí realmente muy bien compartiendo con los presentes un poco de todo lo que aprendí trabajando con WordPress y su comunidad. Más todavía al estar rodeado de personas realmente comprometidas con este proyecto de hacer conocer la plataforma a nivel local, cuyo interés va mucho más allá de las posibilidades laborales que algo como WordPress pueda darles.
Hubo gente que ayudó en la organización, que vino más temprano a armar todo lo necesario para el evento, que se quedó hasta más tarde a limpiar, que se acercó a dar una devolución sobre las charlas. Todo eso es muy reconfortante, es algo que hace que no se está tan solo en esto de promover cosas por el simple hecho de que a uno le gustan, de que para llevar adelante un proyecto se necesita ser alguien copado con la gente que lo rodea, de que el conocimiento tiene que ser compartido y no guardado. Hay un compromiso genuino, con muchas ideas fundamentales en común, que se nota mucho. Porque al final de cuentas se trata más del trabajo en grupo que del individual, y cosas así no podrían llevarse a cabo si no tuviéramos esto en cuenta.
Tenemos un montón de cosas cosas copadas por delante y mucho que mejorar. Las críticas son bienvenidas y nosotros mismos las estamos haciendo ahora mismo, siempre con vistas a presentar algo mejor en el futuro. Muy probablemente dentro de poco vayamos a estar presentando un nuevo evento.
Para cerrar, muchas gracias a todos los que estuvieron ahí, como espectadores, como organizadores y como sponsors. Es trillado, y ya lo dije antes, pero sin todos ustedes nada de esto hubiera sido posible.
Recently, I’ve been working in a WordPress plugin that adds a custom post type. That’s not a novelty, we’ve all done that before. However, we usually need to flush our rewrite rules after registering the custom post type in order to prevent permalinks from not working properly, but we don’t always do this in a thoughtful way.
A lot of developers just tend to call the flush_rewrite_rules() function right after register_post_type(), without any kind of security check. The thing is, as the Codex article notices, this is an expensive operation that may use a lot of resources, so we don’t want to have it running all the time. Just once, after the custom post type gets registered, is more than enough.
En el marco de esto que se viene tratando de armar hace ya casi un año y medio, es decir una comunidad dedicada a WordPress en Argentina, y después de las dos exitosas Meetups por el festejo de los diez y once años de la plataforma, finalmente vamos a estar presentando nuestro primer evento semi-formal, a manera de introducción y presentación a un público general a lo que estamos tratando de hacer.
El evento va a constar de dos charlas introductorias y correlativas. La primera, a cargo de Juanfra Aldasoro, coworker de quien escribe y fundador de NiceThemes, va a consistir en un repaso por la historia de WordPress, viendo de qué manera llegó a convertirse en la herramienta con la que están construídos alrededor del 20% de los sitios web, y la importancia de cosas como el open source, GPL y la comunidad para que esto sucediera.
La segunda charla va a ser dictada por mí, y vamos a hablar de las distintas cosas que se pueden lograr con WordPress, cómo extender y saber separar funcionalidad y presentación, y de qué manera construir un entorno de desarrollo profesional que nos permita trabajar de la manera más rápida y eficiente posible, sin importar si uno se dedica a diseño, programación, maquetado, blogging o management.
La cita es el día martes 26 de agosto, a partir de las 19.30 hs. en Areatres Labs. La entrada es gratuita y al finalizar las charlas vamos a continuar con el encuentro de manera totalmente informal en medio de pizzas y cervezas.
El RSVP al evento se puede hacer acá. Nos vemos ahí 🙂
Recently, two articles from Tom McFarlin drew my attention. In fact, it was two months ago, like years in internet time, but I think the matter is still relevant, despite the fact that this post has been sleeping in my Evernote account much longer than I would have liked. The first article (Simplifying Code in WordPress: Option Arrays) was an attempt to address different ways of checking the availability of array keys in WordPress Options API. There Tom offered a couple of methods to do so, and that led to a discussion in the comments area about one-line solutions, platform compatibility, readability, and simplicity versus complexity.
The second article (Don’t Just Get It Working), published one day after the first, was more of a reflection on how we, as developers, sometimes tend to try (or not at all) to have our software built in a somewhat ideal way, being not enough for us to just have it working and doing what it’s supposed to do. We know how it goes from here: that way we can build products with higher quality and maintainability, but also take the risk of becoming so perfectionist that our projects end up being delayed because we can’t decide if braces should be put before or after a new line (for me it’s always before, BTW). There are also those who don’t care too much about what they write and just want to have things working as soon as possible just to make it home, watch Wilfred and bathe in cynicism and depression. There’s no blame nor shame in that, because programming sometimes can destroy all the purity of your soul, though I think we can make the life of that kind of people a lot easier. And there’s another group of people, those who used to write good code, but got so lazy and confident of their own work that ended up writing pieces and pieces of real ape-bull-boar crap while thinking of it as an epiphany. Such a paradox, uh?
This last group is the one that interests me the most. I think it’s easy to see how, once we gain experience, sometimes we write complex code for the sake of brevity or performance, but forget to make it accessible for other people that could eventually work with it. That often leads to code that is only easy to understand by its own author, but over time the author himself may find it hard to read. I think we don’t give enough attention to this fact.
Uno de los grandes problemas que podemos encontrarnos al trabajar con PHP es que, por carecer nativamente de una separación de ámbitos, podemos ejecutar casi cualquier bloque de código en casi cualquier lado. Eso puede ser una gran ventaja en muchos casos, pero también puede llevarnos a provocar, muchas veces inconscientemente, un desorden enorme en la organización de nuestros proyectos, tanto a nivel código como a nivel de archivos.
Teniendo en cuenta este problema, este post es un intento de repaso por algunas prácticas que, creo, deberíamos considerar al programar con PHP. Más concretamente, cuando trabajamos con funciones privadas o internas.
