Hi. I noticed in XF 2.0 all Cron entries state "Only a limited number of fields in this item may be edited", by which it means none (other than title). At first I thought it was just locking this down for built-in XF Cron jobs, but it's actually all of them, including 3rd party add-on jobs. What is the point of having scheduling options if you can't schedule them (e.g to avoid overlapping, avoid backup windows, increase frequency, etc.)? Seems like a bug.
XF 2.0 Edit Cron Entry: "Only a limited number of fields in this item may be edited"
- Thread starter rfc0001
- Start date
They are not editable because on next upgrade, your customizations will be overwritten. The definitions are essentially owned by the add-on. There are a lot of similar concepts in XF.
You can enable/disable individual cron entries (this is really the one thing that is editable) and create your own versions of the other ones using the setup you prefer, though you do need to understand the significance of this if the core/add-on entries change in the future (what they call and the schedule of calling) as you won't get those changes any longer.
You can enable/disable individual cron entries (this is really the one thing that is editable) and create your own versions of the other ones using the setup you prefer, though you do need to understand the significance of this if the core/add-on entries change in the future (what they call and the schedule of calling) as you won't get those changes any longer.
AndyB
Well-known member
What is the reason for this? I can understand for example if core crons would be overwritten, but why not retain third party add-on customizations when upgrades done?
I'd be fine with losing the customizations. It's probably good to restore them to default with each upgrade, then only advanced users who know what they are doing will reapply their customizations. Same as Template and Phrase customizations. That's better than not being able to customize them. I guess the best approach is just disable the default one and add a duplicate job if you want to customize it
Not doing this could potentially lead to things being broken when upgrading (such as a cron not running). Core and third-party add-on code is literally identical in this context (the core stuff is just from an add-on called "XF").
That is the recommended approach.
Editing cron schedules really is an advanced system. Depending on the cron involved, changing the schedule may either not do what you're expecting or (theoretically) cause potential issues, though that shouldn't be true of most tasks. It isn't really expected that 99.9% of users would be making changes here.
AndyB
Well-known member
For add-ons this perhaps is not that big of a deal, the add-on would have stopped working even before the upgrade.
The problem I'm seeing is this, take for example a email add-on which sends emails, the cron is set to my ideal time, lets say 4:00 AM, but that is for my timezone. Those that use my add-on would also like to have the cron run early in the morning, but due to their timezone it's running at a different time. Is there a solution for this issue?
Thanks for confirming
Personally, I have a spreadsheet of all the default timings, and which ones run hourly, daily, etc. then I adjust the timings so a) none of them overlap and b) none of them run during server maintenance/backup cron jobs, while preserving their order, frequency and general timing. Also, there is certain functionality performed by first and third-party Cron jobs where you want to control when/how often certain functionality occurs. I have all this documented, and know what and why I changed them, so can easily reproduce them if an update resets them. Granted most people don't know/care about them
.Is this the same reason why I can´t run crons manually? Really missing the option to be able to run a cron manually while testing add-ons.
I don´t really know what has changed from XF1, that crons are restricted now. But since I have a huge load of custom crons resulting from add-ons, mail applications and feeders this is really making me headaches regarding an upgrade of my primary site. I doubt that I am the only one in this situation and, like Andy, I´ld like to know wether there is solution to this. With uneditable crons I´m kinda stuck here since it´s affecting the whole setup of the page and how it works now. Not talking about the XF core crons. But when it comes to add-ons I´ld have to setup new crons for each one I`ld like to have different settings for and disable the default I can´t edit. While I am sure you had a good reason to restrict cron-editing and the manual run, I am not sure if this is intended. Isn´t there another way, Mike..?
The only reason a cron can't be run manually is if the add-on is disabled. There's a note about this under the cron entries in question on your screenshot.
Yes, this is how you should do it, if these adjustments are significant to you. Generally, this is how you should have done in in XF1 as otherwise your changes may be wiped out unexpectedly (any time you upgraded).
If add-ons are expecting you to edit cron run times as part of their normal operation, that isn't really an expected use case and they should consider a different approach. (The core uses several different approaches that can be referenced, such as custom job queuing or more frequent triggering with checks before work is done.)
