Hardcoded local task dependency on view scheduler_scheduled_content

I also have something similar. This is my error:

> [notice] Update started: scheduler_update_8102
> [notice] The "Scheduled" tab is now a "Scheduled content" sub-task under the "Content" tab
> [notice] Update completed: scheduler_update_8102

In ProcessBase.php line 188:

Unable to decode output into JSON: Syntax error

{
"0": {
"scheduler": {
"8102": {
"results": {
"query": "The "Scheduled" tab is now a "Scheduled content" sub-task under the "Content" tab",
"success": true
},
"type": "update"
}
}
},
"drush_batch_process_finished": true
}

Good thing I did this on my local...

Any idea what could be the issue?

Hello, Sorry to hear you are having problems.

@lomale
The first two lines of your output are

> [notice] Update started: scheduler_update_8102
> [notice] Update completed: scheduler_update_8102

That is the end of the scheduler update. The next lines [notice] Contact Us elements are not valid and Options likert_quality do not exist are nothing to do with Scheduler. There must be something else causing that error.

The second problem you have is RouteNotFoundException: Route "view.scheduler_scheduled_content.overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName()
But that route name has not changed from 8.x-1.3. Did you delete the scheduled content view?

@Sseto
Your update function has also completed sucessfully, as it shows
[notice] Update completed: scheduler_update_8102
The next part seems to be a problem in how the output of the message is displayed. The parse error could be related to the double quotes in the message text "query": "The "Scheduled" tab is now a "Scheduled content" sub-task under the "Content"

The file is vendor/consolidation/site-process/src/ProcessBase.php, the function is getOutputAsJson() and line 188 throws that exception when the json_decode() failed. This works fine in drush and and when running the update via UI on a site update.php. How were you running the update? Also what operating system?

Hey jonathan1055,

for this:

"query": "The "Scheduled" tab is now a "Scheduled content" sub-task under the "Content"`
It looks like my site is working correctly and it shows that `success: true`. 

Do you think it's safe to ignore?

I didn't get this warning :
RouteNotFoundException: Route "view.scheduler_scheduled_content.overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName()
And I never touched schedule content view. It's still active.

Thanks!

Do you think it's safe to ignore?

Yes, I think it is safe to ignore. It is just the display of the output from the update function. Looks like you ran it in batch. Was that how you did it?

I used drush to update the DB.

Thanks for your help buddy!

That's good. If you see this when you view the scheduled content at admin/content/scheduled, then it has worked. Instead of a separate 'scheduled' tab, you should see 'overview' and 'scheduled content' sub-task links.

Thanks.

But still have the problem that the site crashes when I want to access content.

This is not the problem you reported in the issue summary.

I believe that it is because I hadn't entered any schedule information in the nodes.

Your screen shot shows that the route must still be working, and the view is working, because you can see the tab.
There are no rows shown in the table because, as you said, you have not entered any scheduler dates.

Second I found out, that in some nodes I have two event contents there is no possibility to enter scheduled data.

Was your site working properly at 8.x-1.3? The changes to 8.x-1.4 should not make that much of a difference.

I also got the same error after updating the module:

The website encountered an unexpected error. Please try again later.

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.scheduler_scheduled_content.overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 208 of core/lib/Drupal/Core/Routing/RouteProvider.php).

Looking into the error from this particular site, the module was enabled but scheduler.settings config was never created neither views.view.scheduler_scheduled_content.yml exists.

For other sites, the issues were with both links appearing. For those sites, we manually added the missing config code to views.view.scheduler_scheduled_content.yml then importing config after updating module displayed expected UX.

langcode: en
status: true
dependencies:
  config:
    - system.menu.admin
  module:
    - node
    - scheduler

   display_options:
      path: admin/content/scheduled
      menu:
        type: normal
        title: Scheduled
        description: 'Content scheduled for publishing and unpublishing'
        expanded: false
        parent: system.admin_content
        weight: -10

The website encountered an unexpected error. Please try again later.

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.scheduler_scheduled_content.overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 208 of core/lib/Drupal/Core/Routing/RouteProvider.php).

On one of our websites we got the same problem. The view was never created and the content view (/admin/content) was no longer accessible. Uninstalling and installing the module again created the view and resolved the problem.

Hi Gertlor
Thanks for the info. It is odd how some installations never seemed to have that view. Good that you found a simple way to resolve it.

If users cannot or do not want to uninstall and re-install, then you may be able to use the Config Update module to fix it. The 'Configuration Update Reports' sub-module produces reports comparing loaded config with the source files. You can import missing configs, or revert to source.

Here's the report UI, after selecting 'Scheduler' for the report type 'single module'

Alternatively, copy the view from modules/scheduler/config/install into your config-export folder, edit the yml and add a uuid entry, and run config-export

The module shouldn't force you to have that view. Modules must not add hardcoded local tasks that depend on configuration.

Instead, this should be done in a local tasks alter hook that checks if the view exists, or alternatively moves the configured local task.

I'll try to provide a patch for this.

Thanks Berdir,

