Create PHP CLI Tool

[crossan007]

Create a PHP CLI application to provide an "easy" mechanism for various maintenance tasks:

• Resetting the admin password
• System health check
• Backup/Restore
• Kicking off Timer Jobs

This concept is implemented extremely well by the OwnCloud development team, and I think ChurchCRM could benefit from a similar implementation.

[crossan007]

@MrClever I'd like to see your thoughts for this - are there any tasks I'm missing?

[MrClever]

I can see this being a valuable tool for system admins, as you allude to. Some functionality I can also see being useful:

• Mass email events, eg. bulk verification email triggers etc.
• Directory creation, eg. being able to generate a PDF directory from a set of parameters on a regular basis. Current process is a manual "click-fest" to set all the parameters which only gets downloaded to my computer - automation FTW!
• Debug data packaging, eg. grab the logs/YYYY-MM-DD-app.log and apache error logs along with scraping internal application state (like all the info on the debug page) then dumping it into a nice neat tarball/zip file for sharing with devs etc.
• Manual upgrades when the in-app notification system breaks (seems to affect a number of 3.5.5 users, and it happened in the early 3.0 releases too). Would also make it possible to automate upgrades...for those of us who like live dangerously 😳
• Tools for importing/exporting data in a scripted way (load/dump CSV/JSON files etc). Especially the MailChimp stuff - being able to dump that from a cron job etc would make it trivial to automate keeping CCRM/MailChimp in sync, or any other mail list tool/system for that matter.
• Calendar stuff, eg. being able to programatically add events from external triggers (email scraping, cron jobs, CSV/JSON files) etc. without needing to do the full API interface "thing".

[MrClever]

While I'm pondering this, would it be worthwhile allowing admins to configure how background jobs are triggered? For example, in the configuration have a setting to toggle the background tasks "in-browser" or "via cron" etc? The reason I'm pondering it is in part a result of the "API error" tickets we get regularly which seem to be a result of spikes in long-running DB connections in the browser. Running from a cron job might mitigate this and allow tighter control over how many DB connections are used. A scripted background cron job could just chug away in the background slowly sipping from a single DB connection and still get the job done, as opposed to the need to quickly execute "in-browser" to avoid artificial lag etc.

[crossan007]

Great expansion on what I meant by the final bullet point in my original issue text: Kicking off Timer Jobs

The cron job approach is also more conducive to supporting things like "sending scheduled emails / notifications" (doesn't exist now, but it conceivably could)

[MrClever]

Email notifications would be really handy from both a user and admin perspective. Case in point; it would be helpful for admins and/or users to be notified if their account was locked due to too many password attempts (cough for example cough). Also notifications for various success/failure situations would be handy too.

[crossan007]

I was referencing calendar or otherwise "scheduled" notifications.

Event-driven items like failed logins are already feasible given the architecture.

[dleigh]

just chug away in the background slowly sipping from a single DB connection

Oh yes!

I also like the idea of either having the single cron chugging at the frequency I want handling only thing things I want done (we don't use MailChimp at the moment, for instance)

OR

Allowing multiple cron jobs that run at different frequencies to handle differing tasks that don't require the same frequency.

Whether this is with a CLI (wp cli in WordPress also comes to mind) or simply via a URL query string api is something for you all to work out, as to which is better. I suppose if someone didn't have cron on their hosting but could fire off URL requests from their own "back office windows machine" using scheduled tasks, the URL method might be more flexible for them.

At any rate I appreciate the effort you all are making to improve this!

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 15 days with no activity.