Drupal

If you read my previous post about converting Subversion repositories to git, you’ll know that to do a proper Subversion-to-Git transformation on a batch of repositories is going to take some time (what with all that command line typing). I had 142 legacy project Subversion repositories lying around I wanted converted to Git and, since I’m lazy, I pulled on my bash boots and wrote me a script to do the work!

With the git-svn-migrate scripts I wrote, you can batch convert all of your Subversion repositories in just 3 steps. And I’ve GPLed them and put them on GitHub if you’d like to collaborate and improve them; see the git-svn-migrate project page.

git-svn-migrate: a reverse glue factory

When I first realized that I needed a version control system, the best system at the time was CVS. (No, really.) Subversion was nearing 1.0, so I waited for its release and then used it everywhere. Well, that was 2003. Time for a change.

This past year, it became obvious that there were many Git users within the Drupal community, so Drupal has decided to move to Git. Since then I've started learning and researching the best ways to convert all my development to a Git-based workflow. So far… it rocks.

So this post is going to be a big “duh” for anyone who has written a book covering an open source project, but it was a bit of a surprise for me…

As anyone who’s taken a look at the Zen project knows, I’ve written a lot of documentation for free. And I’m a big fan of (and a member of) Drupal’s documentation team. They rock! \m/

And every time a new Drupal book comes out, there’s a considerable amount of congratulations to the authors and little bit of grumbling about it being a missed opportunity to improve drupal’s free docs.

I was recently asked to co-author an upcoming book on Drupal 7 module development, writing the chapters on the theme system. Now, for the past year I have been wanting to write a ton of tutorial-based theme system documentation (something we are sorely lacking), but I never had time (too many D7 core patches!) So I began to wonder if I would be “cashing in” by writing a book instead of the free docs I had intended to write.

Back in the day, all the CSS of the sites I built were in a single file: style.css. Things were easy. I built the site; I organized my styles; I knew where everything was.

Of course, then I discovered the power of leveraging an open-source community. And now there are innumerable developers writing the CSS for my websites. To keep things manageable, each module of functionality has its own stylesheet.

Unfortunately, once you get in the habit of having multiple stylesheets for your website, you will eventually run into a weird problem with Internet Explorer: some of your styles won’t apply. At all.

And if you have sufficient Google-fu, you’ll eventually discover this is a little known bug: Internet Explorer will only load the first 31 stylesheets and will ignore the rest. And this isn’t even limited to our usual suspect, IE6. All versions of IE have this limitation.

The Full Problem
and why I was insane enough to load 993 stylesheets on one page

The two biggest things that have bothered me as maintainer of the Zen theme is:

1. People complaining about Zen being bloated
2. People actually using the Zen Classic sub-theme

With the latest release of Zen of I've tried to address both points. Zen 6.x-1.1 is now out and with it Zen has slimmed down… by jettisoning the Zen Classic sub-theme. :-)

Please rate and vote for my “I’m coming to DrupalCon Paris video avalanche” response. A free Drupalcon Paris ticket means more beer money. Daddy needs beer! So give me some lovin’, Drupal community!

Did I mention I rap about Drupal in the video? So go watch the “John Albin Wilkins” one and vote for me! :-D (See the detailed voting instructions below.)

Also, I’m behind in the polls right now! Help!

Ok, I mentioned this in twitter a few weeks ago, I created an issue about it in D7’s issue queue, and there are 2 small print notes in the D6 theme guide, but I don’t think my message was visible enough. So let me just say for the record (again)…

Never, never, ever, ever use phptemplate_ as the prefix for your theme’s preprocess functions. Don’t do it! phptemplate_ prefix should talk to the hand! Expunge it from your memory. It’s an ex-prefix. Seriously, cut it out! So, let me re-phrase:

Every time you use phptemplate_ prefix,
God adds a pointless issue to Drupal’s issue queue.
Please, think of the issue queue!

A few days ago, Jeff Burns wrote “Source Order: why I think Zen gets this wrong”.

His basic premise is that content-first HTML source ordering is an SEO-driven idea, is not backed by any accessibility studies, and goes against user expectations. While I respect his opinions, um… he’s wrong. :-)

Over at Brainnovate, Scott Miller writes that a CMS is bad for innovation. Now his opinion is clearly biased and ignorant of how innovation actually occurs, but there are some points I would like to clear up…

“Just because I haven’t personally used it, I do know a thing or two about Drupal. It *is* a powerful piece of software.”

The swing…

“However, at the end of the day it is still a CMS, not a framework […] in its own right.”

…and a miss! Actually Drupal is much more powerful than Scott knows. Because it’s both a CMS and a framework with an extensive API.

Here’s a quick one if you are in need of a noon-time distraction. If you’ve ever used the WYSIWYG editor TinyMCE, called “tiny mice” by some, then you know that it likes to hook() up with every <textarea> that it sees.

The results of this promiscuity range from annoying (I don’t need a HTML editor for a log message!) to the disastrous (?*$! That HTML editor just stripped the newlines from my list of pages in “Page specific visibility settings!” Oh, the humanity!)