We spent a few hours trying to figure out how to use Color to make our custom Drupal 6 theme configurable. Color rewrites your CSS to include the user-configured colours, and adds the resulting stylesheet link to your header.

The first trick was to get the colour picker to show up on the theme settings page. The documentation wasn’t clear, but the easiest way to get started seems to be to copy the color/ directory from the Garland theme into a subdirectory of your theme, and then customize it from there. You will also need to follow the Drupal 6 or Drupal 7-specific instructions for calling the Color module when preprocessing pages.

Color searches your style.css (and imported stylesheets or other stylesheets defined by the ‘css’ part of your $info array) for colour definitions. Any colour that exactly matches one of the colours defined in the default scheme is replaced by the colour in the selected scheme, with the caveat that the base colour should not appear in the stylesheet. If the base colour is found in the stylesheet, it will be replaced by an empty string. In your stylesheet, make sure your base colour uses the shortened version (ex: replace #cccccc with #ccc) or use a very similar colour instead (ex: #cbcbcb).

So, the easy way to colourize your theme:

1. Enable Color, if you haven’t yet.
2. Copy the color directory from the Garland theme into your theme

Color will attempt to figure out unspecified colours based on those colours’ relationship with the base colour. This can lead to interesting combinations. If there are colours you do not want Color to change, put them in a section after a comment like this:

/*******************************************************************
 * Color Module: Don't touch                                       *
 *******************************************************************/

All colours specified after that comment will not be rewritten.

Some gotchas to watch out for:

• It’s probably a good idea to add a comment to your style.css reminding developers to resubmit the colour settings after making changes to the stylesheet. Color rewrites the stylesheet, so changes aren’t picked up until the stylesheet is regenerated.
• The Color preview appears to use hardcoded HTML. The gradient is created by color.js, and there doesn’t seem to be a way around it. Our workaround is to use CSS to hide both the preview and the header above it. Unfortunately, there is no div that encloses both the header and the preview.

“Why is your window transparent?” a coworker asked me when she noticed my screen. I told her about how I do my CSS theming, and she pulled another coworker over and made me repeat the explanation. Since that seems like something other people might find handy, here it is.

Sass: Syntactically Awesome Sytlesheets

I rarely do CSS/front-end theming work, but when I do, I try to make it as fun and easy as back-end development. I use Sass (Syntactically Awesome Stylesheets) so that I can use nested selectors, variables, and mixins. This makes my code cleaner and easier to write. You’ll need Ruby in order to install Sass, but the tool will give you CSS that you can use on any web platform.

Browser-based tools

I prefer doing the initial tweaking in Google Chrome, because I like the way that the developer tools make it easy to modify the stylesheet. The Chrome CSS Reloader extension is handy, too. Most of the time, I make my CSS changes in the text editor, then use the CSS Reloader to reload the stylesheet without refreshing the page. This makes it easy to manually toggle the display of some elements while allowing me to refresh style rules. If I want to figure out the values for a few simple changes, I’ll sometimes make the changes directly in Chrome (you can use arrow keys to adjust values), then copy the values to my Sass source file.

Colors, sizes, and spaces

A second monitor is totally awesome and well worth it.

Designs rarely specify all the colours, sizes, and spacing needed. To quickly get the color of a pixel, I use WhatColor. This shows the hex code for colors, and allows me to quickly copy the code with the F12 shortcut key. If you want to change the shortcut key, the source is available as an AutoHotkey script.

To make it easier to match sizes and spaces, I use WinWarden to make my browser window 20% translucent. Then I carefully position it over my design reference until the important features match. Magnifixer makes it easier to line things up because it can magnify a fixed portion of the screen. By focusing Magnifixer on the part I’m working on, I can tweak CSS without straining my eyes.

When I know I’m going to be making a lot of changes, I use AutoHotkey to map a shortcut so that I can refresh the CSS with one keystroke instead of several. When I happen to have my USB foot pedal handy, I rig it up to refresh my stylesheet.

Regression testing

Sometimes my CSS changes modify other rules. Instead of laboriously checking each page after changes, I’ve figured out how to use Selenium WebDriver to write a Java program that loads the pages in Mozilla Firefox and Internet Explorer, capturing screenshots and numbering them according to the pages in my design reference. This means that I can run the program in the background or start it before taking a break, and then flip through all the screenshots when I get back.

Cross-browser testing

What’s CSS theming without the requirement of browser compatibility? Someday, when I need to deal with more browsers, I might look into Selenium RC. In the meantime, I develop in Chrome, my Selenium-based program makes it easier to test in Firefox and IE, and it’s easy enough to try the URLs in Safari as well. Virtual machines handle the rest of the requirements. 

So that’s how I’ve been doing CSS theming on this project. What are your favourite tips?

The clients wanted a quick way to jump to the latest revision of a node. I was delighted to discover that the Finder module made it easy to create an autocomplete shortcut to nodes and users. It offered way more features than I would’ve coded myself. Finder lets you match nodes on title, author, CCK fields, and so on.

There’s a simpler module called Node Quick Find, but I’m going to go with Finder for now because of the options that Finder offers.

There was one small thing I needed to tweak. Finder Node goes to node/nid, but we’ve got Revisioning set up to view the current revision of a node and not the latest. Fortunately, Finder took that into account and provided enough hooks to let me change the behavior. Here’s what I needed to do:

function mymodule_finder_goto_alter(&$result, &$finder) {
  $finder->base_handler['#module'] = 'mymodule';
}

function mymodule_finder_goto($finder, $result) {
  $vid = revisioning_get_latest_revision_id($result->nid);
  drupal_goto('node/' . $result->nid . '/revisions/' . $vid . '/view');
}

You’ll want to use more if logic if you’re working with different kinds of Finders, of course, but this was enough to handle what I needed. Hooray for hooks!

Finder doesn’t seem to support Features, so I’ll need to configure things again once I move to production. No problem! I’ve added some notes to myself in the issue-tracking system we’re using, and I’ve asked the clients to try this new shortcut out.

Drupal: There’s a module for that.

2011-09-02 Fri 14:17

Fatal error: Unsupported operand types in …../patched/rules/rules/rules.module on line 347

That was the error message Daniel sent me when he asked for my help in debugging. After some digging, I found out that the rules had been defined in two features, so Drupal got thoroughly confused. After I commented out one of the implementations of hook_rules_defaults and deleted the relevant rows from rules_rules in the database, the site worked again.

Daniel wanted to know how I figured out that problem, so here’s the story.

The line number told me that rules_sort_children was having problems. I added a var_dump to it so that I could find out what kind of unexpected data was causing the errors.

if (!is_numeric($element[$key]['#weight'])) { 
  var_dump($key, $element[$key]['#weight']); 
}

The output showed that the regular rules were fine, but our custom rules weren’t – weight was an array instead of an integer.

I looked at the difference between the features in code and the features in the database. The rules were being duplicated. I tried updating the features to match the information in the database, but the code looked wrong, so I used git to stash the changes. I also tried reverting the features, but that didn’t solve the problem either. Time to dig deeper.

I backed up the database, then deleted our custom rules from rules_rules. Still problematic. I commented out the rule definitions in our site_structure.features.inc. The rules administration page now successfully displayed – but mysteriously, the rule definitions were still available.

I looked at the rule tags to see where else they might be defined, and found that another feature had included the rules. Aha! I commented those out. As expected, the rules disappeared from the administration page. I’d identified the problem: the rules had been defined in more than one module, which had thoroughly confused Drupal.

Because it made more sense to define the rules in our site_structure feature than in the other feature, I uncommented the site_sitestructure_rules_defaults definitions and left the other feature’s rules commented. That worked.

I tried restoring the rule customizations from the database, but that gave the same error. The database copy had multiple definitions, and I didn’t feel up to picking my way through the data or writing a Drush script to manipulate the rows. I re-deleted the customizations to get a clean copy. Just in case the other feature had more recent definitions of the rules, I compared the two. Aside from the extra tag, they were identical, so I didn’t need to copy any information over. It meant that Daniel would have to make his changes again, though.

Features: When it’s good, it’s very very good. When it’s bad, it results in quirky bugs. Make sure you don’t define your rulesets in multiple features. Drupal Features still has some rough spots when it comes to Rules. I remember when I created this feature with the rules in it – it created duplicate rules, so I needed to delete the old ones. Still, it’s a great way to export rules and other configuration changes to code, even though it takes some getting used to (and the occasional bit of database-diving).

Anyway, that’s the story of how I identified that issue and worked around it.

When you’re faced with a fatal error involving unsupported operand types, figure out what kind of operands it expects and print out anything that doesn’t match. Then you can start figuring out the real problem, which is how that data got in there in the first place. I’ve used this to find form elements that were mistakenly defined, array elements that were unexpectedly null, and so on. Don’t be afraid to add debugging code to core or contributed modules, particularly if you can use source code control to restore a clean copy. If you use a runtime debugger like XDebug, you can easily explore the data and the call stack. If not, there’s always var_dump.

Hope that helps!

I’m wrapping up a Drupal 6 project which was funded by one of IBM’s corporate citizenship grants. The Snake Hill folks we’ve been working with will continue working with the client until they’re ready to launch. For my part, I’ve been in user acceptance testing and development mode for almost a month, rolling out new features, fixing bugs, and getting feedback.

The project manager has shuffled some hours around and made sure that I’ve got some “support” hours for follow-up questions after we turn the project over.

What worked well

Hey, I can do this stuff after all! I gathered requirements, estimated the effort, negotiated the scope, communicated with the clients and other team members, and generally did other technical-lead-ish stuff. I’ve done that on other projects, but usually that was just me working by myself and talking to clients. This one was more complex. It was fun figuring out what would fit, how things were prioritized, whether or not we were on track, and how to make things happen. I’d love to do it again. (And with the way the world works, I will probably get an opportunity to do so shortly!)

Understanding a project deeply: I was on the first phase of this project as well, and the experience really helped. We didn’t have any disruptions in technical leadership on our part, unlike in the first phase. See, last year, the IBM technical lead who had been talking to the client ended up leaving the country, so we had to repeat a few discussions about requirements. This time, I could draw on my experience from the first phase and our ongoing discussions about the client’s goals for the project. That was fun.

I’ll be turning the project over to the other development company, and the client’s concerned about whether they’ll be able to pick things up and run with it. I’ve tried to write down as many notes as I can, and I also invested time in briefing the other developers on the overall goals as well as the specific work items. Hope that works out!

Externally-accessible issue tracking: In the previous phase of this project, issue tracking consisted of e-mailing spreadsheets around. It was painful. One of the first things I did when we started this phase of development was to set up a Redmine issue tracker on the client’s server. After we gathered and prioritized requirements, I logged them as features in Redmine and split them up over the different phases. I reviewed our list of outstanding work and filed them as bugs, too. As feedback came in, I tracked bugs. I took advantage of Redmine-Git integration and referred to issue numbers in my commit messages. When people e-mailed me their feedback or posted messages on Basecamp, I created issues and added hyperlinks.

Having an externally-accessible issue tracker helped me worry less about missing critical bugs. I also shared some reporting links with the clients and the project manager so that they could track progress and review the priorities.

On future projects, I would love to get to the point of having clients and testers create issues themselves. Wouldn’t that be nifty?

Git for version control: I’m so glad I used Git to manage and share source code between multiple developers. The other developers were fairly new to Git, but they did okay, and I figured out how to clean up after one of the developers wiped out a bit of code after some commit confusion. Git stash and git branch were really helpful when I was trying lots of experimental code.

Developing with a non-default theme: We had a lot of development items to work on while the No.Inc creative team got their Drupal theme together. Once No.Inc sent the theme, I layered it on top of the site, fixed the usual problems, and had even more fun working on a site that looked halfway done. Definitely recommend getting a reliable theme in place sooner rather than later.

Mentoring people: I helped a new developer start to get the hang of Drupal. It was a slow process (must raise estimates even more when dealing with newbies), but I hope the investment pays off. I wrote (and updated!) documentation. I identified small tasks that he could work on first. I checked on him every so often. I successfully resisted the urge to just do things myself. Slowly getting there…

Decision log: I used a wiki to keep track of the design decisions I needed to make, the alternatives I considered, and what I eventually chose. That was helpful for me. I hope it will help future developers, too.

Linux VM on a Microsoft Windows host, XMing, and Plink: I’ve tried lots of different configurations in the course of this project. Doing my development inside a virtual machine has saved me so much time in terms of restoring from backup or being able to tweak my operating environment. I started with a Linux VM on a Windows host, using Samba to access my files and either Eclipse or Emacs to edit them. That was a bit slow. Then I shifted to a Linux VM on a Linux host, SSHing to the VM and using Emacs from the VM itself. That was great for being able to do Linux-y stuff transparently. But then I found myself wanting to be back on Microsoft Windows so that I could use Autodesk Sketchbook Pro (Inkscape and MyPaint aren’t quite as awesome). I ran XMing to create an X server in my Windows environment, used plink to connect, and then started a graphical Emacs running on my virtual machine. Tada! I could probably make this even better by upgrading to 64-bit Microsoft Windows, adding more RAM, and upgrading to a bigger hard disk. (Alternatively, I could host the VM somewhere else instead of on my laptop…)

What I’m going to work on improving next time

Better browser testing, including cross-browser: I’m getting slightly better at testing the actual site, motivating myself with (a) interest in seeing my new code actually work, (b) the remembered embarrassment of gaping bugs, and (c) the idea of slowing down and getting things right. Juggling multiple browsers still doesn’t make me happy, but maybe I can turn it into a game with myself. Selenium might be useful here as well.

Continuous integration: I set up Jenkins for continuous integration testing, but it fell by the wayside as I wasn’t keeping my tests up to date and I wanted more CPU/memory for development. I ran into a number of embarrassing bugs along the way, though, so it might be worth developing stricter discipline around this. I’m still envious of one of the Drupal projects I heard about in IBM, which got through UAT without identified defects thanks to lots of manual and automated testing. If I add more power to my development machine or offload testing to another machine, that might be a good way to stick to this process.

Closer communication with clients and external developers: We set up short daily meetings for the developers, but sometimes people still felt a little lost or out of touch. On future projects, I’ll make sure the clients have it on their calendar as an optional meeting, and maybe see about getting e-mail from people who can’t join on the phone. If I’m the tech lead on a future project, I’ll sit in on all client status update meetings, too. We found out about some miscommunications only when I handled one of the status calls. Fortunately, it was early enough that we could squeeze in the critical functionality while reprioritizing the others. Tense moment, though!

Better vacation planning: I realized we had a 4-day weekend the week before we had it, and we forgot about some people’s vacations too. Heh. I should get better at looking at the entire project span and listing the gaps up front.

Earlier pipeline-building: I nudged some project opportunities about a month before our projected end date, but that wasn’t long enough to deal with the paperwork lag. Oh well! Next time, I’ll set aside some time each week to do that kind of future pipeline-building, and I’ll set myself reminders for two months and a month before the project ends. Not a big problem.

My manager’s been lining up other Drupal and Rails projects for me to work on. Looking forward to learning all sorts of lessons on those as well!

Other Drupal lessons learned:

• June 2009
• April 2009
• Lots of Drupal-related posts

2011-08-10 Wed 17:08

Drupal autocompletion is easy – just add #autocomplete_path to a Form API element, set it to something that returns a JSON hash, and off you go.

What if you want to pass form values into your autocompletion function so that you can filter results?

Searching, I found some pages that suggested changing the value in the hidden autocomplete field so that it would go to a different URL. However, that probably doesn’t handle the autocomplete cache. Here’s another way to do it:

Drupal.ACDB.prototype.customSearch = function (searchString) {
    searchString = searchString + "/" + $("#otherfield").val();
    return this.search(searchString);
};

Drupal.jsAC.prototype.populatePopup = function () {
  // Show popup
  if (this.popup) {
    $(this.popup).remove();
  }
  this.selected = false;
  this.popup = document.createElement('div');
  this.popup.id = 'autocomplete';
  this.popup.owner = this;
  $(this.popup).css({
    marginTop: this.input.offsetHeight +'px',
    width: (this.input.offsetWidth - 4) +'px',
    display: 'none'
  });
  $(this.input).before(this.popup);

  // Do search
  this.db.owner = this;
  if (this.input.id == 'edit-your-search-field') {
    this.db.customSearch(this.input.value);
  } else {
    this.db.search(this.input.value);
  }
}

Drupal.behaviors.rebindAutocomplete = function(context) {
    // Unbind the behaviors to prevent multiple search handlers
    $("#edit-your-search-field").unbind('keydown').unbind('keyup').unbind('blur').removeClass('autocomplete-processed');
    // Rebind autocompletion with the new code
    Drupal.behaviors.autocomplete(context);
}

You’ll need to use drupal_add_js to add misc/autocomplete.js before you add the Javascript file for your form.

Hope this helps!

2011-08-08 Mon 19:16

I know, I know. I shouldn’t allow IFRAMEs at all. But the client’s prospective users were really excited about images and video, and Drupal’s Media module wasn’t going to be quite enough. So I’ve been fighting with CKEditor, IMCE, and HTML Purifier to figure out how to make it easier. I’m hoping that this will be like practically all my other Drupal posts and someone will comment with a much better way to do things right after I describe what I’ve done. =)

