There are a lot of reasons that people are excited to have the WordPress REST API merged into core.

I think some are excited because they won’t need to include the plugin dependency anymore; others, honestly speaking, I think are happy to see it merged for the sake of it. Whatever the case, having the entire infrastructure is core is neat, and I’m excited, but almost none of the client work I’m doing at the moment warrant it.

I believe that will change, though, as people learn what we can do with it. But until that time comes, one of the things I like to do is try to think broadly about what could the REST API offer that isn’t directly related to blogging.

And this leads me to a much broader question.

Continue reading

Spend enough time working in WordPress, and you find that a lot of data is often held in arrays (and multidimensional arrays, at that). I’m not arguing whether or not this is a bad thing or a good thing; it’s more of an intermediary step between grabbing something from the database and then rendering it on the page.

As you venture into the world of WordPress development, though, and you aren’t necessarily sure how you want to manipulate some of that data before rendering it, saving it, or working with it, you may ask yourself the following question:

How do I read the associative array values in WordPress?

And if you have experience in PHP, this isn’t something that’s terribly difficult. But if you’re working with an existing structure or trying to extend or manipulate something that already exists,

Look at all the serialized options.

But if you’re still learning the ropes and you start trekking down the PHP manual, you’re likely to find something like array_values or array_intersect_key or something like that only to find out that you’re more confused than when you’ve started.

So what are you to do?

Continue reading

It probably gets a bit tiresome to talk about coding standards, practices, and things like that when you’re trying to focus on simply getting things done.

And though I get it, I also think that having standards and practices – at least within the context of your team – can go a long way regarding being productive, writing maintainable code, and having things in place to help with maintenance over time.

All of that’s beside the point, though. In the last few years, I’ve found that WordPress – at least those who work on the server-side – usually come in two flavors:

1. Those who follow the WordPress Coding Standards,
2. Those who follow the PSRs.

I think there are good reasons for choosing either one. Naturally, I’d say that because I’ve almost always used the WordPress Coding Standards (I have very few exceptions), but I understand the choice to use the alternative as well.

And it’s something I’m beginning to consider doing, too. But I’m curious, for anyone who’s used both or who has an opinion (strong or otherwise) on which one and why to share.

Continue reading

A few posts ago, I talked through the process of creating your custom WordPress admin page (and listed reasons as to why you may want to do this rather than using an existing API). One of the challenges of doing this, though, is knowing how to set up a WordPress admin redirect.

That is, let’s say that you specify some options – or perhaps you don’t – and you need to be able to display a custom message. Or maybe you want to do some processing on the backend and then show the results on the front-end.

Whatever the case, one of the challenges of not using one of the existing APIs is being able to correctly setup a WordPress admin redirect so that it takes the user back to the page they were on, but also does so with whatever messaging you want to display.

Continue reading