I have been tearing my hair out a bit trying to figure out how to save a whole taxonomy lineage in Drupal, so that everything tagged with a child term would be tagged with a parent term. In other words, given a taxonomy like:

• 1. United States
  • 3. California
  • 4. Vermont
• 2. Canada
  • 5. Alberta

I want it so that if I tag something as California (term 3), it also gets tagged as United States (term 1). The Hierarchical Select module does this, and much more, but it has conflicts with other Drupal modules I want to use, so I just gave up on it.

Finally, I realized that I could simply turn it around and solve this on the data retrieval end, rather than the data storage end. In Drupal, if you enter a standard Drupal path like /taxonomy/term/1, that shows only nodes tagged as United States, but /taxonomy/term/1/all shows all nodes tagged United States and all nodes tagged with child terms.

I’m trying to build a drill-down directory of professional ski instructors (emphasis on trying — it’s still pretty rudimentary now and doesn’t yet have any instructors really). I realized that I could use the Advanced Taxonomy Blocks module to navigate for the drill down and was looking to create an add-on module or a patch for the module so that I could have it add the “all” to the end of the URL. Then I saw this in the settings:

All you have to do is add the /all to the end of the path. It’s built right in to the module settings (go to /admin/settings/taxonomyblocks and click Configure).

So much thanks to Aaron Hawkins, an awesome drupal developer, for this simple way around my problem.

I’ve finally decided to install MegaSuperDuperCMS because everyone has said it absolutely rocks. But I want that special look, so I started going through all of the available themes or templates or whatever it is the MegaSuperDuperCMS community calls them. I found one, KillerThemeCSS that looks great. It has my colors. It has CSS in the name, so it must be modern and cool and up to web standards. It looks so neat and clean and snazzy and it just makes me think it looks like I mean business. Or perhaps that I mean pleasure, because I most definitely don’t want to look like I mean business.

So now I ask you, “What else should I look at besides the awesome look of KillerThemeCSS?” Here are some things I’ve already looked at. Please add to them or correct my foolishness if I’m just plain looking at something the wrong way.

These are in the order the popped into my head, not necessarily in order of importance (and to some extent the importance will be determined by the degree to which they fail any of these tests).

Content code near the top

Do I really have to look at the code? I hope not. I’m a little worried, because I don’t really know HTML but even so, when I opened it up with View Source, the source was 10 screenfuls long and the main headline for the page was on the ninth screen. Is that a problem?

(Okay, this is not as big a problem as it used to be because the search engines have gotten better at figuring out what’s unique and what’s just repeated “service” content like navigational links and disclaimers and such. Look at the source code for a Google results page and you’ll see they certainly aren’t worrying as much about clean code either. But it’s still better not to confuse Google too much).

Proper use of H1 and H2

So someone told me it’s good to put my page headline in an H1 tag. But when I was looking at the source in the last step, I couldn’t find one? Is that a problem?

(This is unbelievably common and this post was actually prompted because I just looked at a “premium” paid theme that had no h1 or h2 on the front page and no h1 on the content pages).

What’s “above the fold” mean?

I love that stunning header image. It’s crisp, it’s clean, it looks professional and really catches the eye. And it had better catch the eye, because for users who don’t have the mega big monitor that the designer has, that’s all they’ll see because it takes up most of the screen. Is that bad?

(I’m exaggerating a bit, but there seems to be an increasing vogue for themes with such big headers that there’s hardly any content at all above the fold, that is, hardly any meaningful content visible to a user on an average monitor without scrolling).

Color and Contrast

My new theme with grey type on a black background looks awesome dude. Cool. Suave. Perfect for my edgy new music site. Except that nobody on a Mac can read it because their different gamma settings make it more like black on black. Is that a problem? And I really love the emphatic RED TYPE in the green sidebar. Many of my visitors are red-green color blind, so the only way they can see it is by doing “select all”. Is that a problem? I tried this just for kicks. I took a screenshot and loaded it into Photoshop (or was it Irfanview?).
– Converted it to greyscale. I couldn’t read a thing, but nobody has a black and white monitor, so this isn’t a problem right?
– Then I played with the contrast, brightness and gamma (in “levels” on Photoshop; under “Enhance colors” in Irfanview). When I got the gamma up to 1.30 or down to .70 I couldn’t tell my form buttons from the background, but nobody’s monitor is that far different from mine is it?

Font size

I love that font they use and how efficient it is at really packing information onto the page, though it is a bit of a hassle trying to read and hold a magnifying glass at the same time. So I hit CTRL-+ on Firefox and… and… it doesn’t resize. That should be okay though, right because everyone has the same screen resolution as I do and my target audience is all under 40, so they all have good eyes. That’s a safe assumption, right?

All screens wide and small

