Just over a week ago, I've been in New Orleans to talk about multilingual Drupal website building at the Do It With Drupal event organized by Lullabot. I've been happy to join fellow Acquians for a short time at the office and then at the Do It With Drupal seminar to represent the company. It was a fun experience to hook up with so many other people looking into using Drupal for the first time or even selling Drupal services already. It was a good mix, and was a very different target audience compared to Drupalcons. This event was more focused on the path seekers and the beginners with high detail and cross-discipline talks over four days. I've enjoyed several sessions, including Robert's session on Solr.

Unfortunately (for my enjoyment of the conference), my session was at one of the last slots, but it had a good turnout nonetheless. I've been prepared well in advance with a completely rethought line of thought (compared to previous, more developer focused events), and a slideshow done from the ground up. So despite talking about this topic before elsewhere, I needed to have a totally fresh look at the topic and present all the latest developments to date.

Since I do not have the permissions to upload my session to the website of the event, and the slides I sent in by email were not uploaded yet, I figured I'd better share them here with those eager to look into them soon. Happy holiday's reading if you are about to take time to learn more about multilingual Drupal solutions!

In first of a series of posts, I'd like to go ahead and talk about project handling functionality, one of the most important tools behind Drupal.org. At this moment, Drupal.org is running Drupal 5, and a big chunk of modules which don't have a Drupal 6 version to migrate to on Drupal.org is the project module family: project (also includes project_release and project_usage), project_issue, pift_server, cvslog and even comment_upload.

Except the comment_upload module (which allows file uploads on comments in a general way), maintenance for these modules are headed by Derek Wright and Chad Phillips. An outstanding thing about these modules is that they keep improving and being adjusted to user needs. Automated testing integration tools were developed and keep improving, so patches submitted against Drupal 7 get automated testing. This is just plain great. However, all this huge amount of motion is going on in the Drupal 5 version of the module. And given that Drupal.org needs a stable environment, it takes considerable effort to maintain a stable Drupal 5 branch with all these feature improvements and changes coming in.

