Because WordPress is built using a number of languages none of which are compiled, it makes it completely possible to make things happen within your theme, plugin, or extension by circumventing the native APIs.
This means that if you wanted to, say, introduce some type of element on one of the dashboard screens or you wanted to introduce functionality into one of your templates that didn’t previously exist, there’s a strong chance that you’d be able to do so simply by “brute force.”
And by that, I mean that you’d be able to make something happen – and probably work correctly – without using the native set of APIs that are available.
But when you’re faced with that situation, I highly recommend taking a step back and determining if you’re approaching the problem in the best way possible given your set of constraints.
The Constraints of an API
Regardless of what languages, frameworks, or platforms that you use, every one of them – Laravel, Rails, .NET, Zend, etc. – provide their own set of libraries and APIs each of which help to make our job easier (or harder depending on the nature of which one we’re talking about, but I digress :).
These APIs ultimately form the constraints in which we work to solve our problems. They help us to frame our mode of thinking such that when we approach a problem, we do so with the set of guardrails given to us by the platform that we’re using.
How Does This Factor Into WordPress?
When it comes to building themes, plugins, extensions, or even web applications, I’ve yet to find a case where an API didn’t exist that allow me to do what I wanted to do, but there are plenty of opportunities to bypass the APIs and I’ve seen more than enough examples of others doing exactly this.
Honestly, I did the same thing in the past when I didn’t know any better (don’t we all?), but one of the biggest pieces of advice that I can give to people who are working with WordPress – or any platform, for that matter – is to familiarize yourself with the Codex and the various APIs that are offered.
This will contribute to how you approach the solution that you’re working to implement. If you end up finding yourself in a situation where you’re trying to use an API to solve a problem and you can’t get it to work, then take a step back and look at the work you’ve done up to this point.
Odds are, there are other shortcuts that have been taken, methods that have been implemented, or other code that’s been written that is preventing you from using the native functionality. And if that’s the case, then it calls for a refactoring of what you’ve already written.
There should be no shame in this either (though we do love to call out others, don’t we?) – we’ve all been there at some point. But it always comes back to us trying to get better at what it is that we’re doing.