#5426 - Do not use calendar system commands wherever possible

  • By
  • Added
  • 11 views
Identifier #5426
Issue type Feature request or suggestion
Title Do not use calendar system commands wherever possible
Status Open
Tags

Roadmap: Over the horizon (custom)

Handling member Deleted
Addon calendar
Description The Composr CMS scheduling system (via calendars) is one of the most unreliable I've seen in a CMS and presents too many points of failure for it to be considered "reliable".

More often than not, when I try to schedule something, it fails to work properly. This has caused significant problems especially considering clients use Composr and want articles to go live at times I cannot be awake.

Overview... the calendar system has several points of failure:
a) CRON not running or not configured properly (though this is easily a failure point for other systems... can easily be detected via staff checklist and health checks)
b) Improper time zone conversions (not unique to Composr but is an uncommon problem outside Composr, but because calendar events use the time zone of the user, I had an incident once where the time zone on my profile was not what I thought it was, thus the calendar did not run when it should have. Can NOT be easily detected.)
c) For system commands, wrong code typed in (Unique to Composr and VERY easy / common to happen. This is the biggest reason why the system is unreliable. Can NOT be easily detected.)

Solution:

a) Wherever Composr internally creates a "system command" calendar event... stop doing that. Instead, migrate those to a new CRON / scheduler hook. Example: publication date/time for news and blogs. See issue #5425 . While moving this functionality to the unvalidated addon, perhaps instead of tying it to calendar, have a new table that tracks content type / ID to the date/time they should go live. And a CRON hook regularly runs and validates content set to go live (and then cleans them from the table).
b) Create a validation system for problem c; when the calendar type is "system command", upon saving, a validation should run to ensure the system commands contain no typos and will run as expected. If validation fails, it should error / prevent saving until fixed.
c) for problem b, state what the user's current time zone is in the help tooltips for the times on adding/editing a calendar event.
Steps to reproduce

Additional information To make solution b work, we need to consider several things:

1. Calendar system commands should migrate away from using raw PHP whenever possible and instead use commandr commands.
2. When we do use raw PHP, we might need to make our own PHP code validation tool because I believe PHP only validates on runtime. The PHP command line could possibly be used.
3. Commandr commands need new validation methods in their hooks which, just like running, take in all the passed in parameters and options, but instead of running, will return whether the command is valid or not (and if not, shows what's wrong). Ideally, these validation methods should easily tie into the actual run / actualiser so validation can run prior to execution as well.
Related to

#5425 - Move publication date/time feature to unvalidated addon
Funded? No
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".

Rating

Unrated