First: images. There doesn’t seem to be a cleaner way than the “Browse server” – “Upload” combination using CKEditor and IMCE. I tried using WYSIWYG, TinyMCE and IMCE. I tried ImageBrowser, but I couldn’t get it to work. I tried FCKEditor, which looked promising, but I got tangled in figuring out how to control other parts of it. I’m just going to leave it as CKEditor and IMCE at the moment, and we can come back to that if it turns out to be higher priority than all the other things I’m working on. This is almost certainly my limitation rather than the packages’ limitations, but I don’t have the time to exhaustively tweak this until it’s right. Someday I may finally learn how to make a CKEditor plugin, but it will not be in the final week of this Drupal project.

Next: HTMLPurifier and Youtube. You see, Youtube switched to using IFRAMEs instead of Flash embeds. Allowing IFRAMEs is like allowing people to put arbitrary content on your webpage, because it is. The HTML Purifier folks seem firmly against it because it’s a bad idea, which it also is. But you’ve got to work around what you’ve got to workaround. Based on the Allow iframes thread in the HTMLPurifier forum, this is what I came up with:

Step 1. Create a custom filter in htmlpurifier/library/myiframe.php.

<?php
// Iframe filter that does some primitive whitelisting in a
// somewhat recognizable and tweakable way
class HTMLPurifier_Filter_MyIframe extends HTMLPurifier_Filter
{
  public $name = 'MyIframe';
  public function preFilter($html, $config, $context) {
    $html = preg_replace('/<iframe/i', '<img class="MyIframe"', $html);
    $html = preg_replace('#</iframe>#i', '', $html);
    return $html;
  }
  public function postFilter($html, $config, $context) {
    $post_regex = '#<img class="MyIframe"([^>]+?)>#';
    return preg_replace_callback($post_regex, array($this, 'postFilterCallback'), $html);
  }
  protected function postFilterCallback($matches) {
    // Whitelist the domains we like
    $ok = (preg_match('#src="http://www.youtube.com/#i', $matches[1]));
    if ($ok) {
      return '<iframe ' . $matches[1] . '></iframe>';
    } else {
      return '';
    }
  }
}

Step 2. Include the filter in HTMLPurifier_DefinitionCache_Drupal.php. I don’t know if this is the right place, but I saw it briefly mentioned somewhere.

// ... rest of file
require_once 'myiframe.php';

Step 3. Create the HTML Purifier config file. In this case, I was changing the config for “Filtered HTML”, which had the input format ID of 1. I copied config/sample.php to config/1.php and set the following:

function htmlpurifier_config_1($config) {
  $config->set('HTML.SafeObject', true);
  $config->set('Output.FlashCompat', true);
  $config->set('URI.DisableExternalResources', false);
  $config->set('Filter.Custom', array(new HTMLPurifier_Filter_MyIframe()));
}

Now I can switch to the source view in CKEditor, paste in my IFRAME code from Youtube, and view the results. Mostly. I still need to track down why I sometimes need to refresh the page in order to see it, but this is promising.

2011-08-05 Fri 16:34