Well, it’s been a while my Drupal friends, almost 18 months… dusting off this old Drupal 6 blog and time to start posting again.

And what better way to get started again than by talking about Drupal 7, by far the best release of Drupal. And with almost 7 years being involved with the Drupal project, I’m speaking from experience :)

The biggest issue with Drupal is understanding all the wonderful complexity going on under the hood.

Automatically tagging content is becoming easier with services like OpenCalais and Yahoo Terms Extractor, offering their APIs for free semantic analysis of content. There’s even a great Drupal module, Auto Tagging (with a great writeup on usage) that ties these services together and makes it even easier.

However, there is still one common issue with these services: they really need nicely written, rich, keyword dense articles to produce the most logical, semantic tags.

Try any of those services with user generated content and you’ll see a common tag each time around: FAIL.

We experimented with over 20,000 pieces of content on MothersClick and our results showed that these semantic services weren’t producing quality & relevant tags: rather, we were getting very little, if any relevant tags for our user generated content.

After a little more trial and error, I then noticed a simple pattern: more often than not, the title to a user’s post usually had the most applicable keywords to what their post was about, rather than the body of the post.

So how to extract just the keywords and make tags from the title of a node?

I’m working on a new project that has a Drupal site running in the cloud—specifically Amazon AWS with RightScale sitting on top to manage our servers and automated scaling scripts.

The advantage of RightScale is it allows us to manage our servers at a further abstracted layer than AWS itself — through the use of “RightScripts” we can script our way through the managing of low level resources.

Things started to get a bit hairy when our scripts needed to talk to Drupal, in particular, registering each new server as it comes online with our Drupal stack, thereby whitelisting its IP address as trustworthy.

When the new myLifetime community launched we wanted to focus on performance, and one trick was to minimize HTTP requests by using the CSS sprites technique. For a great run down of this technique and examples of other major sites using this, check out this resource on Smashing Magazine.

Double checking this implementation with YSlow! everything was working great.

Well almost. Then we tried IE6. I hate IE6.

Then I discovered this excellent post detailing IE6 and its BackgroundImageCache usage.

After trying that JS trick, we noticed the page was significantly faster & smoother in IE6. With heavy CSS sprite usage this was a necessary fix. And with future sites in the works with this same technique, seems like a reoccurring fix.

To Drupal-ize & jQuery-ize this fix for resuability, I wrote this simple behavior below that works with Drupal 6. You can see in action on the myLifetime community.

May this code save you a few hours/days of head banging!

Recently, the new myLifetime Community launched and it has been an overwhelming success. With members joining at such a fast rate, it’ll soon be surging past 100,000 registered members.

This site is separate from the main myLifetime site (which also is Drupal) and was built to be powered by the MothersClick community platform which Lifetime acquired last year. This new community website was built upon the new version of our community platform, which now has Drupal 6 at it’s core.

While we’ve been quietly working on this new platform, we’ve been brewing up and improving some great APIs in the Drupal community, all of which we consider to be necessities for building rich, online communities with Drupal. Without further ado, here’s a top sampling of where our efforts have been focused:

Almost exactly 1 year ago I redesigned this blog and today, I unveil yet another new design. This time, it’s running Drupal 6 and all that goodness. I’ve enhanced the contrast on the design quite a bit and really improved the readability on posts and comments, along with using the GeSHi code filter for much better display of code snippets. This theme was built on top of the Drupal Blueprint theme, which I maintain, and also made theming this site quick and simple.

UPDATE: Earl comments below how this is already built in. Two different ways to achieve a similar result, each with their own pros/cons.

Hats off to Earl Miles and the rest the views developers they have done a tremendous job with Views 2. While the interface is entirely different from that of Views 1, it is so much more intuitive that within a few minutes I had quickly forgotten my bewildered “oh no, I know nothing” look :)

From reading all of the docs and quietly watching development commits, I knew Views 2 was going to eliminate a lot of the Views 1 helper modules and open up a whole new world of awesomeness. While I haven’t seen many blog posts detailing just which functionality/modules have been replaced with Views 2, I wanted to kickstart things with my own discovery as I played around with Views 2 quite thoroughly this afternoon.

With Views 1, to build an alpha pager you would use the views alpha pager module in conjunction with your view. But what about Views 2?

Getting Drupal to play nice with your CDN can be a bit of a hassle. You have to make sure your assets (like JS, CSS, and image files) work not only on your webserver but when copied to the CDN, are served from there instead of your webserver. There is one Drupal module, the CDN module that attempts to make this a bit easier but right now, it’s not in production, and in my opinion, is a bit too complicated. There is a slightly easier way :)

My brother wrote an excellent article on how to connect Drupal and Silverlight. This is pretty indepth and shows what needs to be done on the Silverlight side to work with a simple XML-RPC Drupal module. Definitely worth checking out, great job bro!

The .htaccess file included with Drupal tells Apache to send all 404 requests to Drupal to handle. While this is great in some cases, the performance degradation can have a huge impact on a site that has millions of users.

When Drupal processes a 404, it has to bootstrap Drupal, which includes Apache loading up the PHP process, gathering all of the Drupal PHP files, connecting to the database, and running some queries. This is quite expensive when Apache can be told to simply say “Page not found” without having to incur any of that overhead.

Now you might say your site doesn’t have any broken URLs as you haven’t changed any. Well that’s great, but as your site grows, it is going to be a target for spammers and hackers. They are going to start requesting all sorts of file to see if they can find an exploit. Instead of bootstrapping Drupal each time to tell them that DLL file doesn’t exist, it would be much better if Apache could just say that, to save resources for your real users.

So, what can you do? How can you stop Drupal from handling 404s but not break modules like imagecache?