I’ve been working on a small project, more of a web application than a site, that’s required the development of both a custom-theme and tightly coupled, but very specific functionality.
This is a very narrowly focused project (about which I’ll likely talk about at some point in the future) but in working on it, it’s forced me to get back into the theme development aspect of WordPress development a little bit.
No, I’m not doing any design – thankfully – but I am having to work on theme customizations from a functional perspective. In doing this, though, it’s had me revisit the required functions.php and some considerations I’ve never had before.
Furthermore, it’s caused me to look more deeply at the use of mu-plugins and ask when they are necessary and why I haven’t used them more in the past (or even when one would truly need to use them).
So I’m going to wax poetic about that a bit.
Functionality tied directly to the theme and WordPress core goes into functions.php. Domain-logic that required by the entire solution to work goes in a must-use plugin.
In previous posts, I’ve talked about the idea of focusing on an area and going deep rather than wide. This is personal preference, of course, but it’s mine, nonetheless.
Over the last year, though, one of the byproducts that I’ve found is the longer you stay in a given industry, the more common certain problems become. (This shouldn’t come as a surprise as this is precisely why we have design patterns.)
But the thing about doing this is that you develop a sort of tunnel vision for ways to solve problems.
Case in point: Recently, I was tasked with needing to develop some functionality that was going to parse markup and convert it into a slightly different format.
It is a blog, sure, but it is also a wiki. It’s a spot where I can post ideas, snippets, resources, thoughts, collections, and other bits and pieces that I find interesting and useful. Instead of always being a “performance” level of blogging, it can be a looser more human endeavor that drops the idea of robots sorting the content (in this case simply by date created) and embraces the idea of curation, by me, for you.
I try not to use Chrome but, from time to time, various applications or projects necessitate its use.
I still like the speed of the browser and I really like its debugging tools but the data collection that Chrome performs is one that I dislike and I see no reason for the organization to change its practices. For more information see this, this, this, and this, and this.
And sure, some of the above advice is anecdotal but these are just some of the more common things that people are going to come across if they start looking into what the browser is doing. There are plenty of deeper analyses of what the browser does from a deeper technological standpoint.
But the purpose of this post isn’t to digress into all of the things that Chrome is doing (the when, how, and why), but instead its about sharing extensions that I’ve found to be useful when using Chrome.
Previously, I wrote about updating the content of the blog.
Part of doing that included the desire to select a different theme (preferably one that brings back Post Formats because I never didn’t like them), and to expand the type of content about which I’m writing.
Though I’m still working on the tagline for the type of content that I want to begin incorporating, it’s the first of a few steps for a new direction.