Hey, it’s a fluid design. That’s awesome! I heard that was the best way to go. It uses all my screen real estate and looks great at 800px and at 1024px. It’s a little hard to read at 1200px because the lines are sort of long. But nobody really opens their browser full screen at 1200px do they? And all those visitors in my logs with 1680px widescreen monitor have their browsers open at a reasonable size, right? They won’t get headaches and lose their place because my lines are 250 characters long, will they? And I don’t worry about those iPhone users because I checked my logs and they only visit one page and leave anyway, so I don’t really need to be concerned with them do I?

(Fluid is okay, but it can’t just let the content area expand up to any line length until it becomes unreadable. It can allow longer line lengths in terms pixels when it has bigger text — so if you’re going for variable line lengths, better to use ems, not pixels. It can allow wider display by rearranging elements at certain break points and intelligently using the screen — that’s the more sophisticated and more rare Switchy McLayout approach.

But with the growing prevalence of widescreens, an infinitely expandable center content area at a small font size is not good. At the same time, the mobile market has increased a lot too [candid admission: and I ignore it completely]. More and more there’s no such thing as a standard screen size and a higher and higher percentage of viewers will have very large (1600px+ wide) or very small (400px or less wide) screens. At least try one of the extremes depending on what your target audience is likely to be. The truth is, I don’t build to be mobile-friendly, but I’m seeing that the time has come, perhaps past, when you can get away with this without taking a hit).

Do Javascript and Flash degrade gracefully?

So I love how this theme has AJAX this and that and sIFR headlines that looks so crisp since standard HTML+CSS doesn’t give you anti-aliased fonts. Awesome. But when I looked at it while running the Firefox NoScript plugin, which blocks Flash and Javascript, well, the headlines were completely messed up and the navigation didn’t work and I can’t make comments or anything. Do people really surf without Flash and Jacascript? Is this something I should worry about?

(You used to have to count on losing 10% of your audience if your site required Javascript. Now so many popular sites are enhanced by Javascript, that the numbers of those opting out are dropping some, but there will always be some security conscious visitors who will opt out. Best practice is to opt for a progressive enhancement model, where the site works without Javascript, but it adds a lot of useful features if available.).

Is there a separate CSS file or section of a file for MY styles?

The theme has a hodge-podge of CSS files and I can’t figure out where I need to go to change anything. Is that a problem?

(Maybe or maybe not, depending on your skill and your needs. Some themes are made to be customized and some are not. I like themes that by default include an extra CSS file. Yep, that’s one more file to download, but you might be able to get around that once you go live (Drupal allows you to combine all the files once the development phase is over and cache it as a single, albeit hugely bloated, CSS file) and modern browsers allow more concurrent connections so in the future you may be better off with more small files rather than one big one anyway, even without taking browser caching into account. Once you have it tweaked in your prototype, you can always put it into one small, light CSS file to bring bandwidth down.

The advantage of this system, is that you can make any changes you want to that last file, the one with just your CSS rules, and override the distribution files. Then if the developers find that the theme itself has cross-browser or even security problems, you can move up to the next version of the theme without losing your changes. Also, new versions of the CMS may require new versions of the theme and by compartmentalizing your changes, the upgrade process will be simpler. Even if you do combine files in the end, you’ll have that file with the core changes you made to get your original look, so you can fall back on that if you upgrade.)

Validation

I just ran my site through the W3C HTML validator and got 132 errors. Is that a problem?

(Maybe. It can be hard to find a CMS and theme that actually passes HTML and CSS validation. There are a lot of reasons for this, but one is that modules often generate code and there is generally not a system for a module to find out what the theme DOCTYPE is. So if the theme is XHTML and the module expects HTML and throws out an tag without closing it ( or ) then it won’t validate. Also, since it’s hard to force users to input valid HTML, most CMSes stipulate a transitional DOCTYPE, not strict. Finally, a single affiliate banner from Commission Junction can trigger tons of errors and that’s the fault of nobody but the affiliate network.

I won’t get into the strict/transitional, html/xhtml debate here, but it is reasonable to expect that a theme, running stripped down with only core modules/plugins and validated content, should conform to whatever DOCTYPE the theme author specifies. Ideally, it should validate to the strict version of that DOCTYPE under that situation, though I might want to actually run it as transitional because of the issues with user-generated content. That said, those who tell you validation matters for ranking in Google are blowing smoke. The vast majority of websites don’t validate and so Google does not take validation into account per se, but only secondary effects, like truly broken code that it can’t parse out in order to figure out what the point of your page is and where the links go. It has to be really broken for that.)

Whoa! My Head’s Spinning. Can’t I Hire Someone?

Okay, confession time. I was possessed by an evil demon who channeled through my fingers and I have pretty much no clue what half of that stuff I typed up there means. What I really need is for someone who can just make those changes for me if they’re necessary.

