[#43490] - [6.0] [BC Break] Web cron scheduler does not tigger tasks at all
- Closed
- 25 Jul 2024
- Medium
- Build: 5.1-dev
- # 43490
- Diff
- zero-24:webcron
User tests: Successful: Unsuccessful:
Summary of Changes
Make sure the Web cron scheduler does actually tigger tasks
This has been rebased against 6.0-dev as the change is a b/c break. The reason is that right now the recommended URL is "id" that ID check does not work as the ID is set to the default article id when not set via the URL thus the code following it fails. Thats the reason it has been moved to taskid which also makes more sense.
Testing Instructions
- Setup 6.0-dev
- System -> Scheduled Tasks -> Options -> Disable Lazy Sheduler
- System -> Scheduled Tasks -> Options -> Enable CRON Sheduler
- Trigger the CRON Sheduler for example via curl or other external tool
- Notice that nothing will be triggered
Actual result BEFORE applying this Pull Request
Before the patch the triggered method requires an $id to be passed which is not aviable when calling it from the web cron
Expected result AFTER applying this Pull Request
With that patch we are taking the code from the CLI Runner and trigger the tasks based on priority one by one.
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org: joomla/Manual#286
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Front End Plugins |
| Labels |
Added:
PR-5.1-dev
|
||
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-05-31 20:48:11 |
| Closed_By | ⇒ | zero-24 |
| Title |
|
||||||
| Status | Closed | ⇒ | New |
| Closed_Date | 2024-05-31 20:48:11 | ⇒ | |
| Closed_By | zero-24 | ⇒ |
| Status | New | ⇒ | Pending |
| Labels |
Added:
PR-6.0-dev
Removed: PR-5.1-dev |
||
| Category | Front End Plugins | ⇒ | Administration com_finder Installation Language & Strings |
| Labels |
Added:
Language Change
|
||
| Category | Administration com_finder Installation Language & Strings | ⇒ | Administration Language & Strings Front End Plugins |
I think you can safely introduce new parameter name in any of 5.x series.
$input = $this->getApplication()->getInput();
$id = $input->getInt('id', 0);
$taskId = $input->getInt('taskid', $id);
// Then later on, add deprecation warning if both ID exists and Tsks loaded by this id
if ($id && $tasks) {
//.... Use of "id" parameter is deprecated and will be removed, use "taskid" instead
}
Cool idea but there is still a problem when the "id" has not been set in the URL the call $input->getInt('id', 0); results into the default article ID which could also be an valid task id so no other task can be triggered. Or I'm missing something?
Once agreed with this solution an backport can be done but we would need to keep the old/broken behavior for b/c, right?
but we would need to keep the old/broken behavior for b/c, right?
Correct, we check for taskid if it does not exist we use id (old/broken stuff)
results into the default article ID which could also be an valid task id so no other task can be triggered. Or I'm missing something?
Yes, as I understood , but it is current broken behavior, it will stay for a while (when taskid is empty)
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2024-07-25 20:19:09 |
| Closed_By | ⇒ | zero-24 |
Not needed anymore as the requested parameter change has been removed from the base PR
Rebased against 6.0-dev and comments above updated.