Photo by alx_chief
A disclaimer: This post doesn’t have anything to do with the core team or their roadmap.
As anyone doing software development, when we have questions one of the things we have to do is use a search engine. The documentation in WordPress can sometimes be extremely vague, or at times there are situations where a hook or filter I need exists but I end up recreating the wheel just to be annoyed that it’s already there and my time has been wasted.
One of the things that really stood out is the amount of really, really bad recommendations because some of the answers are copy/pasted from other answers and of course maybe the person writing out the answer hasn’t come to the realization that WordPress way of naming their hooks and filters can come out as vague.
And to know surprise I’m talking about:
The is_admin() function is meant to just check if you are within the administrative interface. But given the rather free and exposed nature of WordPress it’s also a function that could have unintended effects. For example, Some plug-in creators doesn’t develop plug-ins with security in admin, I’ve noticed with a plug-in that I use that anyone could literally change the configurations of my plug-in as long as he/she is registered.
But the problem goes deeper. The workflow that WordPress has introduced over the year is a bit convoluted. A plug-in is literally a free soul that is attuned to the environment, it’s a vacuum that receives all types of requests.
is_admin() while it is an offender doesn’t cover the next thing. Some plug-ins aren’t aware of AJAX/RESTful calls so they end up blocking the calls because the plug-in is expecting the call to be done while a user uses the admin interface but that may also break features that are meant for the public, depending on how things have been laid out.
I feel like while WordPress does tell the developer “hey, you can use this to achieve this”, it doesn’t instruct the developer on “hey, that’s cool you are using our hook/filter but before all that you should check out documentation on security and understanding the functions you need to safely provide resources to your users.”
But it’s not only a thing about security. Like I said, a plug-in in WordPress is a free soul. It listens to all requests, meaning the developer has to devise a way to tend to the needs of:
- public requests
- private requests (within admin)
- public (ajax/RESTful)
- private ajax(RESTful) (within admin)
That aside for a moment, I have actually enjoyed my time developing my plug-in. I can’t actually wait to use it in the public myself but it’s under heavy development.
One of the things I love is how flexible/extensible/versatile WordPress do things. It takes very little effort, or any at all! But as all things, it’s also super easy to mess up your code and leave yourself wide open to attacks.
And I fear that while WordPress has vast amounts of plug-ins out there the bigger question is how many of them are secure?
Would the fault lies with WordPress core team not communicating things? Would WordPress StackExchange need to go on a purge to flag all high risk answers ?
It’s food for thought honestly. Personally, we are already here, and I’ve seen their new documentation and it’s amazing but the people who are writing plug-ins may not be aware of such documentation and maybe being more vocal about security isn’t a bad idea.