joomla-cms
joomla-cms copied to clipboard
joomla
[5.2] Add the "none-ID" behavior to the CRON Scheduler
Pull Request for Issue #43490
Summary of Changes
Implement "none-ID" usage for the CRON Sheduler
Testing Instructions
- Setup 5.2-dev
- System -> Scheduled Tasks -> Options -> Disable Lazy Scheduler
- System -> Scheduled Tasks -> Options -> Enable CRON Scheduler
- Trigger the CRON Scheduler 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.
Expected result AFTER applying this Pull Request
With that patch we allow the usage id as well as "none-ID". With that none-ID thing we trigger one planed task per run.
Link to documentations
Please select:
-
[ ] Documentation link for docs.joomla.org:
-
[X] No documentation changes for docs.joomla.org needed
-
[ ] Pull Request link for manual.joomla.org:
-
[x] No documentation changes for manual.joomla.org needed
Note to the maintainer
Please double check the #43490 before merging as well as check the upmerge of this PR to 6.0-dev Thanks!
The deprecated message as the same issue, it's triggered on every request if the home page menu has an ID.
PR #43164 seems to fix id's from the menu being injected. And with that the original problem. (and then the deprecated message shows when it should) .
Still a good idea to have a dedicated parameter.
The deprecated message as the same issue, it's triggered on every request if the home page menu has an ID.
Hmm yes will remove the call for now. Or do you have a better alternative here?
not really, that would be a solution for the original problem.
Add it after #43164
~In runTestCron also 'id' is used. Wouldn't it make sense to change that as well to taskid. Just to have consistent code?~
I understand what you are trying to do, but I think your issue is solved with #43164. Can you check that?
Works good to me thanks @Hackwar still i would recommend to apply this PR + move from id= to taskid to be sure which ID is passed over. So this here is the B/C safe way and the 6.0 patch will clean up the old Ids.
To be honest, I'm hesitant to merge this if it isn't necessary anymore due to #43164. It feels like change for the sake of change then. I will bring this up in the CMS maintenance team.
Adding back the deprecated message as that issue will be fixed by https://github.com/joomla/joomla-cms/pull/43164
To be honest, I'm hesitant to merge this if it isn't necessary anymore due to https://github.com/joomla/joomla-cms/pull/43164. It feels like change for the sake of change then. I will bring this up in the CMS maintenance team.
Please let me know the result. What we need is the seccond change with the queue what we can revert is the id => taskid change.
https://github.com/joomla/joomla-cms/pull/43164 does not fix the root issue of current PR,
When home page is set to Artcile detail (or another component with ID in request), we still will have id in the input, and this id will conflicting with Scheduler task id.
Because Scheduler plugin blindly checking for any id in the request.
@zero-24 Are the testing instructions still right? They refer to 6.0-dev.
@richard67 I have just updated the texts, during the discussion here the code has been changed so the instructions needed to be updated too.
@richard67 I have just updated the texts, during the discussion here the code has been changed so the instructions needed to be updated too.
@zero-24 Thanks. Description and instructions look good to me now.
When trying the changes and directly accessing the URL in the browser, this error message is produced, and no tasks are executed.
Warning: Attempt to read property "id" on null in /var/www/vhosts/domain.net/subdomains/beta5/plugins/system/schedulerunner/src/Extension/ScheduleRunner.php on line 228
{"success":false,"message":"Joomla\\Plugin\\System\\ScheduleRunner\\Extension\\ScheduleRunner::runScheduler(): Argument #1 ($id) must be of type int, null given, called in \/var\/www\/vhosts\/domain.net\/subdomains\/beta5\/plugins\/system\/schedulerunner\/src\/Extension\/ScheduleRunner.php on line 228","messages":null,"data":null}
When trying the changes and directly accessing the URL in the browser, this error message is produced, and no tasks are executed.
Warning: Attempt to read property "id" on null in /var/www/vhosts/domain.net/subdomains/beta5/plugins/system/schedulerunner/src/Extension/ScheduleRunner.php on line 228 {"success":false,"message":"Joomla\Plugin\System\ScheduleRunner\Extension\ScheduleRunner::runScheduler(): Argument #1 ($id) must be of type int, null given, called in /var/www/vhosts/domain.net/subdomains/beta5/plugins/system/schedulerunner/src/Extension/ScheduleRunner.php on line 228","messages":null,"data":null}
@J-Wick4 Have you tested on a current 5.2 nightly build? This PR here is for 5.2.
When trying the changes and directly accessing the URL in the browser, this error message is produced, and no tasks are executed. Warning: Attempt to read property "id" on null in /var/www/vhosts/domain.net/subdomains/beta5/plugins/system/schedulerunner/src/Extension/ScheduleRunner.php on line 228 {"success":false,"message":"Joomla\Plugin\System\ScheduleRunner\Extension\ScheduleRunner::runScheduler(): Argument #1 ($id) must be of type int, null given, called in /var/www/vhosts/domain.net/subdomains/beta5/plugins/system/schedulerunner/src/Extension/ScheduleRunner.php on line 228","messages":null,"data":null}
@J-Wick4 Have you tested on a current 5.2 nightly build? This PR here is for 5.2.
No sorry, only on the most current recent version of 5.1.2.
hmm will take a look into that. Its kind of an correct error when the ID does not exist, but as there is still the issue with the article id out in the wild. But that should be solved together with the release of this change anyway.
Yes the main question is should we implement a check whether the passed ID is an valid task ID or should we issue an error like mentiond above. While the "article id issue" is solved the same problem comes up with an wrong task id too.
I think if the id is not existing or disabled or trashed it should return an error?
Yes in that case the error is correct and this PR is ready and the test was ok :)
Yes, this was the plan. But for that to happen, it would have required to have been tested. Unfortunately that didn't happen in time. With beta 1 we had a feature freeze and I already handled that VERY flexible. But tomorrow we have beta 2 and that is a pretty hard line for me. Unfortunately it has to go into 5.3 now.
Yes its a bug fix as since 4.x this feature (call without ID) is mentiond within the backend but it never worked. So why cant this go into 5.2.1 etc?
Given that ther are good tests up in this thread i dont see whats missing here, the only test reported an error was because of an invalid ID which kind of correctly issues an error, I can add code to check for an valid ID first when you want.
Given that ther are good tests up in this thread
@zero-24 I don't find any human test results for this PR. Maybe you meant the other, meanwhile closed PR for 6.0-dev?
Given that ther are good tests up in this thread
@zero-24 I don't find any human test results for this PR. Maybe you meant the other, meanwhile closed PR for 6.0-dev?
Yes looks like i got that mixed up. Still this is the same code so a test against this PR should be simple so this logterm bug could actually be fixed soon :)