On January 15, 2007 (Drupal’s 6th Birthday), Drupal 5.0 was released. Neil Drumm acted as the Branch Maintainer for the past four years up until one final commit on January 6, 2011 to clarify the PHP compatibility.

When Drupal 7 was released that meant that Drupal 5 was no longer supported. This announcement is merely a reminder of that fact. It is the policy (and, to large extent a matter of pragmatics) of the Drupal community to support only the current major release of Drupal (currently Drupal 7.x), and the previous release (currently Drupal 6.x). See Drupal’s version info for more details on this policy.

Drupal 5 is no longer officially supported

What does it mean that Drupal 5 is no longer officially supported?

1. You should not expect any of these issues to be fixed in Drupal core.
2. The Drupal Security team will no longer solicit nor work to address issues that are reported in the 5.x branch of Drupal core or contributed projects.
3. The Update Status module, introduced with Drupal 5, relies on XML from drupal.org. That XML is still used for newer versions of the module but may be changed in ways that break the Drupal 5 version of the Update Status module.

What does this mean for you?

• If you are responsible for sites that are running Drupal 5.x, it’s time to upgrade to 6.x or 7.x. See instructions on how to upgrade and a video on Drupal 5 to Drupal 6 upgrade. Note that 7.x is still relatively young so you may not be able to make that transition just yet.
• Module, theme and project maintainers are encouraged to mark their 5.x versions as unsupported so it is clear to end users that these are no longer supported. You can do that by going to your project, clicking the Edit tab, clicking the Releases sub-tab, and unchecking the boxes for “Supported” in the rows for 5.x releases (screenshots below).

You may be thinking “Hey, let’s keep Drupal number 5 alive!” You are not alone in this thought process. There is a Drupal Long Term Support group devoted to the concept but it has met with limited success so far.

Thanks, Neil!

Much like we thanked Gerhard in the Drupal 4.7 End Of Life, we’d like to wish Neil Drumm a warm thank you for all his efforts with Drupal 5.

Note: If you never used an “@drupal.org” login to a site then you can gleefully ignore this post. It was a feature launched long ago and not widely used.

Hey Everybody,

It’s been a long time coming, but we are now approaching the point where the old “distributed authentication” mechanism will be turned off on drupal.org.

For a while, the distributed authentication method was a great idea. Sites like spreadfirefox.com used the distributed authentication and it helped spread awareness of Drupal. It was an early idea for identity and federated websites and distributed social and all those fancy buzzwords.

But while the concept might have been visionary the implementation was not. It is not a super secure architecture, as perhaps the biggest complaint.

So, we will turn it off on drupal.org on November 1st, 2010.

Goodbye legacy, hello new hotness

If your site allows logins like “username@drupal.org” then you should know that it will be turned off soon. Users will still be able to login with that account and the password they last used. But there could be some scenarios where they get locked out. Even worse, if they never updated their account then their mail will not be stored in your database so they cannot use the “self-service” password retrieval system.

If you want to use something similar, consider using OpenID module that’s in Drupal core these days. It allows federated logins without all the architectural security problems.

If you relied on this service

Site owners who relied on this service should…

1. Get people to enter their e-mail on their profiles
2. Alert people that the connection to drupal.org is going away and their passwords will no longer stay in synch.

Yay progress!

WikiWeightWatcher.com is a weight loss community website that allows users to view, add, and change Weight Watchers points and nutrition facts for restaurants and food items. It was initially launched in the fall of 2008, has grown to over 7,000 registered users, and currently receives over 3,000 unique visitors a day.

PropDrop is a company specializing in web development and marketing, focusing on niche websites and small businesses and organizations, doing anything from church websites to veterinarian websites. They did both the initial development, the new custom theme, and the implementation of the new features.

The Old

The original site was developed to see what the demand was for such a site like this. Drupal 5 was chosen because of the speed of development and the availability of the modules.

The “wiki” type functionality, while not 100% true “wiki”, suited our purpose and was simple to implement. Any logged in user could add Restaurant type nodes and Menu Item type nodes. Menu Item nodes had the nutrition information, such as calories and fat grams, and a CCK node reference pointing back to a restaurant. Revisions were also turned on for these content types, so rollbacks could be performed if needed.

To make it as easy as possible, an “Add Menu Item” button was located on each restaurant node, which had the restaurant node id as an additional argument in the link. Using a small amount of custom module code, we hid the CCK node reference on the node creation form, while populating it with the node ID from the argument. Easy and limits potential confusion.

To display the menu items for the restaurant, an embedded view was placed in the node-restaurant.tpl.php file.

Similar functionality was completed for food categories and foot items.

To prevent mass deletions or just plain wrong data, we also used the Modr8 and Revision Moderation modules. This allows administrators to approve changes or additions either in bulk, or individually.

For the theme, we used a slightly modified version of LiteJazz.

