Tag: WordPress (Page 38 of 220)

One of the things that I find consistently interesting (both from a programming standpoint and from a WordPress standpoint), is this:

I like keeping code separated such that code responsible for interacting with WordPress is relegated to its namespace while the rest of our code is namespaced appropriately elsewhere.

I think this is obvious, though.

When it comes to writing code, though, this doesn’t mean it has to be left simply to the how we write our classes and then organize them. What about things at a slightly more granular level?

That is, what if we were to look at methods as part of the larger whole and make sure they’re doing their job well, too? Sure, people like Bob Martin have been writing about this kind of stuff for the majority of their career and preaching it to people like us.

But these concepts are something that you simply start doing and then apply them for good. Paradigms shift, we’re better today than we were yesterday, and there may be multiple ways to achieve the same kind of thing.

So when it comes it comes to creating readable WordPress functions for a specific domain, what might that look like?

Continue reading

Anytime sometime starts to get into more advanced programming – be it in WordPress or any other framework, library, foundation, or programming language – there are times in which new concepts can often be more difficult to understand than others.

I generally have found this to be true whenever a person has learned the basics of, say, object-oriented programming but hasn’t been exposed to the nuances of certain things such as design patterns.

Case in point: I’ve written about the event-driven design pattern (or the publish-subscribe or Pub/Sub as some like to refer to it) in other posts.

Yes, there are some differences to each, but the general idea is that something happens and an event is raised and anything listening for that event, or subscribed to that event, will respond.

Photo by Claus Grünstäudl on Unsplash

This is the primary pattern that WordPress employs that allows us to quite literally hook into certain points of execution. We can generally conceptualize these as action hooks in WordPress.

Anyway, the application makes certain points available for us to add our own functionality. Once that functionality is registered, WordPress will leave its codebase, so to speak, hop into ours, then return back to ours.

It’s easy enough to understand, but what if you want to expose areas in your code that allow others to hook into your code?

Continue reading

If you’ve ever had to work with resizing images programmatically in WordPress, then you may have come across the image_resize function.

Further, you may know it’s been deprecated (given that this appears at the top of the screen):

This function has been deprecated. Use wp_get_image_editor() instead.

And with its deprecation, as is true of all those who do a good job deprecating functionality, it’s not without its replacement.

In this case, we’re talking about the WP Image Editor. This is a class in WordPress that we can use to perform the same operations to go about resizing images programmatically that we once could with the original function.

Continue reading