I have a lot of self-written plugins for a lot of customisations, and each site I own and operate has its functionality plugin, too; I regularly need to update these functionality plugins as things change or I modify my stack and I deliver these updates using two items from https://github.com/YahnisElsts
Firstly, I have a private repo update server running https://github.com/YahnisElsts/wp-update-server, and I also have https://github.com/YahnisElsts/plugin-update-checker within the plugins and within my utility plugin, which acts as a universal update server.
With these, I am able to deliver updates for my own plugins, ones I download from GitHub, and premium plugins, some of which I modify “bypassing the normal update behaviour” of those plugins and delivering my updates so that their own updates don’t remove the customisation.
This has worked really well, and using the same repo I have written additional functions to my utility plugin that allow me to install those both as bundles and individual items. You can see the additional items added to the plugin installer below [My Repo & Bundles]. This uses a custom API that scans the update directory to serve me files I can install.
One of the improvements I’ve wanted to make to this setup is increasing security for both updates delivered via the systems and files installed on my sites. This is a common request on the update threads, and one of the reasons behind this is that if I am to start offering “care plan” services, I need some form of protection for the updates.
Now, when it comes to modifications, I try to make the minimum number of updates to actual files. The reason for this is compatibility. I’ve had to make changes to the actual files before, and it makes updating the server difficult,t so I set about to put some time into streamlining the level of modification needed to the actual updateserver files.
I decided rather than directly modify the update server and create issues for future me., I wanted something that worked with the stock version of the update server, well, my edited version, and after a few hours of testing and working, I settled on a man in the middle interface to take user/update requests and check with the server and pass them on, and this is now working, it has the ability to filter requests in a several way’s a whitelist a blacklist and a bypass.
So what does this mean?
- White List: means we are checking a domain or ip is on the list
- Black List : NO ACCESS at all for this domain / IP
- Bypass: Add Domains / IPs where an API check doesn’t happen, allow you to use just domains or ips rather than just API or API and Whitelist
- API key: This is where your API / Licence Keys would be stored.
Based on the response, it will then serve the update or not. There is no formatting. It uses direct comparison, so it is expandable and workable. For example, if your Licencing server has an API check them against it and then server the update.
I’ve made some changes to the default update server and you can view them here https://github.com/stingray82/wp-update-server-modifications this is what runs within my update server.
The new guardian is a way to offer some additional security with API checking you could again increase this with the in build function to expand within the base update server.
You can get a copy of WP update server guardian here https://github.com/stingray82/wp-update-server-guardian
