The most exciting move in Acquia for me so far just happened a few days ago. We rolled out what was called "Big tent" internally, and means much wider support for all Drupal 6 sites. As Dries points out in his blog post, we used to support our Acquia Drupal distribution via forums, tickets and phone support. However, we found that virtually all sites will use other modules, custom code and themes, tweaks to existing code.
I've immediately jumped on the new 6.5 release of the Netbeans IDE when it was released with much fanfare about its PHP support. Netbeans is a free to use IDE sponsored by Sun. I've used it years ago to edit XML documents, but did not look back on it ever since. Now it does indeed have nice PHP syntax highlighting, context sensitive code suggestions and debugger support as you'd expect from a PHP IDE.
One of my first new year's readings was Dries' reflection post on 2008 which includes predictions for 2009. One of the predictions is that he sees Drupal 7 to be released in the last quarter of 2009. He predicts pain but a strong outcome.
I predict that Drupal 7 will be released in the fourth quarter of 2009. The two most exciting features in Drupal 7 core will be custom content types and radical improvements in usability. To reduce the risk of important modules falling behind in support or update path, a significant portion of the Content Construction Kit (CCK) related modules will move to core and we'll pave the way for the Views modules. The same holds true for other important contributed modules, including token module, path auto module, and image handling functionality. In 2009, core becomes bigger, not smaller. The Drupal 7 code freeze will be longer than expected regardless our new continuous test framework, and the upgrade path to Drupal 7 will be more painful than hoped for. But like always, we'll come out stronger than before...
Two key takeaways to spread from my mind are that:
You should seriously move to Drupal 6 instead of staying on older versions, in anticipation of a new major Drupal release around the corner. The key modules are already out, and they are amazingly more useful then their Drupal 5 or earlier counterparts. The action happens in the contributed modules area!
The doors for your work on Drupal 7 are wide open! You should not hold back big ideas on the grounds of a shortly coming Drupal 7 release. We still have time to design and discuss bigger changes. No wonder the fields in core effort needs time to stabilize and achieve "CCK in core" on higher levels that we anticipated before.
Happy upgrading Drupal 5 sites, working on Drupal 6 modules and contributing to Drupal 7 core in 2009!
I've helped recently to unfork the Bluebeach theme (the theme used on Drupal.org and subsites) which was used with different code on drupal.org and groups.drupal.org. So now both sites can use the same source code for their theming. I've also ported the changes to the Drupal 6 port of the theme which was done by Earl Miles earlier, based on the Drupal 5 version. These were all in anticipation of doing upgrades of drupal.org and subsites with the existing theme before going to the next step with Mark Boulton's redesign.
Dries Buytaert recently posted his Fields in core code sprint debrief, in which he mentions toying with the idea of organizing a Drupal.org upgrade sprint at Acquia. This is what Dries has to say:
All things considered, this [Fields in core] sprint was a big success, and I'm now toying with organizing a "drupal.org upgrade" sprint at Acquia during the last week of January. The goal would be to upgrade drupal.org from Drupal 5 to Drupal 6, and make progress on the drupal.org redesign work. Is anyone interested in participating in or helping fund this sprint? If so, more soon.
From my previous involvement and blog posts, it is probably not big news that I am very interested in helping out with that. Are you?
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 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!
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!
