Problem/Motivation

While going through this issue #2017477: Multilingual tour for content translation settings we wanted to provide a tour for admin/config/regional/content-language that is a page with some functionality when you install language module (so a language module tour should be provided) and extended when you install content translation module.

I discovered that if I configure two sets tips for the same route (two yaml files) only one of them is shown.

Proposed resolution

To discuss:

1- Have tour button for every tour available in that page. This also allows multilingual for example to provide a tour on the Extend page explaining the purpose of the different modules. This means display many buttons on the toolbar instead of one to take each of the tours available using their label.

2- Have a way to merge tour tips, if two tours are available for a page merge their tips by weight so you take all the tours available.

3- config yamls extend the configuration of other installed configuration. I think is not possible to merge the yamls so one tour can be extended with more tips.

Remaining tasks

Decide a solution.

User interface changes

API changes

Comments

rodrigoaguilera’s picture

Issue summary: View changes
rodrigoaguilera’s picture

larowlan’s picture

They were supposed to work this way...

larowlan’s picture

Category: Feature request » Bug report
larowlan’s picture

So the javascript supports this if you're linking from another page.

foo/bar?tour=1&tips=some-class is supposed to auto start a tour with it filtered to tips with the class some-class

rodrigoaguilera’s picture

Oh that is great.

I'm thinking that tours that need to be "extended" by other modules add a hook_tour_tips_alter that can add links to the last step of the tour to take the additional tours that live on that same page.

I'll try that later and will update the docs if this is the preferred way to deal with this kind of situation.

For the moment I'm wondering how we can be sure that the "main" tour is the one that is going to appear when you click on the tour button. I understand this main tour as the one we are going to add links to take other tours in the same page.
I'm not sure how to order tours

If this a solution we can close this issue.

larowlan’s picture

There is a hook_tour_tips_alter, see tour.api.php

rodrigoaguilera’s picture

Yeah I meant implementing the hook.
For example for this tour #2017477: Multilingual tour for content translation settings

Write a tour for the language module explaining the translation settings in that page and write another tour on the same page for the content_translation module that you can take at the end of the "main" language tour using hook_tour_tips_alter on the last tour tip

My concern is that I want the language tour to be the "main" tour that you take when you access that page but ther will be two tours defined for that route.

I guess that clicking on that link will reload the page with the second tour and then you lose all you did on the first tour (checking chechboxes).

I want my plan to be understood and reviewed so maybe it can be a pattern to follow. Tell me any doubts you have about it.

jhodgdon’s picture

Status: Active » Postponed (maintainer needs more info)

I don't understand why you can't use the alter hook for this? I mean, in this case the page works one way by default, and if a module adds some stuff to the page via some kind of page altering hook/class/plugin, then it should also be able to do an alter hook to add stuff to the tips. That seems like the right thing to do, and this hook already exists.

So my feeling is that this is not a bug at all?

If there's another use case for why we need to have two sets of tips, please explain in the issue summary, but I think the use case covered in the current summary is best done via the existing alter hook.

jhodgdon’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)
Issue tags: +Bug Smash Initiative

Thanks everyone who contributed to this issue.

As part of the Bug smash initiative, we are triaging issues that are marked 'Postponed (maintainer needs more info)'. Based on the lack of additional information provided since jhodgdon's reply, I am marking this 'Closed (cannot reproduce)'.

If anyone believes this issue should not be closed, please provide specific information around the use case for why we need to have two sets of tips.