Toolbar button shows "No tour" even where there is one

I should point out that instead it works as expected if the (core experimental) navigation module is enabled, both with and without the toolbar module enalbed (which should be superflous once navigation is used).

This issue is not replicate at my end, it 'll be helpful if more detail steps shared along with screencast.

I had already given the instructions to reproduce! But here it's an even simpler one:

1. Install a standard Drupal 10.3.6 site (I used DDEV & drush with ddev drush si
2. Require & enable this module ddev drush composer require drupal/tour
3. Check that there is a tour that should show up on Tour edit pages (/admin/config/user-interface/tour/manage/tour_edit)
4. Go to edit itself or any other tour, eg:/admin/config/user-interface/tour/manage/tours]
5. Click on the "No tour" button in the toolbar to start the tour

You can see the same problem on all 3 of the default tours provided, as well as new tour you might create, as I said in #1.

The problem is with the toolbar module and not with the navigation module. Just enable it and repeat the last 2 steps to see the problem "fixed".

Would have to spin up a 10.3 but not seeing an issue on 11.x

Are you testing latest 2.0.x branch btw?

Hi, I had a similar issue that was marked as a duplicate of this one. I did some debugging, so I'm copying that here in case it helps shed light on this issue. My issue is that when the route is 'entity.node.edit_form' the 'bundle' parameter is both used and ignored. Looking at the code for Tour 2.0.6 ...

* The 'entity.node.edit_form' route has a parameter 'node' that is the Node entity being edited
* tour_page_bottom() discovers this at line 167 of tour.module and sets $params['bundle'] to the node's bundle. This allows the route to be matched so the tour can be added to $page_bottom. This explains why the tour is available when the toolbar button is clicked.
* On the other hand, tour_toolbar() only looks at the 'node' parameter's id() on line 94, so $no_tips is set TRUE. Then when the button is rendered LazyBuilders::renderTour() sets the text to "No tour".

My suggestion is that tour_page_bottom() and tour_toolbar() use the same code. Even better, the first function to be called should stash its results so we only need to do one entityQuery('tour'). If this is a helpful way forward I can contribute a patch.

Same question on #7 are you testing on 2.0.x or the tagged release 2.0.6

I was testing 2.0.6 but I've downloaded 2.0.x and the same issue presents.

I am seeing the issue but surprised the pipeline is having 0 issues

Can't replicate on 11.0.7

But I do see on 11.1.x

We can re-open if needed but want to include in the next release, which I'm planning shortly.

I'm continuing to experience this issue with 2.0.7.

Here is an excerpt from the YML for my tour ...

id: add_or_edit_a_blog
label: 'Add or edit a Blog'
routes:
  -
    route_name: node.add
    route_params:
      node_type: blog
  -
    route_name: entity.node.edit_form
    route_params:
      bundle: blog

For the node.add route, the tour button says "Tour" when I'm adding a Blog, and clicking it starts the add_or_edit_a_blog tour

For the entity.node.edit_form route, the tour button says "No Tour" when I'm editing a Blog, but clicking it starts the add_or_edit_a_blog tour

We're getting it with routes in search_api on tour 2.0.6 and core 10.3.10

The routes are like:

entity.search_api_index.processors
entity.search_api_index.canonical
entity.search_api_index.edit_form

You click the "No tour available for this page" and it actually starts the tour.

What do these routes have in common? They have parameters. Even when I specify a route, the button still displays the wrong label.

We aren't getting the issue on:

entity.search_api_index.add_form
honeypot.config
block.admin_display

These routes do not have parameters.

Tours working on pages with parameters is a feature request?

From what I can tell that was never part of what it supported. Also based on the description. So least to me seems like a feature request.

Needs more test coverage but a good start.

Wonder if anyone mind testing if this works for them? Then can add coverage for the other params

Automatically closed - issue fixed for 2 weeks with no activity.