WordPress messages, especially custom messages, are becoming a bit of a sore spot for developers, bloggers, content managers and so on.
And with good reason: It seems like every plugin has this desire to display tooltips, messages, promotional content, and so on every single time it’s activated or updated.
WordPress Messages aren’t inherently bad, but they’re abused. Still, they serve a purpose and can (and arguably should) be used sparingly when the opportunity presents itself.
In a series I’ve been working on for Tuts+, I’ve been walking through the process of creating a custom system for implementing, displaying, and customizing WordPress messages.
And how to do so in a way that’s reusable across various projects.
PHP autoloading is a topic that, once you’ve begun to employ it in your projects, is hard to avoid doing so in any project moving forward.
The challenge with learning how to do it, though, is learning aspects of object-oriented programming and what facilities the PHP standard library has to offer. On top of that, there are other advanced tools like Composer that make it possible, as well.
You have to walk before you can run, as they say, so in a recent series on Tuts+, I walk through how to perform PHP autoloading using object-oriented programming in the context of WordPress.
It’s not hard to find criticism about namespacing and autoloading in WordPress, and lack thereof. As much as I’d like to see it, I think it’s important to take a practical look at the software as a whole, the requirements, and realize that implementing such organization would require a lot.
Specifically, it would require applying object-oriented programming throughout the entire codebase (which would last longer than a release cycle in and of itself).
It would also require that all hosts who support WordPress on any level (yes, even those supporting legacy versions) can handle the new features.
In short, it’s not an easy task and it’s important to recognize the practical challenges that come with doing so in 13 year old software powering approximately 25% of the web.
It’s not that it can’t be done, that it won’t be done, that people don’t want it done. But it’s requires exceptional planning, execution, testing, and support from a wide array of situations that I don’t know if I can even fully grasp.
With all of that said, though, this doesn’t mean that we can’t use namespaces and autoloading in our WordPress projects.
Custom admin pages in WordPress are one of those things that aren’t often needed if you’re using something like the Settings API, the
add_menu_page function, or a similar API function.
And in many, if not most, cases all of the above suffice; however, there are times where you need more control over what’s displayed to the user, how the input is handled once it’s submitted, and then what’s returned to the user after the data has been saved to the database.
In those cases, it’s helpful to know how to write custom admin pages in WordPress and all that comes with it – from sanitization, custom error messages, validation, and page redirection.
Creating custom WordPress administration pages isn’t always necessary if you’re going to use something like the Settings API. But if you’re working on a feature for a plugin or something that extends WordPress core in a way that requires more flexibility, it’s something that may be useful.
In some respects, it gives you more control, but you may also need to work on writing your system for displaying messages in the administration area, handling sanitization and validation, and so on.
It’s a lot to consider, and there’s a variety of use cases. In my latest series on Envato, I begin walking through some of the foundational requirements for working on custom WordPress administration pages.