Automate CleanTalk Anti-Spam Updates for WordPress
If you serve a couple of sites, then updating the plugins does not cause any difficulties. Difficulties arise if you serve several dozens, or even hundreds of sites.
CleanTalk Antispam requires frequent updates (we have to release a new version every 1-2 weeks), there are many reasons for this.
WordPress, as a constructor, has a huge number of plugins, themes, widgets, etc. which are not always designed with WordPress Codex in mind, have a different architecture and event handling. Therefore, CleanTalk integration errors may occur with various components, especially rare ones.
Every complex service that uses a large amount of data, a change in the backend, changes in the logic and a lot of other things require changes in the plugin.
At our update frequency, the plugin requires the auto-update option. If this option is done in the plugin settings, then anyway the user will need to go to each site in the plugin settings and install it. But what to do in a situation where the user does not want to enable auto-update, but you need to update the plug-in immediately on hundreds of sites?
For the convenience of managing the service, the auto-update option was implemented in the Service Control Panel.
Auto-update allows you to update the plugin one-time on one site, a group of sites, or enable auto-update on all sites.
Historically, we control the version of the plugin used by the client, and when contacting clients and analyzing feedback, we need to know the version of the plugin used. Each anti-spam plugin, with each request, sends its version in the parameters. The version number is compared with the number in the repository, and if the versions are different, then in the Control Panel we show a warning about the need to update.
Further, when you click on the link, a modal window opens with update options.
When choosing the option, the server makes a special request to the plugin on the client’s site.
The plugin, having received the call, checks the call parameters for authenticity and starts work. Auto-update is implemented through a modified WordPress plugin auto-update class. After the class completes, the plugin checks the version of the updated files and makes a request to the site (on itself). If the HTTP response code is 200, then the server reports this to the “OK” page and makes a special API call, reporting on the new version. If the response code is different from 200, then the plugin rolls back the files to the previous version and answers the north with a line with the error code and technical parameters.
After a successful update, the status in the Service Control Panel changes to “App has been updated”.
CleanTalk Antispam requires frequent updates (we have to release a new version every 1-2 weeks), there are many reasons for this.
WordPress, as a constructor, has a huge number of plugins, themes, widgets, etc. which are not always designed with WordPress Codex in mind, have a different architecture and event handling. Therefore, CleanTalk integration errors may occur with various components, especially rare ones.
Every complex service that uses a large amount of data, a change in the backend, changes in the logic and a lot of other things require changes in the plugin.
At our update frequency, the plugin requires the auto-update option. If this option is done in the plugin settings, then anyway the user will need to go to each site in the plugin settings and install it. But what to do in a situation where the user does not want to enable auto-update, but you need to update the plug-in immediately on hundreds of sites?
For the convenience of managing the service, the auto-update option was implemented in the Service Control Panel.
Auto-update allows you to update the plugin one-time on one site, a group of sites, or enable auto-update on all sites.
How it works
Historically, we control the version of the plugin used by the client, and when contacting clients and analyzing feedback, we need to know the version of the plugin used. Each anti-spam plugin, with each request, sends its version in the parameters. The version number is compared with the number in the repository, and if the versions are different, then in the Control Panel we show a warning about the need to update.
Further, when you click on the link, a modal window opens with update options.
When choosing the option, the server makes a special request to the plugin on the client’s site.
The plugin, having received the call, checks the call parameters for authenticity and starts work. Auto-update is implemented through a modified WordPress plugin auto-update class. After the class completes, the plugin checks the version of the updated files and makes a request to the site (on itself). If the HTTP response code is 200, then the server reports this to the “OK” page and makes a special API call, reporting on the new version. If the response code is different from 200, then the plugin rolls back the files to the previous version and answers the north with a line with the error code and technical parameters.
After a successful update, the status in the Service Control Panel changes to “App has been updated”.