I think I’m only going to use themes designed by freelance designers who are actually out there for hire and looking for work, because as it turns out, most of the hobbyists who design themes are too damn busy with the rest of their lives to even answer my emails and wouldn’t consider working for hire because they care more about spending time with their kids than the $150 I’m willing to give them.

Looking forward to you advice. PS My boss needs our site up and running tomorrow.

I spent a long time on the fence about buying John VanDyk’s Pro Drupal Development because there’s so much documentation online and because I’m a cheap bastard. By about the middle of chapter 2, I realized what a stupid decision that was. I could have saved myself sooooo much time if I had just bought the damn thing when it first came out!

There are, I would say, two good reasons not to buy Pro Drupal Development:

1. You are not a Drupal developer.
2. You are such a Drupal ninja already that VanDyk mentions you in the acknowledgements.

If on the otherhand, you build Drupal sites and do any mucking about in the internals, this book will probably teach you a lot and, if it doesn’t do that, it is still probably a worthwhile reference. In my case, I learned a lot. It was a bit humbling actually, but damn useful.

I’ve tried to read through the forms API and the documentation for it, but it never quite came together for me and I found reading it online wearisome to be honest, in a way that I never felt when I was learning PHP and spending a lot of time with the online PHP manual. I suspect that’s because PHP ultimately has a lot of overlap with C++ and other programming languages, so I was mostly skimming for syntax, but Drupal is a complex system with an architecture that was utterly foreign to me with its massive collection of hooks, callbacks, templates and so forth. So how does hook_nodeapi() relate to theme_preprocess_node() and node.tpl.php? And that’s an easy one. Throw in the menu and forms APIs, filters and so on and it just gets hard to get started on really putting it together.

I’ve hacked together some modules and done quite a bit of themeing, but I never really took the time to really understand the underlying Drupal architecture. By the time I was a few chapters into Pro Drupal Development, I was already seeing better ways to do some things than my old bad “make it work” habits had taught me. Furthermore, with the excellent index in the book, when I came across roadblocks I could often find a solution quickly that allowed me to move on without having to sift through the documentation online.

Most importantly though, in almost every case, VanDyk’s explanations are just so much better than I’ve found elsewhere. I have no idea how talented a coder he is, but he definitely has real skill as a writer and a teacher. So many things that seemed arcane to me from other documentation, we’re absolutely clear and obvious in his able hands. I suspect some of that is because of good editing (not to be underestimated: it’s rare for a film to win the Best Picture Oscar without also winning the Oscar for Best Editing), and I find it much more comfortable to read print rather than onscreen, especially conceptually intricate material. None of that, however, takes away from VanDyk’s skill and my gratitude that he and others involved in the book put the time in to open up Drupal development to the rest of us.

If I have one regret about the book, it’s this: it covers only the core system. I understand the rationale behind that. With thousands, of Drupal modules, you simply can’t go down that road. Still, I think that the Content Construction Kit and Views have really become “pseudo-core” in that complex Drupal sites commonly use them and they are increasingly being folded into Drupal core. These modules are in and of themselves pretty complex, especially Views, and I would love to see a book that covers Views in the detail that VanDyk covers the core (and perhaps one of the other Drupal books does, I just don’t know about it yet). That said, having gotten a much better understanding of core gave me pretty much all the tools I needed to embed Views into my site in the way I wanted, and yet still have everything get themed and hooked properly and without using the Panels module, another complex module which, while powerful and useful, adds a lot of overhead for the simple task I needed (I actually originally built my “proof of concept” site using Panels, but realized after reading Pro Drupal Development that I could simply achieve what I wanted by making small changes in templates and template.php without weighing the site down with yet another massive module).

So in short: Thanks John! Now with take the massive riches flowing to you from all six of my readers, one of whom might actually buy your book, go write another one.

I’ve been wondering which image toolkit is likely to result in lower resource usage (especially coming up against the PHP memory limit) for applications like Gallery and Drupal. People used to always say the resize quality was better with ImageMagick versus GD, but I think GD2 closed much of that gap. But what about resources? The best answer I could find was in a thread on metafilter.com where one respondent says

if possible, do yourself a favor and switch to ImageMagick as soon as possible. GD2 runs within the php child, so resizing any image over 640×480 will pretty much take down the process you’re using. On our server, we’d have children allocated 64megs of memory die trying to resize a 1280×1024 image.

While I’m not an expert on server tuning or linux, my understanding is that in your typical usage scenario, you’d run IM as a niced shell process, meaning that 1) the php child won’t crash because it just launches the exec and continues, and 2) the process shouldn’t significantly slow down your server, because it’ll only use ‘free’ resources. This CAN mean that your user may experience a delay between uploading a file and being able to see a thumbnail…

That’s the best I can find for now. I should test it, of course, but for now I’ll take that advice and default to IM until I run into trouble.