drupal

Links, blog entries etc related to drupal

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.

Four fallacies in some current Drupal community thought processes

Of course I couldn't help but be aware of the raging debate that went on today over certain remarks Dries made in his keynote at DrupalCon Copenhagen. My own opinions on the matter aside, sometimes people are just plain wrong. Here are some examples of the incoherent arguments being put forward today.

Fallacy #1

Drupal 6 JavaScript and jQuery

by Matt Butcher | Published by Packt Publishing

The very first Drupal module I was ever tasked with building was a little widget for displaying portfolio items. You could scroll through thumbnails, three at a time, each successive three being loaded via AJAX, and clicking on any thumbnail loaded a larger image and description, via AJAX of course, for that portfolio item. I was brand new to Drupal and, despite being pretty scared of JavaScript, was thought of as "the AJAX person" on the team (because I had once mentioned that one time I had built something that used AJAX). It was a pretty tall order, from my perspective.

AHAH in Drupal: may it one day live up to its acronym

With a name like AHAH, one might expect positive experiences in one's dealings with it. But often a name like "AGAH!" would seem more appropriate (Asynchronous Groaning and Headbashing?). There's no doubt about it - AHAH in Drupal is hard. I'm referring here to the trick of dynamically changing elements on a form or adding new ones, as is done on the poll creation form in core. It was next to impossible in Drupal 5, promises to be fairly straight-forward in Drupal 7, but has many people tearing their hair out in Drupal 6.

Rotators Unite!!

The "featured content rotator" seems to have become a standard feature in our client sites - a front page device for promoting content, using nice "flashy" effects during auto-rotation between promoted items. For Drupal 5 sites I ended up always working off the same custom module I had built for the first one and having to tweak it according to different client requirements: Did they want tabs? Did they want pause and play buttons? Should navigation be triggered on tab click or on tab hover? And so on. I had been thinking to myself I should really get around to writing a one-module-fits-all solution, where these options would just be different configuration settings. Well, I am now certain I will never write such a module. Recently, we needed to implement a rotator feature for a D6 client site. I had heard vaguely that there were D6 modules available but until I came across this post in the Duplicated Modules Hall of Shame on groups.drupal.org I had no idea that so many developers had contributed their own version of this feature.

YADCWUP or Yet Another DrupalCon Wrap-Up Post

I already posted a conference wrap-up over on the Raincity Studios site but wanted to write a more personal summary of the week here. One of the best things about the trip was the opportunity to hang out with Ariane and Audrey in our cool little flat in the Dupont Circle neighborhood.

Introducing Quick Tabs 2.0: ...and would you like some AJAX with those tabs?

When the Quick Tabs module was first conceived, it was meant as a space saving device that would replicate a feature becoming quite common on news websites: the little "Most emailed / Most popular" block, where you'd have two tabs, each showing about 5 items (node titles with links to the nodes), and that would be that. Of course I wasn't so short-sighted as to limit it to two tabs (I limited it to 10), but I didn't imagine there'd be much more people could want out of it. Well, my issue queue soon proved me very wrong.

The dual aspect of Drupal forms and what this means for your AHAH callback

Over the last week or two I've spent a lot of time on an aspect of my Quick Tabs module that I am certain none of its users will care a hoot about. It wasn't a case of adding a new feature or fixing a bug or even improving usability, but a question of, to put it succinctly, cutting down on its evilness. The admin form for creating and editing Quick Tabs blocks (where you choose either a block or a view for each tab) had a serious amount of ahah functionality: click a button to instantly add a new tab, click a button to instantly remove one of your tabs, select a view for your tab and have the view display drop-down be instantly populated with the correct options for that view. It was pretty user-friendly; there was just one problem: it flew in the face of Form API best practices.

Quick Tabs for D6 beta release - now with Views 2.0 integration, but was it worth it?

At last I overcame my fear of Views 2.0 and have added it to my D6 effort for Quick Tabs. (Previously my D6 version only allowed you to add blocks to your tabs.) My colleague, Hubert a.k.a. couzinhub, having quickly jumped in and familiarised himself with the wonders of Views 2.0 (well, after all he did help with the UI), helped me out with a very enthusiastic run-though of displays, overriding default displays, etc. and generally getting an overview of the lay of the land in the beta4 release of this super-module.

As far as Quick Tabs integration went, all I needed was a way of providing a drop-down list of all available Views so that people could add one for display in a tab. I had previously used the views_build_view() function then to display the view. There were a couple of hiccups in getting this to work in Drupal 6. Views_build_view() no longer exists but there is views_embed_view() which is slightly different because of the fact that you now have different displays per View. Probably the biggest challenge was getting a dependent drop-down to show all the displays for whichever View is selected. Let's just say I had an interesting journey through the Forms API, after my initial naïve effort that simply used AJAX to replace the options in the drop-down (synopsis: you can't add new elements or even select options to Drupal forms via AJAX without telling Drupal about them - see here for more info: http://drupal.org/node/150859). And the end result is a Quick Tabs creation form which may well get the prize for highest concentration of AJAX and AHAH craziness - which is not necessarily a good thing, as I'm worried my issue queue will prove soon enough.

Actually, the real low point came after I had done the bulk of the work and then suddenly it seemed that the new Views was so powerful it totally reduced the benefit of being able to add a View directly into a Quick Tabs block over just adding that View's block display (i.e. just adding a block that happens to come from a View). Well, fortunately, that's not quite true. The ability to use the same View in multiple tabs but passing in different arguments each time (an example of which is the "My Favourite..." QT block in my right sidebar) is, I think, justification enough for my continuing to include Views integration in Quick Tabs. I'm looking forward to feedback on this question.

Next on my to-do list: SimpleTest unit tests for Quick Tabs. And I might even request some Drupal Tough Love for it... if I dare!