To continue our theme of making WordPress your next enterprise deployment (Check out our two previous articles… WordPress In The Enterprise – Building In A Class Library and WordPress In The Enterprise – The Functions File) we will talk about how we can go about organizing your code so that it can have “bolt on services”. WordPress has a ton of extensibility capabilities which make it ideal for plugins and to add in whatever service they want. However, this mechanism may not exactly fit all scenarios you need. Perhaps you don’t have the time to re-code everything into a proper plugin. We will talk about one mechanism, that I have used exclusively, that makes it easy to build your own services right along side WordPress and has worked out nicely for some of my enterprise projects.
These would be services you might have had in your previous platform but didn’t exactly want to make into their own plugins. They may be services that are utilizing classes from your new class libraries (talked about earlier) that would borrow from WordPress but not exactly be part of WordPress. The term “bolt on service” is just what I am calling a service that sits next to WordPress but isn’t a plugin. With plugins you would have to create the folder in a specific place of the file hierarchy, add a header to have WordPress pick it up through the plugin admin and follows WordPress coding practices. All which are good, but may require you to re-code or re-engineer code to bring it into the WordPress world. Some of us just don’t have time for that. Not to mention why rewrite code that has been battle tested and customer approved?
You might ask, why would you do such a thing? As briefly mentioned in the opening paragraph, the code you use in a service may already exist and would have very few touch points to the underlying WordPress infrastructure. Something that might provide an API of some sort, perhaps it provides OAuth (which was our first such service) or even a file uploading service. You might want to expose new endpoints that work directly with the database but only use the $wpdb (WordPress Database Object) to do it. I found that creating a service that leverages classes like $wpdb extremely helpful since the WordPress database object is a rather nicely designed class that is already made and tested. Why not utilize it?
Not to mention that your service may already have a well defined file hierarchy that you don’t want to change (or simply can’t change). By simply having the code sit next to the WordPress install with minimal dependencies, you can utilize WordPress functionality without being as tightly coupled to it as you might be with a plugin.
This is how we structured such a setup in our project…
As you can see, we have created a folder we called “services” and put it right next to the WordPress common folders. By putting it here, we can now access code using https://hostname.com/services/
With this method we have already begun building out several services that provide interaction with the website and yet live completely outside of it and outside of the world of plugins. If your code is rather simple and easy to flip over to being a plugin, that might be the best way to go. However, since we are using code that was designed outside of WordPress and doesn’t know anything about it, we were able to make a few tweaks to have it work alongside WordPress without having it muddy up the waters for users, editors, admins etc of the WordPress install.
One last advantage I will mention (there are certainly many) is that our bolt on services can still easily leverage our class libraries. If you read the previous two articles, where we built the class libraries, we designed a general overarching class library that can be shared across both the WordPress install and our services. Just as easy as it was to bring in our ready made enterprise classes into WordPress, we can also borrow them for the services as we need to. You could even leverage the same type of autoloader.
Since the library sits one level up from webroot, our PHP can reach up and pull down a class for a service’s use. This gives us the ability to have WordPress and our service both act with one class and thus interact with external sources in the same consistent way. Then we just add more classes to the library and all services and sites win. This also makes it great for debugging by providing a centralized repository of classes and that library can be easily managed in version control.
I hope you have started to notice the general theme here between the three articles we have posted about WordPress in the enterprise. We created a general class library, centralizing and decoupling code and now leveraging that library to create a services folder that can provide a ton of value without being firmly planted into the world of WordPress. We talked about some of the things you can do with such services and advantages like borrowing from WordPress and not needing to re-code everything into plugins. At my company we have leveraged this design to great effect and provided many services from the website. All without needing to touch WordPress core, re-code proprietary well tested code to be 100% WordPress compliant and decoupled enough to allow us to create and destroy services without WordPress knowing any differently.
We hope you found this idea and design enlightening for your own projects. If you are interested in trying out some of the ideas in this blog, please check out our ebook The Programmers Idea Book which features 200 programming project ideas and contains tips, tricks, resources and even a project rating to help you decide what can be conquered in a day versus a week. Many of these project ideas can even be leveraged into services that sit alongside WordPress. So please support us and get a copy of it today! Thanks for reading! 🙂
