CaptainCore 
CaptainCore runs commands like backup, update, quicksave and scan-errors across many WordPress sites on a scheduled basis in the background. Until now there hasn’t been any way to see any progress in the UI. That makes it really difficult to know what’s still running and how long it’s taking. To solve this I’m introducing a new global argument --progress which can be used on bulk commands to track progress. Before I can go into how this works technically, you can see it in action here.
New bulk command to run commands in parallel with lightweight progress tracking.
Many of CaptainCore’s CLI commands already had support for parallelization, however, there was no standard way of handling it. That’s why I created captaincore bulk which is a common way to run commands in parallel with a few additions – like progress tracking. I may expand on this later, but for now, that tracking is very basic. It simply shows the progress of how many sites have completed out of the total number of sites selected as shown above.
Using inotifywait, log files and web sockets to create a realtime interface.
Using the new --progress argument will generate a new process log. Here is an example of what those files look like.
{"process_id":"14870","command":"scan-errors @production","created_at":"1606493446","count":"1251"}
..........................The first line tracks info about the command. The second line containing periods tracks the completed sites. In this example, you can see the command will run on 1,251 sites. It’s currently completed 26 sites as represented by the 26 periods. Since the bulk command is running these loops concurrently there is no way to know the order the site will run, hence the need for some way to track progress.
In order to see the data in realtime a websocket is connected to captaincore running listen which uses inotifywait to listen for process log file changes. As files are added or updated it runs the files through a PHP script to generate status updates on the web socket.
{"command":"ssh @production --script=\"deploy-helper\"","created_at":"1606493446","process_id":"14869","percentage":"13.03","status":"163 \/ 1251 completed","completed_at":"1606493602"}
{"command":"scan-errors @production","created_at":"1606493446","process_id":"14870","percentage":"3.52","status":"44 \/ 1251 completed"}This lays the groundwork for scheduling scripts.
I currently manage a schedule of background commands with Crontab like the one shown below. This isn’t very flexible as it’s globally defined for everyone’s group of sites. I’d instead like to move these configurations to be configurable per captain, the administrator of a group of sites. That would allow other CaptainCore alpha users to run a custom schedule from what I run over at Anchor Hosting.
*/10 * * * * captaincore monitor @production --fleet
01 00 * * * captaincore quicksave @all --fleet
45 18 * * * captaincore scan-errors @production --fleet
15 09 * * 3 captaincore update @production.updates-on --fleet
15 0 1 */3 * captaincore update @staging.updates-on --fleet
03 00 * * * captaincore backup @production --fleet