Advanced Theme Construction Kit (ATCK) updated for Drupal 6

The Advanced Theme Construction Kit, which integrates a derivative of the Yahoo grids CSS library within a Drupal framework, was updated and released for Drupal 6 today.

Something new
After religiously following the changes to Drupal 6's theme-layer for many months now, as well as actively coding a Drupal 6 module for the past month and a half, I was thinking that upgrading ATCK was going to be a snap...

In some ways it was, but the Drupal 5 to Drupal 6 theme conversion was by far the most complicated theme update I've seen since being involved with Drupal (4.5 onward). As it turns out the Drupal 5 template.php file for ATCK was almost completely useless, and it was with great thanks that I (again) borrowed heavily from Hunchbaque's template.php in order to get the desired granularity for classes/id's.

One area I did depart from core and the Hunchbaque theme on is the handling of css files. Allowing for the possibility that there is something that I'm 'missing', I can't say that I'm currently very happy with Drupal's new method of adding stylesheets via .info files, nor with the functions that Hunchbaque currently uses in it's template.php to add IE-only css. The core method of stylesheet handling makes stylesheets a bit of a pain to refresh, and I found both methods to be unreliable with respect to conditionally adding stylesheets.

In the end 'old fashioned' conditional statements were implemented within page.tpl.php, and a custom function added to template.php. Along with being reliable, this combo provides the ability to tell Drupal to NOT import specific core css files (e.g., if you don't want the node.css file loaded - simply add a line to the function inside ATCK's template.php and node.css never gets loaded).

Something old
The most satisfying part of the upgrade was that the centerpiece of ATCK, the Yahoo Grids-inspired CSS library, did not require a single change. So this part has proven to indeed be modular and Drupal version independent. :-)

Future development plans for ATCK
* Possibly add the edit functionality that the Zen theme has introduced to make managing blocks and views easier.


HigherVisibility is looking for assistance!

15 March, 2008

Speeding up Drupal Forums

The Drupal forum.module has become, well, somewhat infamous for less than awesome scalability. Recently I had a chance to see this firsthand, and track down a solution for managing the long page load times for a client who has a highly trafficked forum. This was not a case of a site that was un-tuned - actually this particular site had a lot of good work and performance enhancements already done to it, including block caching and even some modifications to the forum module that were allowing to work better than it would have without them. But still 5-6 second page load times on /forum persisted.

As this was my first time working on the site, I began by reviewing all of the main configuration files for Apache, MySQL, and PHP, since they are the foundation for everything else. After making some adjustment there, I headed over to the Drupal admin interface and check /admin/setting/performance/ and made sure all was happy there as well. Finally, I went to the block admin page and double-checked all of the blockcache settings, which as it turns out were set a bit to aggressively, resulting in slow form submission times (every time anyone submitted anything a gazillion blocks were being re-cached whether they need to be or not).

With the foundation of the site now looking good and everything, except the forum pages flying along (and the tracker, but that's a story for a later article) - it was just down to forum.module.

Here are the steps that led to cutting the page load time in half from what they were:

1. Disable the forum.module, rename it to something like "forum.module.orig", make a copy and then rename the copy "forum.module".

2. Download the advcache module and apply the forum patch includes to your new copy of the forum.module.

3. If want the cleanest solution and are comfortable with coding/debugging at all, instead of just copying the forum module and working on it directly (and thus having a hacked Drupal core file around all the time) - name the copied file something completely different than forum.module and edit all of the hook/function calls with in it with new name and place it where you keep the rest of your contributed modules.

4. (Note: this step is an option only if all your forums are public)
Open the module and remove all references to db_rewrite_sql. This will keep Drupal from doing a lot of expensive and uneccesary queries in order to check access rights. (thanks Khalid)

28 February, 2008

Dev Mashup: Building a dual MySQL 4.1 and MySQL 5 dev environment in OS X 10.5 Leopard (and more)

I've been wanting to upgrade to MySQL 5 for a while now, and after hearing that MySQL 5 is required for Drupal 7 I decided to bump up my upgrade schedule, pronto. If all one wants is MySQL 5 then that is easy enough -- go download MAMP and you're done. But what if you want to be able to dev on MySQL 4 for projects that require it for whatever reason (e.g., clients who are run it and are not willing/able to upgrade MySQL at the moment)?

Well, with not a lot of effort - it very easy to have a PHP 5, PHP 4, MySQL 5, and MySQL 4.1 environment - all sharing the same doc root and servernames (e.g., urls):

Step one:
Configure Apple's native Apache, PHP, and add a free-standing MySQL 4.1 install (since MAMP comes with MySQL 5, right). Here are two good links to get you on your way to doing this:
Install Drupal on Mac OS X 10.5 Leopard
Working with PHP 5 in Mac OS X 10.5 (Leopard)

...if you are migrating a free-standing MySQL install from a previous install you may want to check these articles out (1, 2) as well.

Note: Getting all of this totally set up and working right, including setting up your virtualhosts and /etc/hosts file, before installing MAMP will pay off.

Step two:
Download MAMP and follow the readme.txt instructions and/or use these links to setup the basics:
HowTo: Create a local environment using MAMP
Install a Local Web Server on Mac OSX

Step three:
Now it's time to integrated these two completely separate environments so that you can keep a common doc root, virtualhosts, and urls, and systems tools (we'll get terminal access going for MAMP's MySQL):

We'll make it so that we can keep all of our sites, no matter which enviroment they require, in a common place -- and so that no matter what we're running we will always be able type in "localhost", or and know that it will take us to our doc root (instead of having to remember to type "localhost:8888/" for MAMP:). Relatedly, doing the steps below lets us keep common server names (e.g., 'mysite.local') across environments.

So now:

* Change the docroot in MAMP's httpd.conf (line 368) to:
DocumentRoot "/Library/WebServer/Documents"

15 February, 2008

jQuery UI 1.5 and jQuery Enchant 1.0 alpha work with Drupal 6!

The jQuery team has just released an alpha of jQuery UI 1.5 and jQuery Enchant 1.0, both of which will work with Drupal 6, as it is stated that the minimum requirements for the alphas are identical to the version of jQuery that ships with Drupal 6!

Some links to help you get your tinker on:



[Note: even if the jQuery version requirements for UI and Enchant change at some point before the final release, rest assured that someone in the Drupal community is sure to make an upgrade path available] ;-)

