I think that one of the more underrated aspects – or perhaps one of the rarely discussed aspects of custom plugin development – is the ability to include custom templates in our WordPress plugins.
And, to be honest, I get it: I’m one who is pretty staunch on what should a plugin and what should be a theme.
- themes are for presentation,
- plugins are functionality.
If I include templates in a plugin, am I not doing the same thing as when developers include functionality in their themes?
As with so many things in development, I think it depends. I mean, adding a lot of functionality that locks you into a theme is something of which I’m not a fan. Similarly, if you have a plugin that is meant to showcase data on the front-end and is theme agnostic, then it makes sense.
So you have to be judicious in your decisions.
Regardless, there’s a common set of steps we can use when including custom templates in our WordPress plugins.
And that’s what this post is going to show.
Continue reading “Including Custom Templates in Our WordPress Plugins There’s a common set of steps we can use when including custom templates in our WordPress plugins.“
In November 2017, I started a members-only section of this site and, for the most part, have written at least one article per week that has been long-form and aimed at those who are looking to improve their WordPress development skills, their business acumen, or both.
This week, I’m pausing before starting a second series. Last week, I finished the most extended series I’ve done yet in which we refactored the WordPress Widget Boilerplate.
There’s documentation that I need to finish up before merging the development code into the master branch; however, in the 16 article series, we took apart an eight-year(!) code base, refactored it, and put back together using modern standards.
But why am I telling you this?
Continue reading “16 Months of Members-Only Content It’s been a little over a year of members-only content and this is what I’m planning to do next.“
I’m a fan of short release cycles. Depending on the project, the length of the cycle will vary, but for many of the types of projects on which I work, I aim to have two-week release cycles.
Further, there are times in which I’m working on a project for someone where environmental variables are necessary so the code knows if it’s running in development, staging, or production.
And this can be achieved a different way depending on the needs of the project. Sometimes, a configuration file will work, sometimes query string variables can work, and other times I think it’s reasonable to store a setting in the database.
But, as far as WordPress is concerned, I think we shortcut better design decisions and throw information in the database, specifically the options table, when alternatives may be better suited.
Continue reading “Don’t Pollute the WordPress Options Table Don’t just toss data into the options table because it doesn’t fit anywhere else.“
This isn’t something that’s really WordPress-development related. It is, perhaps, tangentially so and it’s something that I’m likely going to be talking about on this blog and in a few of the upcoming podcasts so I thought I’d go ahead and bring it up now.
For many of us, we’re well aware of the privacy implications of the software and services many of us use on a day-to-day basis even if we’re not sure just how this information is shared.
Anyway, since this is something that does tie back to WordPress, data-ownership, and so on, it seems fitting to discuss at least periodically.
I think there’s a level we’ve been comfortable with certain aspects of privacy and how data is shared (some have a higher threshold than others for it, sure) but it’s beginning to reach an unsettling level for me.
But let me back up.
Continue reading “Privacy is Hard, Let’s Go Shopping! There’s a level of lack of privacy and how data is shared but it’s beginning to reach an unsettling level for me.“
We’re finally at the final post of the series on refactoring the WordPress Widget Boilerplate. By the end of this post, we’ll have the development branch of our code done, and we’ll be ready to merge everything into the master branch.
There is, however, still a bit of work to do. Namely:
The last thing we’re going to look at after this is tightening up some of the conditional logic along with a word about caching data (since we’re already doing a bit of that in earlier posts).
So those are the two things we’re going to be looking at in this post. Specifically, we’re going to look at handling conditional logic for the front-end and then how to implement basic caching.
Continue reading “WordPress Widgets: Refactoring, Part 13 Here, we finalize the updated version of the WordPress Widget Boilerplate.“