Add support for details/vertical tabs

The Backbone Model & View seem to only being used to handle initiation & completion of a Tour and not further down the flow of the tooltips. The Joyrider library provides the preStepCallback which could be used to check on the visibility of the next Selector.

See attached patch for fieldset & vertical tabs support. (Modal selector excluded)

Not sure if this is the right approach, but it looks like it does the job. Tested on 8.4.x-dev

Regards

Looks like this patch broke in the 9.2.0 release today, both Tour JS files have had extensive changes made in this release.

Drupal core switched from joyride to shepherd: https://www.drupal.org/node/3195234

Patch in #18 appears to work but I think with this new feature there will need to be test cases added.

Took a shot at the test

Moving into review that failure was caused by something else

This seemed like a bug more then a feature request.

Needs work for 10.1.x

Patch for 10.1.x.
Please review.

+++ b/core/modules/tour/js/tour.js
@@ -239,7 +239,22 @@
+                  const details = $(selector).parents('details');
+                  if (details) {
+                    const id = details.attr('id');
+                    const link = $('a[href="#'.concat(id, '"]'));
+                    if (link.length) {
+                      link.click();
+                    } else {
+                      details.find('summary').click();

this is too coupled to details elements, it assumes the only reason an object isn't visible is if its in a fieldset/tabset

this feels like a won't fix to me

Means tour can’t really work with elements that are hidden in tabs.

Ideally the TipPlugin would support a ::beforeShow method that would allow a plugin class for 'hidden in a details'

Confused by the last comment. The tour tip applies correctly it’s just the element it’s attached to is hidden. So wouldn’t this have to happen in the JavaScript side?

Yeah sorry I'm talking about extending the tip plugin interface to add some JS integration points

Not entirely sure how to do that.

Would request if this ticket is won’t fix to postpone it for when moves to contrib.

I think we'd need to expand the TIpPluginInterface (or add an additional one) to allow tip plugins to nominate libraries.

And then somehow wire up JS for each tip to allow it to do the 'before show' so we didn't have to hard code knowledge of e.g. details/vertical tabs in the generic JS.

But yes, might be a thing to wait for when its in contrib

Just not sure how the tip interface would know if the tip is inside a details tag before the page loads to determine if a new library is needed.

When the author is writing the yml, they will know, so they would nominate a different tip plugin ID for that tip

So we would need a new field Boolean if this tip is in a container. Then if true load this other library?

Had a conversation with @larowlan on slack and most likely will have to wait until contrib, making the strong assumption that will happen.

This extension is being deprecated, see #3336033: [Meta] Tasks to deprecate Tour module. It will be removed from core and moved to a contrib project, #3376099: [11.x] [Meta] Tasks to remove Tour.

This is now Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

First fix into 2.0.x branch!