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 #43164

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.

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.

#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.

Hm, ignore my previous coment,
I have misunderstood a few things ?

Can you fix the codestyle?

Fixed @Hackwar

@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.

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.

I can confirm the error when entering a non-existing id in the base URL.

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.

The article id issue is solved by now.

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 :)

This pull request has been automatically rebased to 5.3-dev.

Wasnt the plan to merge this into 5.2 still? @Hackwar ?

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.

isnt this a bugfix anyway?

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?