Author: Tom (Page 142 of 430)

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

When using WordPress, it’s one thing to set the WordPress user role using the provided interface. And this is what we do if we’re working as administrators of a particular site.

But say you’re working on a project, you need to import users and, as part of the process, set the WordPress user role in the context of the import process.

This could come as importing a new user, or it could come as updating an existing user. It doesn’t matter so much as there is a need to set a user role with working with a user.

The WordPress API makes this pretty easy, but there are two things to understand that, if missed, can result in basically overloading the user with multiple roles.

Here’s what I mean.

Continue reading