Author: Tom (Page 114 of 427)

Registering WordPress Hooks Using Another Class

April 19, 2017 / Tom / 0 Comments

In yesterday’s post, I talked about a WordPress plugin constructors and the rationale as to why hooks shouldn’t be in the constructor.

Though I mentioned a number of ways to handle hook registration, I didn’t bother to go into details for each of those strategies. As far as I’m concerned, they are deserving of their own article in order to provide as much detail as possible for how to set something up.

For example, one of the methods I shared stated:

It’s possible to create a class that maintains a registry of objects and the hooks with WordPress.

In other words, it’s about registering WordPress hooks using an object-oriented approach to decrease coupling and increase cohesion among the components in the plugin.

But what does that even mean? What are the advantage does it bring, how is it setup, and how it used?

WordPress Plugin Constructors Shouldn’t Define Hooks

April 18, 2017 / Tom / 0 Comments

WordPress plugin constructors seem to be more and more a topic of debate when it comes to what they should define. I’ve talked about it before but it’s okay to revisit a topic like this from time-to-time, right?

After all, there are things we learn and things that we change as we gain more experience.

It’s not at all uncommon to see plugins defining hooks and other behavior, but I’m not a fan of this approach. Instead, I think handling hook registration should be done in its own function or, even more drastically, handled by a set of classes.

But before getting into that, I want to explain what should go in a WordPress plugin constructor, why it should go in a constructor, and how this can be handled when working on your plugins.

Writing WordPress Plugins For Existing Features

April 17, 2017 / Tom / 0 Comments

In a previous post, I’ve talked about the WordPress design philosophy of decisions, not options. And I’m working towards getting to a point, but I’ve got to set the foundation a bit about the whole thing first.

You can read the entire set of philosophies on this page, but here’s the gist about the one I’ve just mentioned:

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration.

As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in.

It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

This is arguably my favorite philosophy that defines what should go into WordPress core and how; though I’d be remiss if I didn’t say I think there are areas for improvement.

(I know this is where the discussion can take a turn into left field but I don’t know to do that, nor am I trying to start armchair quarterbacking.)

But here’s the question:

If there’s an area of the WordPress UI that can be improved by a plugin that does the same set of functionality that already exists in the plugin, is it worth creating the plugin if the feature already exists?

Does it make sense to create WordPress plugins for existing features if the plugin adheres to the “designs, not options” philosophy more so than the core feature?
Continue reading

WordPress Developer Bootcamp via Know The Code

April 14, 2017 / Tom

Some time ago, I talked a bit about the WordPress Developer’s Club (which is still alive and kicking). But since that post, Tonya Mork and others have been working on something called Know The Code for the last few months.

There’s an active community, a ton of educational content, assignments, labs, explanations, examples, and so on. If you’re a budding WordPress developer or someone who’s looking to get into professional WordPress development, I recommend it.

But in an attempt to go to 11, Tonya and Know the Code is looking at offering a WordPress developer bootcamp specifically for those who are looking to take it a step beyond the code itself.

How to Exclude Files From PHP CodeSniffer

April 13, 2017 / Tom

When you’re working with PHP CodeSniffer, and you’re doing so in the terminal, you’re likely looking to output errors into something other than your IDE.

I mean, if that were the case, you’d just have it running in your editor, right?

But there are times where you may be interested in finding the problems in other people’s code. Perhaps it’s a dependency, perhaps it’s a third-party piece of software, or perhaps it’s a favor.

Whatever the case, if you’ve set up the project directory in a way that uses Composer to include PHP CodeSniffer and you’re using the WordPress Coding Standards, then you’re likely going to need to exclude files from PHP CodeSniffer when running the program.

And this is how you can do that.