Tag: WordPress

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.

That is:

• 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.“

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.“

For as much as I write about – and am a fan of – object-oriented programming, I don’t write much about the times in which I’m working with a procedural code base.

Procedural programming is a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, or functions, simply contain a series of computational steps to be carried out.

Sometimes, I come by this from the requirements of a project, sometimes it’s from a project that I’ve inherited, or sometimes because of something else.

I think it’s important that, as programmers, we don’t hold one paradigm so high that we shy away from working with other ways of writing code. After all, the act of writing code is, at its core, about solving a problem.

How the problem is solved may be considered secondary.

Regardless, whenever I’m working with a code base; however, it’s written, I still try to make sure it’s organized in a way that’s cohesive, as easy to follow as possible, and is able to be maintained over time.

I thought I’d share how I approach writing WordPress plugins using procedural programming versus object-oriented programming and how I go about organizing procedural code.

If nothing else, perhaps this will give you some ideas for a current or future project.

Continue reading “Suggestions for Organizing Procedural Code How I write WordPress plugins using procedural programming versus object-oriented programming and how I go about organizing procedural code.“