And as the traffic ramped up, we saw our time to load pages increased to where it began to negatively affect our Google rankings. So we installed Boost and it immediately solved the problem.

This all worked great and it would have continued to work great. But, it was time to mature. After we got our 7,000th user, we decided to sit down and figure out how to bring the site out of infancy and develop a plan to make it more successful.

First on the agenda: moving from Drupal 5 to Drupal 6. With the inevitable release of Drupal 7 on the horizon, it was simply time to stop putting it off. It’s not that Drupal 5 stumbled or didn’t meet our needs. It met our current needs perfectly. But our needs were not going to remain stagnant. So we upgraded for two main reasons:

1. PropDrop has worked exclusively in Drupal 6 for over a year, and our Drupal 5 skillset (theming, module development, etc) was getting a bit rusty. For both maintenance and additional feature development, upgrading made the most sense. We also gained access to the more advanced Drupal 6 versions of certain modules, like Views 2.

2. Drupal 5 will stop being supported with security and bug fix releases after the release of Drupal 7, which, as far as we know, is probably being released this year. We didn’t want to be caught with our pants down.

The Upgrade

This was the first Drupal core version upgrade attempted by PropDrop, and it went more smoothly than we could have hoped. We did it over a single Saturday, which is one of the days with lower traffic.

First we took a snapshot of the database and the file structure, and copied that to a different server. This way, no matter what happened, we always had the live site still running. No worries.

Then, on this new instance, we followed the instructions as listed at http://drupal.org/node/340073

No major hiccups occurred, and after this, we copied the database and file structure back over (after taking another backup of the live site file structure) and we were suddenly running Drupal 6 and ready to grow.

All in all, it took about 10 hours combined work.

The New

Next on the list, after the upgrade, was creating a new brand and custom theme. Litejazz had served us well, but we needed to move on.

We went with a less formal logo, yet a bolder color scheme. On the old site, the most visited pages were the Browse Restaurants and Browse Food Items pages, for obvious reasons, and links to these pages were kept in the left sidebar. For the new theme, we wanted to give them the prominence they deserved, so they are now part of the primary navigation. Not only that, but they are on the far left and a different color than the rest of the primary links.

A new front page layout was devised to look more organized and less cluttered, yet have more information, including room to feature some of the unique articles we would be adding.

We also wanted to move the sidebar to the right. Having main content on the left offered a better user experience.

User Accounts: Making them Useful

Since the very beginning, we’ve had about 6 to 9 new people sign up for user accounts every single day. This was one indication that the idea had some legs to it. There wasn’t even a reason for these people to sign up, other than the forums (powered by Advanced Forum), which, initially, no one really took advantage of anyway. And only about 3% of these users actually edit or add information. It’s still a mystery to us why people kept signing up for no apparent reason, but we’ll take the growth whether we understand it or not.

Regardless, in this iteration of the site, we actually wanted to make these user accounts useful. So we added three things.

First was the Clip to Favorites functionality. Utilizing the Flag module, it was simple to allow users to mark their favorite restaurants and menu items, and have them show up in their profile. If there are a few restaurants they always find themselves looking up, this will help eliminate a few mouse clicks.

Second was the Friends functionality using the User Relationships module. Using this, we will eventually integrate the Heartbeat module show people can know what their friends are commenting on and when a friend marks a restaurant as their favorite.

And third, we added Imagecache and Imagecache Profiles. Yes, on the old site, we didn’t even allow people to have avatars. How lame is that? It has now been remedied. In addition we have a Featured Members section that helps highlight that we are indeed a community site.

iPhone and Services

Upgrading to Drupal 6 allowed us to use the latest Services module. We wanted an iPhone application, but didn’t really want it to draw from a local database. The appeal of the site is that it should have the latest information based on what users are adding and editing, and so we wanted the iPhone app to pull directly from the live Drupal database.

This was the first time we had ever used the Services module, and our first ever iPhone application. It was quite an adventure of head scratches and blank looks at LCD monitors, intermingled with some frustrated sobbing. But we prevailed. The app is now approved! http://itunes.apple.com/us/app/wikiweight/id389590293?mt=8

But how did we go about this? No one knew Objective-C (the language for programming Apple applications), and frankly, no one really wanted to learn it. Thankfully, people much smarter than us had already come up with solutions to this common predicament.

The first is called Phonegap, which wraps HTML, CSS, and Javascript into an XCode project, effectively making it a native iPhone application. This meant that we could use tools we were already familiar with to develop for the iPhone platform. In addition, Phonegap also includes wrappers for Android and Blackberry applications, so the same code can be used for multiple smart phone platforms.

The second tool we used is called JQTouch. It’s great to be able to use Phonegap so we can use HTML, CSS, and Javascript, but that doesn’t really do a lot of good unless you can have the look and feel of a native application. JQTouch, a JQuery plugin, provides this admirably using webkit animations and a nice default theme (which our application uses).

