Tag: WordPress (Page 59 of 220)

Articles, tips, and resources for WordPress-based development.

On Immutable Values in WordPress Plugins

May 31, 2017 / Tom / 0 Comments

If you’ve done any work – or even any reading – on object-oriented programming, then you’ve likely come across the idea of immutability. That is the idea of something being unchanging.

Sometimes you can have immutable values, and sometimes you can have immutable objects (at least after they are instantiated).

The opposite of immutable (but he was my favorite ninja turtle, anyway).

The thing is, the more I work with object-oriented code, the less I tend to work with immutable variables. Sure, I’ll use constants as defined in a configuration file, but you’re not likely to find me storing values within a class as a const.

That probably implies something about me and my abilities, but it’s true. Thankfully, code reviews are great at helping you see opportunities on where to leverage strategies you normally wouldn’t. And such is the case with immutable values in WordPress plugins.

Of course, this is one of those things that was brought to my attention by a friend when reviewing my code.

Sending Secure Ajax Requests in WordPress (with Nonces)

May 30, 2017 / Tom / 0 Comments

I know that the REST API is a huge topic of conversation in WordPress right now, and rightfully so, but there are still times in which we have to use admin-ajax (as its coming to be known) for a variety of reasons.

Perhaps it’s an application,
Perhaps time doesn’t allow for creating the necessary endpoints,
Perhaps you’re more comfortable with admin-ajax,
And so on.

Regardless of your reasons for why you use it (which I still do, for whatever that’s work), I think it’s important to make sure we’re sending secure Ajax requests in WordPress using nonces just as you would if you were submitting traditional form data.

Legitimate, live shot of wires carrying your Ajax request.

If you search the web for results on how to do that, you’ll come up with a variety of answers, and this will be just another drop in the proverbial bucket.

But if you’re curious for a recipe for how to handle it, this is how I do it each time.

Rapid Prototyping: Introducing Autoloading

May 26, 2017 / Tom / 0 Comments

Over the last few posts, I’ve walked through the process of taking an idea from concept to prototype.

Granted, there are some things that you might change (and there are some things I’d change regarding organizing classes). But the point of the series isn’t to walk through all of the various object-oriented techniques that can be used to create a solution.

Instead, it’s about taking a prototype and converting it into something a little more professional. There’s still one thing that we need to do, though.

Right now, we include all of our files through require statements. And this works alright for small files, but introducing autoloading in conjunction with namespaces can make the application even cleaner.

And that’s what we’re going to do.

Rapid Prototyping: Prototype To Code, Part 2

May 25, 2017 / Tom / 0 Comments

The previous post demonstrates a lot of work in taking something that was once a rapid prototype and taking that prototype to code. If you haven’t been following along, we’ve done the following:

talked about and built a prototype for a plugin,
diagrammed out one object-oriented approach may work,
and refactored our prototype to actual code.

At this point, there are a few more things we can do to improve our code. Namely, we can introduce the concept of namespaces. This takes the organization a step further and can pay dividends for larger projects.

So here’s a look at how this plays out in our current project.

Rapid Prototyping: Prototype To Code, Part 1

May 24, 2017 / Tom / 0 Comments

As far as rapid prototypes and WordPress are concerned, we’ve done two things thus far:

At this point, we’ve done enough work to warrant beginning to refactor our code. That is, we’re going to start converting the prototype to code. But this is something that’s going to need to be done in two phases.

First, we’re going to simply introduce classes that represent the diagrams from the previous post and that encapsulate the responsibility of each project.

After that, we’ll look at organizing the code into namespaces and packages. Before we can do that though, we need to make sure the code is object-oriented and remains functional. So that’s what’s going to happen in this post.