Tag: WordPress (Page 37 of 219)

One of the things on the backlog of things that I’ve been working to do is to put together a list of benefits for members. Here’s the thing, though: The WordPress economy is vast, so what one person can do or from what they may benefit is not going to be the same as what another person can do or benefits.

What’s to be done about that?

Regarding providing solutions for the site, the current state of memberships on this site is easy to define:

• offer object-oriented introductions and practices,
• practical tips for how to achieve specific tasks,
• how to apply all the above in your day-to-day work.

But that’s not all I want it to be. In addition to all of that, I also want to provide members with access to software, courses, and more than help them get better at what it is you do on a day-to-day basis.

And that’s what today’s post is about: Finally announcing a couple of benefits for site members.

Continue reading

One of the things that I find myself trying to do on a regular basis is to streamline how I’m building WordPress-focused functionality. I’ve recently talked about this but thought I’d expand on it a little bit more.

That is, I thought I’d lay out the approach I take when building things such as custom post types, taxonomies, meta boxes, and so on.

Generally, think of this as a strategy that I follow for building out aspects of a project that interfaces directly with WordPress but may require a few components such as:

• classes that register themselves with WordPress through various hooks,
• classes that require calls to certain WordPress APIs
• and classes that require a custom view.

Sure, not every thing that interfaces with WordPress will need all of the above (for example, does a custom post type need a view? No. But a meta box does.)

Continue reading

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