Quicktabs module: some updates and an attempt at a roadmap

Quicktabs, the Drupal module that allows you to create blocks of tabbed content such as views, blocks and nodes, and which I co-maintain with Csuthy Balint (Pasqualle on drupal.org), received a couple of significant changes recently. One of the changes, allowing Quicktabs blocks to be exported just like you export Views and other CTools exportables, had been submitted as a patch by Young Hahn of Development Seed a shamefully long time ago and I had procrastinated about certain aspects of it. But building client websites at Work [at] Play, the dev team has been making huge efforts to keep everything in code, and it became increasingly clear to me that Quicktabs' lack of exportability was a Bad Thing; my fellow developers were surely casting sidelong, disapproving glances at me as its author, wondering what on earth the problem was.

Yay - Quicktabs are now exportable!

So I have created the 6.x-3.x branch of the module in order to accommodate this change. The reason I felt this was necessary is that we have moved from serial ids to machine names, so although existing QT blocks on a site can simply be given an automatically generated machine name when you update the module, the fact that their original numeric id gets blown away means that any placement of that block also gets blown away seeing as that was how it was referred to in the blocks system. Anyway, when I showed Owen Loy (aka mundanity), chief of development at Work [at] Play, that our custom modules can now have a mymodule.quicktabs.inc file where all of our QT blocks are defined, just like what we do for Views, he almost shed a tear of joy. That was nice :-)
If you want your custom module to define some Quicktabs blocks, you must implement the CTools plugin API. Here's an example:
* Implementation of hook_ctools_plugin_api().
* Tell Ctools that we support the quicktabs API.
function mymodule_ctools_plugin_api($owner, $api) {
  if (
$owner == 'quicktabs' && $api == 'quicktabs') {
    return array(
'version' => 1, 'path' => drupal_get_path('module', 'mymodule') . '/includes/quicktabs');
Then in your mymodule.quicktabs.inc file at the above path, you'll implement hook_quicktabs_default_quicktabs, which will return items as copied and pasted from the export page after you defined your QTs in the UI.

Custom menu callbacks as tab content

The other major change in Quicktabs is to allow arbitrary menu callbacks as tab content. I've also added this to the 3.x branch but I may eventually add it to the 2.x branch as well. It needs testing so I'm hoping that people who are interested in this development will go ahead and check out the 3.x-dev version and play around with it a little. When creating your tabs you'll now see an extra option for each tab type - QT Callback. You just need to provide a path to a callback you have set up in your custom module that returns the content you want to show in this tab. Thanks to Ronn Abueg, senior dev at Work [at] Play, for helping to make that a much more elegant solution than what I was originally suggesting.

What about Drupal 7?

Drupal 7 already has a 2.x branch and a 3.x branch. The 2.x branch is a straight port from 6.x-2.x - however the 3.x branch in D7 was created way before the 3.x branch in Drupal 6. Its main raison d'ĂȘtre was to experiment with the possibility of using jQuery UI Tabs for the whole tabbed interface side of things and leverage as much of the new functionality provided by the D7 Ajax framework as possible. Making these two things work together was not all that straight-forward and certainly without the two patches I mentioned in my recent post on the Ajax Framework, it will be trickier still. I am hopeful that it will come together but it represents quite a big departure from the original way that Quicktabs has always worked - for example, the module would no longer come with all the pre-defined styles it currently offers as the whole theming side of it would be looked after by jQuery UI.

Achieving a coherent roadmap for Quicktabs

Aside from the obvious task of adding the exportability functionality to the 7.x-3.x branch, much thought will need to go into where to take things from here. The last thing I want is to frustrate Quicktabs' existing users by introducing changes that make their lives difficult. And yet, such users should not be left out when it comes to exciting new features. The best solution might be to have exportability as the only difference between the 2.x and the 3.x branch in D6 (so all other enhancements get added to both), and to maintain two quite different branches for D7, one that uses jQuery UI and one that doesn't. But there are still questions to be answered e.g. should 7.x-2.x provide exportability? User feedback will undoubtedly be the most valuable guideline here and I look forward to receiving plenty of it.

This is a nice development,

This is a nice development, exportability should be a part of any version going forward.

Any chance on making quicktabs work nicely with block cache for D6?

Here's the issue for the

Here's the issue for the block cache problem: http://drupal.org/node/342459 It's not really a Quicktabs-specific problem, so not sure there's much more we can do about it :-/

Please include exportability in both 7 versions!

Would it be easier to have one Drupal 7 version that could either use JQuery UI or use the traditional method? I do not envy your module maintenance responsibilities!

Yes, I guess the fact that QT

Yes, I guess the fact that QT blocks will need to be placed again after an upgrade from 6.x-2.x to 7.x-2.x will be the least of one's worries and if it's clearly explained in the upgrade instructions it should be fine.
As for having the jQuery UI stuff as an option, that's a tough decision. There are so many options now, it might get very confusing. Also, the really nice thing about the version that uses jQuery UI is I can blow away the whole quicktabs.js file and all of the tabstyles subdirectories, so it would be a really clean version of the module - a LOT less code, which is nice.

I am in favour of using

I am in favour of using jQuery UI instead of custom code.
It will mean less code to mantain for you while providing theme developers with a known tool (jQuery UI) to hack in case of necessity or custom needs.

My .2 cents.