Page 55 of 427

Don’t Pollute the WordPress Options Table

March 19, 2019 / Tom

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.

Don't Pollute the WordPress Options Table: The Options Table ERD

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.

Privacy is Hard, Let’s Go Shopping!

March 14, 2019 / Tom

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.

WordPress Widgets: Refactoring, Part 13

March 13, 2019 / Tom

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.

Suggestions for Organizing Procedural Code

March 12, 2019 / Tom

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.

Organizing Procedural Code

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.

WordPress Widgets: Refactoring, Part 12

March 7, 2019 / Tom

As far as refactoring the WordPress Widget Boilerplate is concerned – especially given how far we’ve come since the project started eight years ago – we’ve done a lot of work.

We’ve brought it up to a far more modern standard and we’re making it far easier to work with it such that building future widgets should be easier. And this is not only from the standard of the boilerplate but from an object-oriented standard so that maintenance and code quality is higher.

In the last post, we wrapped up much of the work for the administration area and are ready to begin our work on code for the front-end.

We said:

Next, we’re going to look at rendering content on the front-end. We’re nearing the end, of the refactoring of the Boilerplate but there’s just a bit more to do before we’re ready to merge it into the master branch of the codebase.

So in this post, we’re going to pick up there. Now if you’ve been following along up to this point then you should have everything you need from the develop branch.

If not, be sure to pull it as that’s where we’re going to pick up in the remainder of the post.

Tom McFarlin

Don’t Pollute the WordPress Options Table

Privacy is Hard, Let’s Go Shopping!

WordPress Widgets: Refactoring, Part 13

Suggestions for Organizing Procedural Code

WordPress Widgets: Refactoring, Part 12