jQuery is the bread and butter of rapidly developing a highly-interactive websites, and Drupal has long made use of it, and indeed includes it as part of its core install.

There's only one catch... Drupal 6.x (the current stable version of Drupal) is still living in 2008, shipping with the antiquated jQuery 1.2.6. Over the intervening two years since the release of 1.2.6, there have been substantial additions and upgrades to the jQuery library, as well as several tools (such as the jQTouch library) that rely on those changes. As of the writing of this post, the current jQuery version is 1.4.2.

The jquery_update module has done a fantastic job of letting users upgrade the version of jQuery used by Drupal, but unfortunately the jquery_update module got stuck at 1.3.2.

The culprit: a bug in Drupal's core function drupal_to_js(). This function exports a PHP variable into the JS space. The issue is that it preforms some text modification to convert characters such as ampersands, angle-brackets, and line endings into their escaped unicode equivalents. Unfortunately, it does not do a very complete job and as a result, many issues arise when jQuery is upgraded to 1.4.2.

As is often the case, the Drupal community stepped up and created a patch that fixes the issue (for your convenience, I've attached this patch below). Unfortunately, after more than six weeks, there has been little-to-no movement to include the patch in future releases of Drupal 6.x. This leaves us with the distasteful, but worthwhile, task of repatching the core whenever a new core update is released.

Anything involving Eclipse is always epic. First, you have to get your head around what distribution of it to use, as confusing as one's first introduction to Linux distributions (there are different kinds of Linux?).

Next, you have to grok the fact that the Zend Debugger must be installed on your server. In this case, MAMP.

Then, you have to make Eclipse listen to the debugging information being outputted, on the debug port.

Finally, you have to figure out how to use a debugger effectively (not in scope, but careful, debugging will blow your mind).

I started with this screencast, lulled by his easy manner of speech. The directories in MAMP are slightly different, like 5.2 and 5.3 instead of whatever he said. Not a big deal, just noting it.

Great! I hit "Test Debug" and...

Test Debug Server: Web server connection failed. Please verify that the address ....

So then I went to:
Eclipse -> Preferences -> Debug -> Installed Deguggers

And change the Zend debug port to whatever the output of your phpinfo gives you, which in my case was 65535.

I knew something was happening at that port because
telnet 127.0.0.1 65535
and typing some random stuff produced errors with the word "debugger" in it (thanks for the tip, Dan).

But it turns out the real problem was that there was a superfluous
zend_extension = "/Applications/MAMP/bin/php5.2/lib/php/extensions/no-debug-non-zts-20060613/xcache.so"

in my php.ini file. Anyone else notice that these config files get kinda crufty even without touching them?

Commented it out and now I get a happy:

Test Debug Server: Success!

Thanks much to Rebecca Janine Wise for her excellent post with configuration errata. Definitely worth a read if you are configuring Eclipse PDT.

Open Atrium (http://www.openatrium.com) is best described as an "Intranet in a box" that sits atop Drupal 6. With the release of Open Atrium 1.0-beta4, Development Seed made a few crucial changes to the way OA is configured and structured. Now at beta7, there are still some older OA sites out there that are still running versions prior to beta4. Those sites require a little extra work to upgrade since they need to be upgraded to beta4 first, and then can be upgraded to beta7 and beyond.

It should also be noted that each release of Open Atrium contains a version of the Drupal core as well. I do not personally know if there are any potential issues with upgrading the version of Drupal independently of Open Atrium, but I do know that updating Open Atrium will typically upgrade the Drupal Core as well.

The basic steps for upgrading Open Atrium to beta4 are straightforward, but there are a couple pitfalls that you should watch out for:

1. Make sure you have a backup of EVERYTHING (your codebase, your database, etc)
2. Do NOT visit your site in a browser until you've finished all of the steps

After observing the above pitfalls, start with a fresh beta4 codebase and copy over your files and contributed modules.

Next, make sure you follow the section titled "Upgrading from Atrium 1.0-beta3.x to 1.0-beta4" located here: http://drupalcode.org/viewvc/drupal/contributions/profiles/openatrium/UP...

Items 1, 2, and 3 are mission critical. Using drush:
drush vset install_profile openatrium
drush cc all
drush updatedb

Before beta4, OA did not use the install_profile variable. Starting with beta4, if you don't have this variable, you will at best be stuck with the pre-beta4 themes and features. At worst, you'll be stuck on either an unthemed site or a garland Drupal.

The stock "Send Email" action type that ships with Drupal 6 does't offer a whole lot of options for including content from comments in your triggered emails.

In fact, it doesn't offer any.

There has been a good deal of discussion on this: a patch has been proposed and a stop-gap helper module has been posted to drupal.org.

Before you go that route, though, check out this post on using the Token Actions module to provide access to the full array of available tokens in your email. Thanks to Erik Weik at New Rivers Digital for the great post.

We're using Trigger-based email notifications to fight spam and help our clients be engaged with their commenters.

How do you use and implement comment notifications?

So when working with a dev site, I couldn't figure out why my changes to CSS weren't propagating.

I turned off the boost module, cleared the cache, restarted apache.

Then I realized that Apache must be actually not getting to the file. And the only place to do that in Drupal is the .htaccess file.

Viola! Remove this from your .htaccess:

 ### BOOST START ###
  AddDefaultCharset utf-8
  <FilesMatch "(\.html|\.html\.gz)$">
    <IfModule mod_headers.c>
      Header set Expires "Sun, 19 Nov 1978 05:00:00 GMT"
      Header set Cache-Control "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"
    </IfModule>
  </FilesMatch>
  <IfModule mod_mime.c>
    AddCharset utf-8 .html
    AddCharset utf-8 .css
    AddCharset utf-8 .js
    AddEncoding gzip .gz
  </IfModule>
  <FilesMatch "(\.html|\.html\.gz)$">
    ForceType text/html
  </FilesMatch>
  <FilesMatch "(\.js|\.js\.gz)$">
    ForceType text/javascript
  </FilesMatch>
  <FilesMatch "(\.css|\.css\.gz)$">
    ForceType text/css
  </FilesMatch>
 
  # Gzip Cookie Test
  RewriteRule boost-gzip-cookie-test\.html  cache/perm/boost-gzip-cookie-test\.html\.gz [L,T=text/html]
 
  # GZIP - Cached css & js files
  RewriteCond %{HTTP_COOKIE} !(boost-gzip)
  RewriteCond %{HTTP:Accept-encoding} !gzip
  RewriteRule .* - [S=2]
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz -s
  RewriteRule .* cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css\.gz [L,QSA,T=text/css]
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz -s
  RewriteRule .* cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.js\.gz [L,QSA,T=text/javascript]
 
# NORMAL - Cached css & js files
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css -s
  RewriteRule .* cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.css [L,QSA,T=text/css]
  RewriteCond %{DOCUMENT_ROOT}/cache/perm/%{SERVER_NAME}%{REQUEST_URI}_\.js -s

Let's start here: Drupal for Firebug is amazing. I'll even go so far as to say that it's more useful than Devel Themer. More details below, but you should start by downloading the Drupal for Firebug Firefox extension (or the Chrome one) and drush dl drupalforfirebug on a local project and giving it a spin.

So, in my last post, I upgraded to bleeding-edge jquery, hacking the jquery update module. Yay.

How do I tell my systems administration not to blindly drush upgrade that module?

The answer? The hacked module.

It will diff your module files against those in Drupal's CVS and tell your sysadmin not to upgrade a module.

Here's what you see:

In the process of implementing a design today, the javascript provided required jquery 1.4 as a dependency.

What is the answer to this problem?

NOTE: See this more recent post on adding jQuery 1.4 to Drupal

A couple of resources:
jQuery No Conflict allows you to load multiple version of jQuery on the same page for different code.

jQuery update module allows you to get up to jQuery 1.3 in Drupal 6.

If you try to upgrade to 1.4 on your global Drupal install, you will break your Drupal.

Ok, So basically I had a listing of books set as a view. Some books were available in Hardcover, Paperback, and Digital. Unfortunately, the client wanted these books to have completely different information, except description, title, and image. In order to have that, we needed to create separate nodes for each version. This caused another problem.

Now in my listing, there were three nodes back to back with the same title, image and description. The client wanted these nodes to show as a single row in the view. I thought, easy enough, I will just add a group by statement. I know you are going to tell me I could have edited the query object, and I tried that... but apparently views disabled support for that. My solution, hijack the actual MySQL statement before it runs, and edit it.

Here is the snippet:

<?php
function publications_views_pre_execute(&$view){
  if ($view->name == 'publications_category')
  {
    $search = array('ORDER BY');
    $replace = array('GROUP BY node_title ORDER BY');
    $view->build_info['query'] = str_replace($search, 
                                             $replace, 
                                             $view->build_info['query']);
    $view->build_info['count_query'] = str_replace($search, 
                                                   $replace, 
                                                   $view->build_info['count_query']);
  }
}
?>

While trying to use the Context module's menu context conditions, I noticed that certain pages, though in the menu tree "Primary Links" were not properly passing the proper active menu to the context module.

Helpful: Using the Devel module's Context Inspector block to figure out if the context was failing to be called.

Bryn and I worked out that this was likely a problem with Drupal's menu system.

Helpful: Using Devel's PHP Execute block to call various menu functions from Drupal's Menu API page to inspect what the active menu trail was.

Helpful: pasting in this block of code to see what was the matter dpm(menu_get_active_trail());

We found that calling menu_set_active_menu_name('primary-links') set the active menu properly.

Now, where and how do we call that function?

Ctools uses a nice snippet that can be pasted into a helper module.

Here's what worked

The module Menu Breadcrumb uses a variant of this function to unbreak the Drupal menu system.

So as an alternative to pasting this code into a module, you can try installing Menu Breadcrumb and see if your life is magically better.

I've just released version 2.3 of the Sites module, which has been quietly under off-and-on development for a couple of months now here at EchoDitto Labs. Sites was originally conceived as a way to make it easy to create multi-site Drupal configurations without the problems and complexities incurred by using Domain Access. Sites is a less-articulated solution than Domain Access: it has fewer features at present, and does not integrate as deeply into the Drupal access stack, but is consequently more stable. Most importantly, it avoids rebuilds of the node_access table, which can be slow (and, in the case of very large sites, can even cause your servers to grind to a halt).

There are several considerations that came into play in the decision to write the module. First, we wanted to be able to create multi-site installs of Drupal wherein some views could show content existing across sites, while others could discriminate between those sites and show only content from the current site. If we simply created a new folder under /sites, there would be no clean way to know at the level of the controller (nodeapi, Views, etc) what site was being used to access content. Furthermore, if we decided to segregate content into different databases, it would be difficult to share that content across sites (the easiest alternative would probably be to publish feeds, which seemed like far more trouble than should be necessary).

On a site we're starting to build, Drupal's core "Sticky at top of lists" functionality isn't necessary (using Nodequeue for lists), but nodes need to be included or excluded from search results on a per-node basis. Rather than create a custom CCK field, and since we're building search (as usual) through Views, I decided the simplest answer was to rename "Sticky" to "Appear in Search Results," and filter accordingly in the view.

So how to do this? hook_locale() only works on non-English languages (see t()) and seems to define groups rather than strings.

The simplest solution, it seems, is to use settings.php (or in this case, a common.settings.php used by all the others). Like so:

I've started using and loving the Popups API module. It allows other modules to create lightbox-type ajax popups of other pages and forms. Out of the box, it includes the option to convert several admin UI pieces into popups, like the Configure Block links, Taxonomy Add/List/Edit links, etc. Saving a few seconds here and there adds up to a lot of time!

(Note: Make sure to set the Content Selector in your theme settings (/admin/build/themes/settings/themename). The default is strange, but in most themes div#content should do it.)

This week, I released a Drupal 6 module called Environments (shortname Envts), my first released module and EchoDitto's first for Drupal 6. Its purpose is to help developers manage "two-dimensional" Drupal site environments. Drupal is fairly good at running multi-site builds, with sites folders and different settings.php files. Modules like Domain Access are good at managing those sites one-dimensionally - a single list of hosts with primary (mysite.com), secondary (special.mysite.com), etc, and deep integration with Views and other modules.

But this single list of sites is built for one environment: one set of domains, such as for a live site. For example:

• dartcenter.org [primary]
• dartsociety.org [secondary]

Domain Access is good at listing these domains and filtering nodes by them. But in our work, there's never only one environment. There's a development environment -

• dartcenter.dev.echoditto.com [primary]
• dartsociety.dev.echoditto.com [secondary]

- and each developer usually has a local server environment -

• dartcenter.ben.local [primary]
• dartsociety.ben.local [secondary]

- and sometimes there's a staging server between dev and live -

• staging.dartcenter.org [primary]
• staging.dartsociety.org [secondary]

- and so forth.

After working on some 50-odd Drupal projects over the past few years and inheriting a number of (often questionable) others, it occurred to us it'd be a good idea to have a script that detects hacks and/or "modifications" to Drupal core for a given Drupal install. The result is this remedial PHP script (or core agent) that detects your version of Drupal, downloads the appropriate tarball from Drupal.org, runs a diff on /modules, /misc and /includes, and returns you the results.