New Localization API guide, much better code reviews

This story started almost a year ago, when I published my cheat sheet for the Drupal 6 localization API. Although Drupal 6 was not ready at that time, the localization API was as stable that the cheat sheet is useful without modification even today.

My intention with the cheat sheet was to start a localization API guide on and get the intricate details of this API documented for the general good. Over the past few weeks, i've managed to have time to actually sit down and document best practices and tips for these functions, and published the Localization API guide as part of the developer handbook (it is worth to check out the printer friendly version for a quick glance). While some parts of the guide are still under discussion and finalization (and I still plan two pages: one on emails and the other one on pointers for people looking to translate user provided data), the guide is pretty much complete as far as localizing the interface goes.

Another side of that old blog post of mine was new Translation template extractor support for the coder module. Well, that was basically tapping the existing errors into coder and make you figure out the rest. The existing error messages in extractor were however quite cryptic, like Invalid marker: t($joe). This is not really helpful in finding out what is the issue at hand, when you are not familiar with the finer details. This was unhelpful for both module authors and code reviewers, who were eager to fix these problems. I got several support requests in the extractor issue queue to clarify guidelines. So updating the error messages was clearly in order.

The result of these two efforts is that the latest development version of the extractor on the 6.x-2.x branch (update from CVS or wait for today's tarball to materialize) now supports nicely understandable error messages for coder module (and way better error messages for its standalone mode just as well) with links to the actual documentation explaining the underlying causes and details. This will hopefully end up in a new release very soon.

So do you have any excuses left to not write nicely translatable Drupal module interfaces?

Updated my blog to Acquia Drupal

Well, although I was the first employee at Acquia, I somehow managed to keep myself out of actually using the product on my own blog up until now. While I know we have a great product, built up from superb community contributed Drupal modules tested to work together, distributed under the GPL, I did not find the time to actually migrate my personal blog to this distribution of Drupal.

One of the factors causing this was that I actually ran Drupal 5. Wow, another shocking revelation about the Drupal 6 maintainer! Especially considering that I only run the contributed modules Pathauto, Mollom and Tagadelic, and these were ready for Drupal 6 already. In fact, I've tried to upgrade to Drupal 6 already, and in preparation to that, I've got rid of some contrib modules, replacing Flickr syndicated images with Flickr's own image script display for example, thus avoiding using Drupal modules for that. This helped me prepare for an easier Drupal 6 upgrade a few months ago. Except I never got around to actually doing it.

Being a maintainer of this simple blog, as a user of the above mentioned three contributed modules, the Drupal 6 based Acquia Drupal upgrade was the most logical step at this point. I've made a backup of my source code and uploaded files, as well as the database. Did a test upgrade on my local machine and it went great right from Drupal 5 to Acquia Drupal, even picking up the moved contributed modules. It was a piece of cake.

On the test upgrade, I've even played around with using the built-in Acquia Marina theme, and found it great, so switched to that from the Alek 2.0 theme. Because these three modules are included with Acquia Drupal, I could just use it for my blog from now. Additionally to keeping what was in already, the Drupal 6 upgrade allowed me to track updates to my modules, add support for OpenID, and so on.

If you are still considering upgrading to Drupal 6, Views 2 being out and Acquia Drupal soon upgrading to this stable release, it is a great time to switch. Drupal 6 is well tested in the field, as Dries shared it on the last Lullabot podcast, five hundred active sites are deployed daily based on Drupal 6. My site is just one of them for today.

"Drupal, make waves"; also, MySite running into the spotlight fast

From time to the time, the topic of forming a new slogan for Drupal is coming up again and again. Admittedly "Community plumbing" might be a bit worn out. One could only wonder if a new slogan is part of the redesign underway now or not. upgraded from Drupal 4.6 to 6.4(!)

As with lots of hobby projects, things could just drag on without much progress, if you don't sit down and just do it. It was the same situation with, the site which got me to use and heavily contribute to Drupal (4.3 originally). Unfortunately I only had the time to keep updating the site up to Drupal 4.6 and the long cycle around Drupal 4.7 and my heavy involvement with other things (such as finishing off studying for my MsC degree) dragged me away from taking care of the site.

Updating from Drupal 4.6 to 6.4Almost two years ago, I have started to work on an upgrade of the site to Drupal 5. That was "of course" never complete, so early this year, I've started to push for updating it to Drupal 6 finally, and got momentum among the other editors/managers of the site, so we worked hard in the little spare time we had to get it to launch. Our efforts reached the actual live upgrade this past weekend.

This site helped me fix up and enhance commentrss module and Localization client over the past two years, directly benefiting the community. As far as our custom modules go, it was a bit frightening effort to port our custom Drupal 4.6 modules to Drupal 5, however it was a piece of cake to port Drupal 5 modules to Drupal 6 with coder module.

Because our first priority was to relaunch on Drupal 6 instead of 4.6, we dropped some of the less used features, avoided toying too much on the design, and concentrated on retaining data and getting the site run on a modern backend system finally.

One interesting thing I developed way back in 2007 however was the direct update mechanism. Drupal 6 lacks some of the old update functions, so I needed to copy them back, and there were two places where I needed to patch the old update functions (avoid menu_rebuild() too early before the new menu system is in place and avoid calling node types from the database before they are in there), but otherwise it was a great experience to just copy the old Drupal 4.6 database, hit update.php and the whole update process just run.

The update process running

Due to the timing of our update efforts (and our diligence to update to the latest and greatest Drupal versions, given that we might not have time to do so for some time again), we were in the unfortunate position to never be able to use CCK and Views, due to no stable releases available of these fine modules. So if you expect a nice use case of porting 4.6 custom stuff to CCK and Views, I need to disappoint you. What we did, is that we ported custom node types to the build it node type system, we ported our custom file upload code to the since then built in upload system and a custom filter for Drupal 6, so that our attachments included in posts will still work. We kept custom code to list stuff in our jobs section or in our books area though. In cases when modules were available however, it was just so nice to be able to get new features developed through the past years by others. Oh, the wonders of building on an open source framework!

Drupal 4.4 style tracker on Drupal 6.4One interesting tidbit is that we keep using the tracker style which was available way back up to March 2004. This old style tracker lists comments to a post, compared to just listing their numbers in a boring table. This also allows displaying individual read information for users, as shown on the picture. To my best knowledge, this was removed due to performance reasons. Querying all related comments for all displayed nodes takes some power for sure. What we did to remedy part of the issue is to hide most read comments on long threads for logged in users, so they get a more compact view and the site eats less power.

In place editing on Weblabor.huWe almost kept our self-promise to not add new features. One small new feature we've added however is of great help to site admins. Inspired by Flickr's in place title and description editing and by the doubleclick Drupal module, we've developed in-place editing for node titles, so we can touch up quickly on mistakes and typos. This feature consists of a little bit of code on the theme to mark up editable titles, JavaScript to replace titles with an input field, some AJAX to send it over to the server and a very small module to save the node title coming in (if the user has permission to change node titles). It would be a piece of cake to contribute to the dblclick module but the only problem with it is that it is heavily theme dependent. How you put the input field into the page depends highly on the markup used to display node titles, and that could vary quite a bit on different sites. I'll try to find the time to write up an article about it though.

I am happy to see almost two years of little bits of spare time work pay off, and I am hopeful our efforts will help put on a growth path again.

Ps. The logo in the site header is one we actually created in real life (although it did not become as good as we hoped it will be).

Our home is being redesigned, are you participating? (and its whole site family) is being redesigned, thanks to heroic efforts by the Drupal Association. The site family grew quite big (and is still growing) so there is a lot of stuff to do. You probably have your own gripes on how it should work, so now is the time to get involved! Just as you'd expect from good architects when redesigning your home, Leisa and Mark are running a series of blog posts (just watch Drupal Planet to see them) to discuss details of the redesign, and understand our needs. Anyone can put in their opinions, and it is their job to filter it down and produce useful results in a relatively short time.

I started contributing with a one-on-one interview with Leisa at Drupalcon Szeged 2008. This event was a good opportunity to interview lots of different type of people on how they use the site, what are their problems and happy moments with it. If you have not been to Szeged, or have not been able to get an interview, there is no reason to step back. You can also contribute with comments on various blog posts (just as I do), taking part in the online card sort and submitting your own wireframe suggestions.

I've just decided today to sit down and make sure my opinion gets into the pipe, so I submitted this simplistic wireframe (click on it and get to Flickr to see the notes): homepage redesign idea

My goal with the suggestions is to get rid of the blog-look for the home page and get prime-time for more important stuff by highlighting them by topic area. We don't need such a long explanation on what Drupal is, if people can instantly see, that Drupal events are happening near them, they can buy books to hold in their hands, people build cool sites with Drupal and they can earn money with Drupal as well, within a thriving community, which takes software and security seriously. If you break this sentence down, several boxes come up for the homepage to highlight security bulletins, showcases, the Drupal Planet, events, and so on. These all describe Drupal's several aspects themselves, leaving the intro itself to a short explanation. I believe this kind of hub homepage would finally get us to a state where we can tell people to just go to the homepage and get a decent overview of Drupal.

Do you think you can do better then me or have other ideas to get highlighted in the redesign process? Why not participate? Come wireframe with Leisa.