Thanks to the above tools, we were able to interface with the Drupal Services module with JQuery AJAX calls. To do this, we used the JSON server, modified to accept JSONP(http://drupal.org/node/598358). This was a bit tricky to smooth out all of the kinks and syntax requirements, and required a lot of trial and error, and looking at the Javascript console in Firebug. In particular, figuring out the double quotes that needed to be there, but also escaped in certain places. The typical ajax call we ended up with looks like the following:

He may not be known to everyone yet. Henrik Danielsson (TwoD) suddenly appeared out of nowhere approximately 18 months ago and started to post a couple of pretty solid patches to Wysiwyg module’s queue. In case you do not know the Wysiwyg module yet: It allows you to integrate any kind of client-side content editor (WYSIWYG) with Drupal by building a communication layer between Drupal forms and the actual editor(s). Thus, working on the project requires a solid knowledge and highly advanced expertise of Drupal’s Form API, Filter API, JavaScript, and lastly every individual editor library.

Like many other contributors that do something for projects I care for, TwoD had to go (♥) through my motivation-killing bastard patch reviews, me nitpicking on adherence to Drupal’s coding standards, documentation standards, and other badass change requests. Requiring him to re-roll the most simple patches a couple of times until they matched my expectations. Although I already knew and still know that in most cases, contributors are running away screaming, I was and still am searching for eligible co-maintainers for all of the projects I maintain.

TwoD took on this challenge. In an astonishing brilliant and still pleasant way. Soon, his first patch was committed, without me having to touch a single line. After running with him through the very same badass procedure for one or two of his other patches, he understood how to get patches “beyond me”. Suddenly, he started to redo his other patches in the queue, without a single word from me. “Woah. How awesome is that?”, I thought, and within the next couple of minutes, Wysiwyg’s CHANGELOG.txt saw quite some heavy traction.

Shortly after, I contacted TwoD to ask whether he’d like to co-maintain the Wysiwyg project, so he’d be able to commit those patches on his own. And luckily, he agreed! (with praise)

Round about 12 months and 596 issues later, TwoD is the most active person in Wysiwyg’s queue, answering hundreds of support requests, (partially bogus) bug reports, and writing really kick-ass patches for all kind of browser quirks, misbehaviors, and JavaScript conflicts. What totally amazes me most is that even after having replied to and worked on all those issues, he still has the balls to write completely open and detailed analyses, most often with lots of evidence, for almost every issue in the queue.

In addition to that, his knowledge and wisdom giantly helped to scope and draft the future 3.x goals for Wysiwyg.

Frankly, TwoD is truly amazing. And an irreplaceable Drupal contributor.

Interestingly, my attempt to also turn him into a Drupal core contributor blatantly failed. Which might mean that I need to raise the bar for contributions to my projects a little higher even. But don’t worry, I’ll make sure to try that again with TwoD.

By the way, during the process of turning TwoD into a fully-fledged co-maintainer, the Best practices for co-maintaining projects handbook page was born: A “code of conduct” for Drupal project (co-)maintainers and contributors who want to become one.

Drupal 6.18 and 5.23, maintenance releases which fix security vulnerabilities are now available for download.

Drupal 6.19 also fixes other small issues reported through the bug tracking system.

Upgrading your existing Drupal 5 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement, more information on the 5.x releases can be found in the Drupal 5.0 release announcement. Drupal 5 will no longer be maintained when Drupal 7 is released. Upgrading to Drupal 6 is recommended.

read more

Drupal 6.16 and 5.22, maintenance releases which fix issues reported through the bug tracking system, as well as security vulnerabilities, are now available for download. Drupal 6.16 also fixes other smaller issues.

Upgrading your existing Drupal 5 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement, more information on the 5.x releases can be found in the Drupal 5.0 release announcement. Drupal 5 will no longer be maintained when Drupal 7 is released. Upgrading to Drupal 6 is recommended.

read more

The San Francisco DrupalCon organizing committee is happy to announce that session submissions are open!

Come see the sessions that have already been proposed, and if you can’t find exactly what you’re looking for, suggest your own. Drupal’s community is what sets it apart from the pack, so come be a part of the magic!

The session submission and voting schedule is:

• January 15, 2010 to February 15, 2010 – Session Submissions Open
• February 16, 2010 – March 1, 2010 – Public Voting on Sessions
• 
March 5, 2010 – Speakers Notified

• March 15, 2010 – Final Schedule Posted

read more

Drupal 6.15 and 5.21, maintenance releases which fix issues reported through the bug tracking system, as well as non critical security vulnerabilities, are now available for download. Both releases fix other smaller issues as well.

Upgrading your existing Drupal 5 and 6 sites is strongly recommended. There are no new features in these releases. For more information about the Drupal 6.x release series, consult the Drupal 6.0 release announcement, more information on the 5.x releases can be found in Drupal 5.0 release announcement.

read more