Direct Link to a Quick Tab

Here's a solution (and patch!) that I used and seems to work pretty well in our use case. Hopefully this can get the progress started to a more stable solution.

Proposed solution

1. Make `/path/to/page-with-quicktab?qt-myquicktabname=my-quicktab-title` link directly to the "My Quicktab Title" tab by triggering the jquery "click" event (inspired by the solution in the Drupal 8 Tab History Issue).
2. Create a new data attribute to the quicktab link called `data-quicktabs-tab-name`
3. Populate that data attribute with a transliterated/cleaned up string based on the tab title (Inspired by public function MachineName::transform).
4. Replace the URL of the tab so that the user can right-click, copy url and share the url as they please

Fixed a critical typo...

Reviewed this patch on SimplyTest.me - created a Quicktab set and copied the link from both. Works!

http://simplytest.me/project/quicktabs/8.x-3.x?patch[]=https://www.drupa...

Would you reroll this against the current dev? There have been numerous changes for coding standards and other patches applied.

On further review, this method would have to be completely reworked. It would break the current method for retrieving content via ajax. The path is actual built as path: '/quicktabs/{js}/{instance}/{tab}' so that the content can be retrieved. This patch completely changes that path so that the ajax method does not work.

Darn! Makes sense, though. Thanks shelane! Trying to rethink the approach... One way is to use javascript to change the href when a tab is right-clicked, but I'm having a hard time reliably reverting the href attribute when contextual menu is closed.
Another approach is to display an optional 'permalink' that either appears in the tab or in the tab content. Won't be as intuitive as right-clicking the tab and sharing the url, but at least this solution may provide a shareable link. I'll work on a patch for the latter.

I reworked the patch so that an additional 'permalink' gets printed as sibling element to the the tab link within the quicktab link container.

The permalink can be enabled/disabled in the quicktab edit form (admin/structure/quicktabs/{quicktab id}/edit) and is defaulted to `disabled` to prevent any regressions on existing sites. As the functionality stands in this patch, the link will be printed with the direct link url and the text 'Permalink' and I will leave it to the developer to theme it as they wish.

Fixed this warning introduced from the patch in #9:
Notice: Undefined index: permalinks in Drupal\quicktabs\Plugin\TabRenderer\QuickTabs->render() (line 176 of modules/contrib/quicktabs/src/Plugin/TabRenderer/QuickTabs.php)

Created a new patch that addresses a few issues that were introduced from the patch in #9 and were not fixed in #11.

1. Undefined index in quicktabs edit page:
   Notice: Undefined index: permalinks in /app/docroot/modules/contrib/quicktabs/src/Plugin/TabRenderer/QuickTabs.php on line 70
2. Only half of the quicktabs were working. The tab indexes were not getting determined correctly due to the Drupal.quicktabs.prepare function applying tab properties to the permalink links. This new patch skips permalink elements.
3. Changed the 'permalink' class to 'quicktabs-permalink' to avoid possible conflict with other 'permalink' solutions. REGRESSION ALERT! Please note that if you're using '.permalink' selectors in your custom js or css, change those to '.quicktabs-permalink' ASAP if you use this new patch.

Grr... previous patch didn't include the first item i mentioned in my comments in #12. This new patch now includes that fix for that pesky undefined index warning.

Reminder: REGRESSION ALERT! Please note that if you're using '.permalink' selectors in your custom js or css, change those to '.quicktabs-permalink' ASAP if you use this new patch and were previously using the patch in #9.

Hi,

Applied the patch first to Alpha4 and then the latest dev, but didn't get it to work.