10 February, 2008

Hyper-dynamic Drupal sites with Panels and Views

The motivation for writing this article came from my feeble attempts at trying to discuss a module I'm actively working on (to be covered in a future article) with several very intelligent Drupal developers. Due to the inherently abstract nature of the issues, and for lack of a common language, the end result was that in every case each person just ended up scratching their heads at me without really comprehending what I was really trying to get at.

Hyper-dynamic defined
Technically speaking, Drupal offers a dynamic framework right out of the box, right, so what is meant by "hyper-dynamic"?

Hyper-dynamic, for lack of a better description, refers to sites/sections-of-a-site for which pages do not exist as individual nodes, AND which (for example) are more complex than a single static view/panel. A panel/view which takes arguments, particularly multiple arguments, is an example of hyper-dynamic content delivery.

Getting down to business...
How is this idea of hyper-dynamic content useful and/or or what are the use cases?

As a 'simple' example, let's say we have a multi-regional travel site which caters to people looking for info/deals on casinos. For each region, we'd like to have a separate homepage, AND separate landing pages for each casino within the region. Finally, let's throw in a "Deals" subpage for every region/casino.

So the site hierarchy would look like this:

Name that tune
The challenge is to figure out the fewest parts we can make this architecture, while still maintaining flexibility/maintainability/upgradability.

In this case, we can accomplish our proposed site hierarchy, for an unlimited number of regions/casinos, with as little as 3 views, 3 panels, 2 content-types, and a handful or arguments:

Views used
1. "Node listing" - provides node-listing for each region/casino determined by arguments. This view is placed in the "Landing panel" (see below).
2. "Deals listing" - provides deals node-listing for each region/casino. This view is placed within the "Deals panel" (see below).
3. "Homepage listing" - provides node-listing for homepage. This view is place within the "Homepage panel" (see below).

Panels used
1. Landing panel - Provides complete landing page for each region/casino based on arguments
2. Deals panel - Provides complete "Deals" subpage for each region/casino based on arguments
3. Homepage panel - Provides homepage. Could theoretically even get away with just using the landing panel for this, but by using a separate one for the homepage we get a little more
flexibility and sanity.

13 December, 2007

Drupal upgrades/updates and how to approach them

Published in: 

There is perhaps no other Drupal-related issue which commands so much attention from site admins, Drupal developers, and Drupal core alike, as the subject of Drupal updates/upgrades.

The Players

Site admins typically want to have the 'latest and greatest' version just for general purposes. This is, of course, very understandable, all other things being equal.

Drupal developers like to be able to keep up with the latest release for various reasons: a) to take advantage of new features, b) to keep their skills current, b) because their clients want it, c) as any bonafide geek knows, it's alway fun to check out the new toys.

Drupal core is always concerned about Drupal updates, well's Drupal core. The project and Drupal itself is dead, or at least frozen in time, if it ceases to innovate at semi-consistent intervals.


In a perfect world everyone - site admins, Drupal devs, and Drupal core are always perfectly in sync - all the time, 24/7.


Keeping up with the current version of Drupal core is not always practical. In some cases it might even be downright detrimental! This statement applies particularly to start-up sites, and/or people who are short on time. But you know what...

...IT'S OK!

Having the latest version of Drupal, in and of itself, will likely have little to do with the success of your site. Though each iteration of Drupal does represent it's own quantum leap forward, that is not to say that versions before it are garbage. While this point may seem obvious to many, I've spoken with numerous people who seem to regard anything but the latest version of Drupal as a 'dinosaur'. That's just silly.

By all means - if time is pressing in on you, or your budget is strained, keep up with the latest security updates for your particular version of Drupal and don't give it another thought until there is a more opportune time to upgrade.

By the way, if the new version of Drupal less than 2-3 months old, this advice especially applies for sites which use numerous contributed modules. While many modules are updated before or soon after a new Drupal release, experience has shown that many others contrib modules do not get upgrades and/or reach stability for at least 2-3 months after the initial release date of Drupal core.

Bottom line

Don't be in hurry for your Drupal upgrade if the timing isn't right. Sometimes good things come to those who wait.

28 October, 2007


Subscribe to RSS - blogs