While these modules do not even have a Drupal 6 branch yet, Adam Light went ahead and worked on a Drupal 6 port for project module. He hosts this in his own private Subversion repository (see http://drupal.org/node/157694#comment-891587 and the rest of the comments there). Since he started off long ago from a then current version of the module and implemented Views integration (instead of the one-off SQL based pages in the Drupal 5 version), the Drupal 6 port has a largely refactored codebase and does not carry the improvements made to the Drupal 5 version since then.

The lead maintainers however are at this point more interested in working on a new stable release for Drupal 5, given that some bigger changes they are planning to make would be easier to manage on their own instead of as part of a bigger porting and migration work to a new Drupal version and to a Views based backend. This gets us to a message of "please help with a new stable Drupal 5 release of project module before Drupal 6 work can be considered". While these patches are relatively big, they are far from how big of a monster patch is the Drupal 6 upgrade. All-in-all the possibly awkward conclusion is that maintainers look for help with the Drupal 5 version before Drupal 6 work can be started.

For concrete action items, Adam Light summarizes it well:

Let me explain the situation a little here:

There are still some things that we'd like to get fixed in the Drupal 5.x branch of the project and project issue modules before we branch for Drupal 6. See http://groups.drupal.org/node/10865 and http://groups.drupal.org/node/16069. One big issue that affects all of project* land is #98278: project* namespace bugs in $node. The project* maintainers have agreed that it would be best to fix this problem *before* branching, because if we try to fix it during the port that will make testing the port even more difficult than it will be.

Creating a D6 branch itself will not really unblock things. Hunmonk or I could also do that ourselves. However, the ported code that is currently in my SVN repository contains a *lot* of changes, and all of us agree that those changes should not just blindly be checked into the project cvs repository without at least some review.

Yes, we all realize that this is a non-ideal situation, and that the port is moving much slower than anyone of us would like. The best way anyone could help move the port forward would be by helping to write or review patches for any issue not yet finished in the list of things to do before the next 5.x release. Mostly, that means reviewing the $node namespace patches in the issue I linked to above. The unfortunate part of this issue is that it is huge, but really boring. And none of the sites run by the project* maintainers use a combination of modules that actually causes this bug to reveal itself. But at the same time, we realize that lots of project* users *do* use such a combination of modules (eg. they use pathauto with project), and so we need to fix this bug soon.

So there are numerous big issues affecting Drupal.org which will be solved as part of the Drupal 6 port, but the main issue holding back the port from even starting is an issue which does not even affect drupal.org (and therefore is not going forward on any reasonable speed).

In summary, there are difficulties in how improvements on drupal.org are expected by some people right now instead of after an upgrade, and the maintainers are taking on work on these items; and issues not affecting drupal.org holding back our most important upgrade ever. So you can help at least three ways with the project module upgrade:

• Put away some of your cool feature ideas for project modules on drupal.org for now. Let's focus on porting and bugfixing or we are not going to get over new feature requests anytime soon.
• Help test patches against the Drupal 5 version of project modules to fix long standing bugs. See http://groups.drupal.org/node/10865 and http://groups.drupal.org/node/16069
• Help test and fix existing issues in the Drupal 6 port of project module. It at least has Views integration issues coming from the RC2 API changes in Views. See my pending patch at http://drupal.org/node/157694#comment-1069892 which still needs work.

We definitely need your help in many ways. Let's do good for the drupal.org upgrade / redesign!

Update: The final design iteration is online! Check it out! Added screenshot to the post.

About five weeks ago, I blogged about that the redesign process is coming to an end soon, and that it is our job to take over and actually implement what was designed.

The first steps to get to a better drupal.org is (1) to see what we have, (2) keep what we are going to use forward, (3) implement migration paths for whatever we drop and (4) start adding functionality afterwards. In my previous blog post I referenced my report titled Where we are with Drupal.org modules vs. Drupal 6? which covered some of (1), and provided some ideas for cleaning up for decisions in (2).

At the start of the redesign, ideas of single sign on for drupal.org subsites, splitting out project management to its own subsite or merging all subsites into one were tossed around. A single unified node id space among subsites was discussed but more concrete implementation details were not made up. So there are lots of bigger scale infrastructure questions, and we need dedicated people to deal with these, drive the directions, make up solutions.

To facilitate teamwork, I decided to bring findings in my report to a wiki page and encourage all of you to come and sign up for tasks. The Drupal.org to Drupal 6 upgrade collaboration page is a wiki page which lists major module sets on drupal.org and calls out some ideas / directions we might/should take in each area. There is place for people to sign up and for relevant issues to be posted to have an overview of all the items needed.

While the focus of the page is to update drupal.org modules to Drupal 6 (some of which lag behind considerably, especially project handling related modules), the upgrade itself poses some questions. Some of the functionality is not meaningful to update given new plans. Two examples:

• The drupal.module based distributed authentication model for Drupal.org is planned to be OpenID going forward, and we will drop the old drupal.module based authentication scheme. This needs action on drupal.org to set up an OpenID server and provide migration for those using their drupal.org names on sites such as groups.drupal.org for example.
• The xapian and search modules now hosting the search functionality are target of much criticism. Jacob Singh, Robert Douglass and Peter Wolanin have a better proposal for drupal.org based on ApacheSolr, which will offer faceted search as well: http://dc2009.drupalcon.org/session/more-search-how-apachesolr-changes-… So why would we update the xapian module then?

While there are some questions, there are clearly required modules, such as the project module family, without which drupal.org will not live as happy as it is planned to be. There are numerous smaller modules in the drupalorg.module, or items like comment_upload which need attention if you can help out.

As Kieran Lal writes, today is the day when we will see the last design interation from Mark Boulton Design, and from there we are left with designs we need to build actual working functionality behind. With the risk of repeating myself from my previous post, I'd say again, that there is nothing like building a website for more then 300,000 users and 720,000 unique visitors per month. You might not catch such a project soon, if you miss this one! So get on and work with us in this exciting redesign!

Just as I completed my MsC last year at the Budapest University of Technology and Economics (BME), I've been asked to go give context and advice on the possibility of using Drupal with people at the Central European University in Budapest. They were looking at content management systems such as Plone and Drupal and were trying to scope their work and the possibilities they have for converting to an Open Source system.

This past year, I've been happily presenting at FOSDEM (which "is probably the most developer-oriented Free and Opensource conference" and is taking place in Brussels, Belgium each year). I've had a great session on new things in Drupal 6 and it was even videotaped.

FOSDEM is again coming to Brussels in 2009, and the dates are Saturday 7 and Sunday 8 February 2009. The 2008 Drupal group is now renamed for 2009, so FOSDEM-interested parties can congregate in there for this next year as well. The event itself ran on a Drupal website, and keeps running for the upcoming year as well. It would be great to set up a Drupal developer room again there in 2009!

Today, Packt Publishing announced, that Drupal not only won the first prize in the PHP CMS category but also the first in the overall category in Packt's 2008 Open Source CMS Award! Yay!

More than a year ago, I've started to rehearse for Woof's role in Hair, a musical adaptation of the famous film we are putting on stage. At that time, it was expected that we would be ready by May 2008, but this did not materialize due to time limitations of our director and some helpers working with the team. So it was pushed back to November 2008, which is getting pretty close now. We've actually announced the dates now, being November 7, 8, 9, 11, 12, 13, 14 and 16 (update: extra nights on the 17th and 18th). Final rehearsals are now in full force, lights, smokes and dresses are getting final touches. While the whole process is enjoyable, I love this part most when great fruits of our work actually show.

If I am not going to reply as soon as I usually do to emails or issues around Drupal, then I am sorry, but at least you know why is that. By sheer luck, Drupal Conference Hungary is on the 15th of November, so I'll be able to present and attend without being tied to run away right after my presentation to the show. (We are having a day of break on that day due to the technical staff not the Drupal Conference just to make it clear).

While looking at a film excerpt is no substitute for seeing and hearing us in person, here is one of the songs I am going to perform: Hair.

As Tiffany published in the drupal.org post titled Drupal.org redesign officially underway in September, Mark Boulton design's activity with the drupal.org redesign is tied to a timeline, and will end in one week as originally planned. Whether this deadline is actually met or not, the fifth iteration of the prototype was posted on the groups.drupal.org group related to the redesign a few days ago.

For those better in the know then I am, Fluid.app might be quite old news. I however just got on the bandwagon recently, and I thoroughly enjoy it. Fluid is a Mac OS X application, which acknowledges the fact that we are not using "the browser" anymore, but we are working on our days jobs, using our private email, posting photos, chatting with friends, etc. And these are all distinct activities or tasks we do. So we would be more comfortable looking for our "photo app", "chat app", "email app" or even "work app", but most of our interactions are now done on the web, so all these are tucked under the "browser app".

Packt Publishing is at it again. They've published David Mercer's follow up to Drupal: Creating Blogs, Forums, Portals, and Community Websites, which was originally based on Drupal 4.7. The new book subtitled Build your own professional blog, forum, portal or community website with Drupal 6 tries to cater to the same audience but with greatly updated content.

David seems to be completely up to date on the Drupal 6 matters, as much as the March 2008 publication time allowed. This was one of the first Drupal 6 books on the market, and the author even managed to include a lengthy section on CCK. Hats off. Now that Views 2.0 is out for Drupal 6, many more people will consider using this new version as a base to start with. David caters to new users, not upgraders though, so this guide helps you get up to speed (and the Views covering books are still awaited on the market).

The book has a certain eye to detail in talking about things like setting up users and permissions. David even goes to note that setting up access rules for names or emails does not affect existing users. This practice was changed in recent Drupal versions, considering this a security bug instead of the way how Drupal works, and honestly, I don't think people expected to see this behavior noted in print. This attention to detail goes to extremes however in the examination of taxonomy. To my tastes, it would have been better to get down to more practical examples sooner instead of trying to organize the section around the theories of taxonomy. Same applies to coverage of HTML, where David tries to teach content producers certain HTML tags to write a feature-rich webpage. This might be a good idea for the theming section, but not where content is produced by end users.

With a book going into such details, you might think Drupal core fills up the pages in itself. This is however not the case. David goes to introduce contributed module installation right in chapter three with DHTML Menu module. Highly useful and/or popular modules such as Pathauto and Localization client are covered. So the book acknowledges that for building a website, Drupal core needs to be pimped up with contributed functionality. Another positive note in this approach is that even custom look and functionality is covered. In my humble opinion, this book does a modest but still better job in doing a custom theme then Ric Shreves' Drupal 5 themes accomplishes. JavaScript capabilities are also shown by integrating a custom JavaScript control.

All-in-all, I think this book is a good starter guide for Drupal 6 users, even if sometimes too detailed. You'll certainly need to be ready to learning a lot more from Views to CCK field modules while you actually build a more complex site, but starting off with a simpler website should be possible from the topics covered.