This is sort of a compilation of articles I ran into over the last week. I think they can be useful for both myself and other developers, either doing WordPress-related work or not. Some of them are very technical, while others just share personal experiences, and the rest fall in the middle.
Quick Tip: How to Disable Page Templates in Child Themes
While developing a website with WordPress, you’ve probably been or will be in the following situation:
You created a Child Theme, inheriting a number of page templates from the parent theme. The thing is, maybe you don’t want some of those page templates. You don’t want your users to select it, or you’re not gonna support it, or it’s not fully compatible with the modifications you’ve made, or you just simply don’t like it. Whatever the reason is, you’d like to remove it from the dropdown in the page editor when creating a new page.
Before WordPress 3.9, there were some bizarre and pretty much complicated things to accomplish this. However, wlth the introduction of the theme_page_templates filter, it has become a really easy task to do.
Why Using Shortcodes Inside Templates Isn’t Always a Good Idea
The WordPress Shortcode API is going through a great deal of a refactoring process, which was necessary since a long time ago. Though still in its initial stages, one of the main goals is to provide more strict guidelines about the way shortcodes should be used, specially regarding what can and what cannot be passed as attributes, being HTML code the more complicated case. This is part of an ongoing discussion that began when WordPress 4.2.3 was launched, and lots of sites broke because they were using shortcodes in a way the update didn’t support anymore.
I’ll skip my point of view about the way the update was managed by the Core team, and I won’t dare to say that there’s a “wrong” way to use shortcodes, since I think that any provided tool should be used in any possible way that’s allowed by its internal logic. I’m just gonna stick to talk about a practice that can help to prevent some issues with the Shortcode API.
Programar no es (tan) complicado
Aprender a programar no es exactamente fácil, pero tampoco es lo más difícil del mundo. La dificultad no tiene tanto que ver con entender la sintaxis de un lenguaje, o los conceptos básicos de la programación en general, sino con aprender a manejar distintos problemas que van a ser encontrados de forma inevitable mientras escribamos código. La sintaxis y los conceptos básicos son cosas muy sencillas y que resultan incluso muy intuitivas, porque en general tienen que ver con la vida cotidiana de cualquier persona que haya aprendido a leer y escribir, sin importar demasiado qué tan bien lea o escriba.
How to make public methods and functions private when used as hooks
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.
How to Avoid Redeclaring Inline Styles for WordPress Customizer
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.
Correctly Obtain the Path to the WordPress Admin Directory
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.
Here’s How You Do It
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 🙂
How to Efficiently Flush Rewrite Rules After Plugin Activation
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.
More Thoughts on Writing Accessible Code
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.
Now With Random Cats Included
I wouldn’t say I am exactly a cat person. I do have a cat, but I’m not really more into cats that I am into dogs. I don’t completely share all of the cat related crazyness that’s been around the internet for years now, but I enjoy it as something cool, funny and cute at different times.
Cats have also become a meme on their own, so in those moments of tension or boredom both at work and home, a gif of a cat going batshit crazy serves as a relief from the awful pits of common life. At least for a while. Then you start looking for more photos, and boom, there goes your day.