EDIT: should have first uninstalled alpha4 and then dev plus patch
1. Enabled the permalink in the settings page
2. took the links (for example: https://www.domainn.com/group/38?qt-group_page=progress)
3. disabled the "display tab permalinks"
3.1 cleared caches etc.
4. Tried the links, but not working, the tab does not change with the urls given.

Also another problem is on the settings page:
Display tab permalinks:
Yes: Direct links to a quicktab within the page will display alongside the tab link.
No: Only quicktab links will be displayed

There is situation when none of the settings are enabled.
1. select "No: Only quicktab links will be displayed"
2. click save, and after saving the settings, both radio buttons are empty.

Other settings what I have on the /admin/structure/quicktabs/quictabname/edit
Style: On the gray
Ajax: No: load all tabs on page view
Hide empty tabs: checked

With this patch, Firefox web developer console gives error, when refreshing a page while in the URL is a link to certain TAB:

"Some cookies are misusing the recommended “SameSite“ attribute"
Will be soon rejected because it has the “SameSite” attribute set to “None” or an invalid value, without the “secure” attribute. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Install Quicktabs and apply this patch #13
Enable quictabs links, and use one in the URL
When you refresh the page, you get the error

Attached is a new patch to address the issue from #14. Thank you for finding that bug, jukka792!

Apologies... I am unable to reproduce the issue in #15. Here are some resources that might help you address the samesite cookie issue:
https://www.drupal.org/forum/support/module-development-and-code-questio...
https://www.drupal.org/project/drupal/issues/3150614

Sorry... embarrassing typo in #16. This patch doesn't cause a whitescreen error now.

Latest patch is working for me on 9.4.3.

Fixed a PHP warning that was introduced in the #17 patch:
Warning: Undefined array key "permalinks" in Drupal\quicktabs\Plugin\TabRenderer\QuickTabs->optionsForm() (line 70 of modules/contrib/quicktabs/src/Plugin/TabRenderer/QuickTabs.php).

I made a combination of tabs and accordion using quick tabs. I would like to be able to open a specific accordion from the top menu, which is in the tab. I tried the patch above but it doesn't work for me. Has anyone done accordion in there with linking and had a similar problem? Drupal 9.5.2.

All,

I have updated this patch to be a bit more user friendly.
Tabs now have direct links to them and the tab URLs are updated for right clicking links.

Attached it a new patch that I hope helps others. Reach out if there any questions or things I can improve on.

Apologies, I had a error in my patch. See the updated!

@jmester13

Couldn't apply the last patch, can you check?

Triaging the queue with so long of inactivity is this still a desired feature?

We actively use this functionality. So for us, yes.

Haven’t reviewed the patch but should have test coverage and be in an MR

Understood. Makes sense. I'll see if I can get that pushed up next week.

Tests are pretty lacking so hoping to add a basic one in another ticket. That maybe can be extended here

Seconding that this is desired functionality.

Also, is there a working patch for this feature at the moment? I have attempted to install the last patch mentioned in this thread (using Quicktabs v4.0.1), but to no avail. I received an error while applying the patch, just looking for confirmation on if someone has recently gotten it to work or not.

@smustgrave +1 for the functionality

I tried to re-roll the patch 22 form @jmester13 but without success. The code has changed significantly the last 2 years.

I just created a new merge request for this thread. I completely rewrote the code, but the underlying idea remains the same.

The permalink is using a hash instead of a querystring parameter.

The permalink is semantic; it is a transliteration of the tab title.

In the backend, I am incorporating a simple on/off checkbox to activate/deactivate this functionality (users might prefer to opt out of using it). If the checkbox is disabled, Quicktabs should work exactly like it already does, and the entire functionality will be bypassed.

I’m leaning toward keeping direct linking enabled by default.

The earlier concern was that changing the tab href could break AJAX loading. Since this MR keeps the existing Quicktabs AJAX route intact and adds hash handling on top, that concern seems addressed.

I’m open to opt-in if others feel strongly for BC reasons, but I don’t see strong disagreement in the issue so far.

Hiding patches

Hi all 👋 thanks for your patience on this one, and thanks to everyone who kept it moving with patches, testing, and the rewrite.

I reviewed and cleaned up the MR, and pushed an updated version.

A few out-of-scope pieces were removed:

• The cookie to localStorage change for tab memory, since it was unrelated and changed existing behavior.
• The JS-applied ARIA changes, since ARIA is already rendered server-side and the JS introduced duplicate IDs and incorrect active-tab announcements.
• The forced focus() call on tab activation, since it caused unwanted focus/scroll changes during page-load restores.

The direct-linking work was kept and tightened up:

• Fragments are namespaced per Quicktabs instance, for example #qt-example=tab-name.
• The URL is only updated on real user clicks.
• Slug generation is more defensive.

For upgrade safety/BC, direct linking is on by default for new installs, but existing instances are set to off by the post_update and can opt-in per instance.

Test coverage was added for schema/slugs and the main Nightwatch direct-linking behavior, including load, click, per-instance isolation, and hashchange restore.

AI note: I used AI assistance for review, implementation, and test scaffolding. I made the scope and design decisions, reviewed the changes, and verified them locally via DDEV/Nightwatch before pushing, as per policy on AI contributions.

Committed and pushed to 4.0.x. Merge train has left 🚂!
Thanks everyone for keeping this issue moving over the years with patches, testing, rerolls, and reviews.

Out-of-scope changes from the earlier MR were intentionally removed:
Cookie-to-localStorage tab memory changes, this could be a good feature just had some issues, worth it's own issue and I am a fan of removing dependencies if possible.