Tag: WordPress (Page 70 of 219)

I recently walked through the process of using a class’ constructor to prevent a plugin from working if it an expected dependency isn’t loaded.

Though I don’t consider this particular strategy a problem for a one-off dependency or in certain situations, there are ways this can lead to code smells.

It also prevents us from using a native feature of Core called WordPress subactions:

https://twitter.com/JJJ/status/822265137935646720

But before looking at subactions, I want to make sure I’m clear around the problems using the conditional approach (versus subactions) can breed with code smells.

Continue reading

If you approach a lot of WordPress plugin development from an object-oriented perspective, then you’re eventually going to hit a point where you’re not doing a lot of interaction directly with WordPress core itself.

And, in my mind, that’s a good thing. It’s a sign of an architecture that you’re properly structuring your code. That is:

1. You have WordPress sitting at the foundational level,
2. You have a set of classes that are sitting just above WordPress responsible for sending information to and from WordPress between the plugin,
3. And you have the rest of your code that comprises the rest of the functionality.

How this is implemented can vary, but the general way I picture this is the same way I tend to think of the standard N-tier application where you have the data layer, application layer, and front-end.

Except for this time, you have the WordPress, a layer for communicating with WordPress and the rest of your code, and, you know, the rest of your code.

How a plugin may be organized.

So what happens when you want to stop plugin execution when it has to interact with a third-party dependency and should only execute if that dependency is present?

Continue reading

One of the ways that WordPress plugins come to be is that, at least in my case, they start off as a collection of functions used to help with a particular purpose for a given project. From there, you think “Hey, maybe someone else will find this useful.”

At least that’s been my experience more often than not.

But the thing is that before you release it for other people to try, you want to go through the process of cleaning up the code. I’m not talking about refactoring WordPress plugins, either – at least not yet.

I’m talking about taking the code, bringing it up to something that will work as a WordPress plugin, and then possibly refactoring the code.

Continue reading

This past weekend, I spent time closing a bunch of sites, exporting content from one service to another, preparing to consolidate a couple of sites, and even shutting some sites down.

But the number one thing that has resulted in a weird bit of feedback is the idea that I opted to archive my data from Medium in preparing to move it to a WordPress-based site. This resulted in some weird WordPress versus Medium points from others.

Truthfully, I know this kind of argument will never die. But I digress for now.

And, I suppose, the reason this is weird is that I – like many who use WordPress – want the control that comes with owning your data. Perhaps it’s also about playing in someone else’s sandbox, too, right?

But there’s an inherent problem with sticking only with one CMS and neglecting what the rest of the industry is doing.

Continue reading