The module shouldn't force you to have that view

Yes I agree. In previous versions we did not force it, and the view could be deleted in /admin/structure/views. I think the problem came about due to #3167193: Move "Scheduled" menu tab so it's a task under "Content" where the update hook scheduler_update_8102() tries to modify the view.

Here's a patch that moves both related local tasks into an alter hook. I also moved the "optional" overview tab as eventually, when that core issue happens, it will likely have a different name, and then it's easy to add a second if condition for full back and forwards compatibility for all possible names and eventually (maybe) you can then remove that condition when you require whatever core version moved it to node.module.

Tested on my site that doesn't have the view. I did _not_ yet test on an installation that actually has that view ;)

The update function itself is fine, that already checks if the view exists.

I have this error as well after upgrading to 1.4.0, when visiting admin/content overview.

Without the patch from #19, I get this error:

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.scheduler_scheduled_content.overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of core/lib/Drupal/Core/Routing/RouteProvider.php).

With the patch from #19, I get a different error:

Drupal\Component\Plugin\Exception\PluginException: The plugin (scheduler.scheduled_content) did not specify an instance class. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 79 of core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).

If I downgrade, the error disappears.

This is on Drupal 9.2 btw.

Ah, I forgot the class, need that in the alter hook. That's why my approach usually is to define a local task on the view and then just change the parent. But I don't want to change the view yet again.

Thanks @berdir for the patch, that's really helpful. And thanks @achton for testing.

Here's an updated patch with 'class' => 'Drupal\Core\Menu\LocalTaskDefault' added for each of the local tasks. With this in place I then got

Notice: Undefined index: options in Drupal\Core\Menu\LocalTaskDefault->getOptions()
(line 108 of /Library/WebServer/Web/drupal89dev/core/lib/Drupal/Core/Menu/LocalTaskDefault.php).

Adding an empty array item 'options' => [] fixed this.

This works for me with manual testing, both with and without the core Content Moderation module enabled, and with and without the scheduer view existing. But we will need test coverage for this (patch #19 passed all tests but was clearly not complete). Also this work will need to go into the 2.x branch first, so that we do not get regression. But for now, one step at a time, here's the patch for you to retest.

Adding dependency on core issue so we don't forget this issue when #2172307 is merged.

#19 was missing the class from #22 but both #19 & #22 were using hook_local_tasks_alter instead of hook_menu_local_tasks_alter. So I kept getting the error

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "view.scheduler_scheduled_content.overview" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 206 of core/lib/Drupal/Core/Routing/RouteProvider.php).

Fixed this with the proper alter (scheduler_menu_local_tasks_alter) in a MR.

I'm going to work on this at 2.x and am thinking about using a dynamic local task deriver class instead of hook_local_tasks_alter() or hook_menu_local_tasks_alter()

@Gertlor, @Berdir, @mpp, @achton I have pushed to the 2.x branch. Any chance you could have a quick look and/or test this on your sites which do not have the views or where they are disabled. This all works fine for me locally. I can disable any of the three views (scheduled content, scheduled media, scheduled products) and I do not get the "route does not exist" error.

I tried to expand the test coverage of this, but could not make the test fail when the view is disabled. I could not get the "route does not exist" error. I tried running the functional tests using Bartik as the theme not Stark, but the local tasks are still not rendered. Maybe this is a candidate for a Kernel test? (of which Scheduler does not have any yet). I would like to have a test that uses the routes and that will fail with the existing hard-coded local tasks when the views do not exist or are disabled. Then we can prove that the new dynamic local tasks fix the problem.

I think the 2.x MR 21 is ready. If anyone else could review and/or test it that would be appreciated. I added checks on the status of the view and the existence of the 'overview' display (thanks to @berdir for that on the earlier 8.x-1.x patch)

Using the recent version of the merge request fixes the problem for our project, where we just disabled the "Scheduled Media" view (we do not use Scheduler for Media). I like the approach and it's great to see a test coverage. Thank you!

Test the latest MR 21 using the patch.
Works Correctly.
Attached screenshots.

Hi joshua1234511,
Thanks for testing and pleased to hear it works for you.
However I am not sure exactly what you intended with the patch? The code changes are already made in the MR branch. Your patch is a copy of patch #22 which is for the 8.x-1.x branch of Scheduler. But your screen shot shows that you are using 2.0.0-alpha1 and you have sucessfully used MR 21 (which is correctly for the 2.x branch).
When the work on 2.x has been completed and committed I will also make the equivalent fix on the 8.x-1.x branch.

I do have a little more work to do on the 2.x branch, as I want to remove the hard-coded additions in .routing.yml and .links.task.yml. That will be coming soon.

@Matroskeen - thanks for testing too.

Merged MR21 into the 2.x branch.

The correct hook to use (in 8.x-1.x) is definitely scheduler_local_tasks_alter not scheduler_menu_local_tasks_alter. The initial patch in #19 was correct, but the function comment header had the wrong name.

Committed to 2.x and 8.x-1.x
Thanks everyone.