Category: Articles (Page 72 of 258)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Object-Oriented Programming in WordPress: Terms and Conditions

December 7, 2017 / Tom / 0 Comments

In the previous post in this series, we talked about defining requirements (or a statement of work) and why it matters to have this.

Before we get into actually understanding – and writing – object-oriented code, there’s one more “business-related” topic to discuss: Terms and Conditions.

For many, it’s a bit of a dry topic, but if you’re looking to build solutions for someone else, do so from the ground-up, and do so properly, then it’s important to make sure you have all of the necessary pieces in place before doing so.

And once you’ve:

performed analysis (part one and part two),
understand your customer’s expectations,
and have prepared a statement of work,

It’s time to make sure you have the terms under which you’re working.

Should Money Dictate WordPress Plugin Code Quality?

December 5, 2017 / Tom

I don’t have many plugins available in the WordPress Plugin Repository anymore (and there are reasons for that), but I’ve been giving some thought to those plugins that I do have as well as the general level of code quality that goes into the first iteration of a plugin.

Plugin Code Quality: WordPress Plugin Repository

I mean, for some, plugins are merely small utilities that aim to do one thing and one thing well. Then, other plugins are much more advanced. I think these need a higher level of code quality to make them more maintainable.

But there’s one aspect of building plugins (or any software, really, but I’m specifically talking about WordPress plugins) that I find myself thinking about:

What level of plugin code quality of enough to ship the first version of a plugin?

Building WordPress Administration Screens (Components, Design, etc.)

December 4, 2017 / Tom

I don’t talk about user interface design much because it’s not my forté. I’m all for people working within their core strengths and then hiring them when needed on a project-by-project basis (if the designs aren’t already provided).

But when it comes to working with WordPress administration screens, there’s a difference, right?

I’m on the mindset that because the WordPress administration area has a consistent look and feel, then anything that’s built to work within the administration screen (such as a settings screen) should look as close to the core UI as possible.

Not everyone agrees, and it’s evident by the vast array of plugins that are available. But that’s my position on it.

Periodically, I’m asked how I structure the UIs of projects when they need administration screens and how I map them to files within the project.

So I thought I’d take a simple example and break it down in this short post.

Getting Started with Gulp Starter Packages

December 1, 2017 / Tom

Talking about CodeKit and the benefits it offers for front-end developers has also come just after a post and the benefits that something like Gulp offers, as well.

A post on the difference between the two, why you may want one over the other, and the advantages or disadvantages of either can be its post.

But for this, I’d like to take the starter packages I wrote about regarding Gulp and give a simple example of a starter Gulp file and how to use it in your WordPress projects.

Quick Tip: Metadata and Inline Editing

November 29, 2017 / Tom

If you have a custom meta box or are working with custom metadata at the post-level, then you may stumble across a problem with having data accidentally deleted when saving it from the Bulk Edit screen.

The setup for the problem is something like this:

you have a collection of posts that need to be changed,
you load all posts in the bulk edit screen (as shown above),
you apply a change.

Once this happens, the change occurs, but it erases any custom post metadata that you may have.