Tag: WordPress (Page 45 of 219)

Articles, tips, and resources for WordPress-based development.

Two Pillars of Object-Oriented Programming: Part 1 of 2

December 13, 2017 / Tom

When it comes to talking about object-oriented programming (or OOP), you’re likely to hear about The Three Pillars of Object-Oriented Programming or The Four Pillars of Object-Oriented Programming.

Depending on your background, you may have already heard of them, know what they are, and don’t really need to dive into it too much. But if you have not, I believe understanding them is foundational to object-oriented programming.

We’ve covered the whole Analysis phase of Object-Oriented Programming:

With that said, let’s get into the design and implementation discussions. After all, this is what’s many people want to jump to anyway, isn’t it?

Two Pillars of Object-Oriented Programming: Part 1 of 2

Before writing any code, I’d like to do two posts about the four points of object-oriented programming (because I’m one of those who subscribes to the idea that there are four).

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.

Products, Services, Blogging, and WordPress with Matt Medeiros

December 6, 2017 / Tom

A couple of weeks ago, I had the opportunity to chat with Matt Medeiros [once again] about various topics related to WordPress.

I’ve had the pleasure of knowing Matt for several years now, got a chance to hang with him at WordCamp US 2016, and continue to chat with him (when he’s not #medeirosing) both on podcasts and via other channels.

Yup – it’s one of those cases where you meet someone on Twitter, and they become friends. That does happen, you know.

Retweet if you've ever met someone face-to-face after previously only knowing them from Twitter.

— Eric Bailey (@EricVBailey) December 5, 2017

But I digress.

Instead, how about some more fun (or at least more interesting) things?

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.