Category: Articles (Page 91 of 258)

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.

Continue reading

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

One of the advantages of working with object-oriented programming is the ability to define interfaces so classes that implement those interfaces have a strict set of functions that said classes must implement.

That is the definition of a class interface, anyway:

An interface is a contract specifying a set of methods, fields and properties which will be available on any implementing object

But how might this look if we’re aiming to create a namespaced solution for including WordPress plugin interfaces (or an interface) for a class that can be used to enqueue stylesheets or JavaScript files?

Continue reading

When working on WordPress-based projects that utilize Composer, there are times that we’re going to want to have certain dependencies available for our project and there are times where we’re going to want to have tools available throughout our system.

For example, for some projects, we may want to have PHP CodeSniffer with the WordPress Coding Standards available. For others, maybe not.

But having a tool like WP-CLI is something that’s likely better served when it’s available throughout the entire system rather than on a project-by-project basis. Globally installing WP-CLI is a relatively trivial matter.

It does, though, assume you have Composer already installed and available on your system.

Continue reading