Scheduler 2.2.0 breaks code

Here is a quick patch I wrote using the fix used at https://www.drupal.org/project/content_planner/issues/3498530 🐛 The content planner 8.x-1.2 not compatible with Scheduler 2.2.0 Active

Here is a quick patch I wrote using the fix used at https://www.drupal.org/project/content_planner/issues/3498530 🐛 The content planner 8.x-1.2 not compatible with Scheduler 2.2.0 Active

I am running into the same problem, but I don't understand why we would need this, because the scheduler module itself also adds the aliases.

See https://git.drupalcode.org/project/scheduler/-/blob/2.2.0/scheduler.modu...

The event aliases used to be defined in the /src/ class files but were moved in 🐛 TypeError: Drupal\content_calendar\EventSubscriber\SchedulerPublishSubScriber::onNodePublish(): Argument #1 ($event) must be of type Drupal\scheduler\SchedulerEvent, Drupal\scheduler\Event\SchedulerEvent given in Drupal\content_calendar\EventSubscriber\Sc Active . Maybe those classes were previously being detected by autoloading or some other behind-the-scenes process? But now it needs to be done another way?

Are you using the SCMI 2.x or 3.x branch? Not sure if that is salient, but just useful to know.

Also, when exactly does the error happen? is it during upgrade, or during scheduling, publishing or cron?

The actual error Drupal\scheduler\SchedulerEvents not found means it is looking for the old class. I see in the event subscriber the parameter typehint has the old name. I've pushed a change, don't know if this will fix it, but it may do.

I am using SCMI 2.x and I get that error during a "drush updb" from scheduler 2.0.1 to 2.2.0.

I think https://git.drupalcode.org/project/scheduler/-/commit/46b1988b7e87e47188... is the commit that introduced the problem

Yes that was the commit from the issue I linked in #6 🐛 TypeError: Drupal\content_calendar\EventSubscriber\SchedulerPublishSubScriber::onNodePublish(): Argument #1 ($event) must be of type Drupal\scheduler\SchedulerEvent, Drupal\scheduler\Event\SchedulerEvent given in Drupal\content_calendar\EventSubscriber\Sc Active
Can you test with the SCMI merge request I have created here?

I could reproduce it locally and the problem is that .module files are not loaded before a drush updb. So the alias was not registered

With the patch, I get the following warning from clearing cache:

› drush cr
 [warning] Cannot declare class Drupal\scheduler\SchedulerEvent, because the name is already in use scheduler.module:45
 [warning] Cannot declare class Drupal\scheduler\SchedulerEvents, because the name is already in use scheduler.module:46
 [success] Cache rebuild complete.

@dan2k3k4 please ignore the patch. That is not the solution. Can you test the MR?

@chr.fritsch have you tried with the MR? The error was in SCMI code which the new path for the use statement, but the old path in the parameter hint. I don't think SCMI needs to use the alias at all. Or if it does, it need to be internally consistent.

The MR is only a doc change. How could that help?

It was only a guess :) I thought maybe that the @param type hint was being observed in the function parameters definition. Maybe not.

.module files are not loaded before a drush updb. So the alias was not registered

OK, that's useful info. So maybe we need to put back the actual /src/ files, but also have the aliases in the .module to satisfy the previous problem. I see that the core aliases are prefixed with @, which Scheduler does not have. Or we use class_exists() to prevent an error.

Not sure if this is the desired fix, but it works for us.

Bringing back src/SchedulerEvents.php and src/SchedulerEvent.php fixed the issue for me.

Hi @wotts, yes that is the right correction but I guess you are using an earlier released version of SCMI because that change has already been made in the latest 2.x and 3.x dev.

@chr.fritsch - that's great to hear. I presume you are talking about MR223 in 💬 Sheduler upgrade 2.2.0 and content planer 8.x-1.2 Active . Do you know if there is any impact/downside to declaring the aliases in both places? Is there a situation where an error will be thrown because the alias already exists? They are doing the same thing, and all of the Scheduler tests pass, including the legacy API tests I added when we moved the aliases to .module

@wotts's patch is working for us.

@jonathan1055 we don't use dev branches if we can help it. As such, that patch is necessary until someone can get a new 2.x release out.

Thanks @loopy1492 , yes I accept that. The fix in 2.x was done in #3444174: Tests fail with "Call to a member function isPublished() on bool" → in May 2024, and since then we've had 2.0.0-alpha1, 2.0.0-beta1 and 2.0.0-beta2 on 19 July. I think we need a 2.0.0 proper release now, even though there are still many other issues/bugs to solve.

I'm not the primary maintainer of this project, but I can probably make a 2.0.0 release if @smustgrave agrees. I will ask.

I have merged the two corrections to the @param typehint, even though this does not fix the problem. That is being investigated in 💬 Sheduler upgrade 2.2.0 and content planer 8.x-1.2 Active

Putting this issue back to 'active' as there is nothing to review now. I will also be making a full 2.0.0. release soon.