Drupal related posts by Gábor Hojtsy.

Presenter commentary for "Drupal Module Development Kickstart"

When I was looking for topics to present at Drupalcon DC, I quickly realized I have not seen a Drupal module development presentation in the style I'd have liked to, so I should better try and deliver it myself. While playing with the idea, Peter Wolanin expressed his deep interest to join, especially since he shared the same views relating to what we should cover.

We designed our presentation to be complimentary to other presenatations, like the Gentle intro to Drupal Code which nicely explains high level concepts, but does not show the depth of what people can do, or the fun Pants.module session way back from Drupalcon Brussels, which shows a bit too much of what Drupal can do without explaining what people should not eventually do.

Interestingly, our session started off with why people should not write modules. After all, there are more then 4400 projects on Drupal.org, on which you can base your sites. If someone else maintains your code, it gets bugfixes and improvements while you sleep, you are on vacation or you sit at a presentation. However far these precooked modules get you, you will always find missing items which need custom development. Then and only then should you think about writing modules.

Therefore we focused our session around the alter hooks, modifying existing menus, form layouts, submission workflows, and so on. We did include an example of a complete module with SQL code and all, but quickly jumped to talking about why you should not do this at home. We might have picked a bit over-the-top examples for those not familiar with PHP, but the basic idea was to show off what you can achieve with a few lines of simple code, and then let people read the resources (books, cheat sheets, articles) with that in mind.

for those about to code we salute you

All-in-all, I think your module development should enter this era, if you did not focus already on this approach. Get your general improvements to the modules in question and use the alter, nodeapi, user, etc. hooks to modify behavior whenever you need to add, remove or modify capabilities for your own needs. Less code to manage for you, better for the community that you find the bugs in the common modules, easier the upgrade path when it comes to move one version ahead.

Peter was quick to post our slides while in DC with our speaker notes included and the sample module we compiled to contain all our examples. The sample code is a single installable Drupal 6 module with all our examples implemented. Happy coding!

Second day report from the drupal.org upgrade sprint

A couple weeks ago, Dries posted a call for sponsors for efforts to upgrade the Drupal.org site with its existing functionality and design to Drupal 6 and then start work on the redesign, new features and theme implementation. We are on the first phase at the moment, and sitting at the boardroom of One Laptop Per Child in Cambridge, Massachusetts. We are getting to second day's close, and already achieved an impressive amount of progress. Here are some of the most exciting items.

Self-made project planning tools on Drupal.org

We need to admit, these days, people are more reliant on contributed modules then Drupal core. What is in Drupal core is taken as a given and some requested new feature would ever come in a contributed module in a reasonable timeframe for a Drupal site builder. People are not waiting for Drupal 7 to get a feature, people are active in the issue queues to get things done sooner. Drupal core is supposed to lay the foundation and be stable for long, while contributed modules can experiment, change, and add new features on a much more active pace. So as a result, Drupal core can keep using the "will be released sometime" approach, and it does well with Drupal 7 allowing for more improvements by not keeping the "every 12 months" release cycle intact. With contributed modules on the other hand, much more frequent releases are anticipated with new features introduced through a shorter timeframe.

What's common in both, is that for longer lasting development, overseeing progress on major areas like the file API, the database layer and so on is important, while on shorter release cycles, knowing what is required for the release to be fixed, and whether the project is on track or not could be key to get contributors. So having (A) overviews of project progress and (B) checklists of things to be done is increasingly needed on drupal.org. There are a few things people did about these needs recently, and all have their advantages and disadvantages. There are some reasonably new approaches, so I decided to highlight the ways I see people approach project planning on drupal.org.

Drupal.org runs the infamous project* module family to help micro (and not so micro) projects run around the Drupal core. These include modules, themes and translations as well as installation profiles. Currently, drupal.org hosts more then four thousand (yes, more then 4000) projects, with support for a CVS space for hosting the code with branching and tagging, as well as a release system tied to those CVS concepts. Projects can also have an issue queue, which people can submit issues with, covering bug fix requests and suggestions as well as new feature requests. So a project's issue queue can be quite busy, but it is the only "core" way to track what needs to be done, who is assigned to these tasks, who is working on them, what is the current status and so on.

So eventually people started to experiment building new tools on top of project issues to help manage project planning, overviews and checklists. Here is a hopefully comprehensive list of what tools people built on top:

Just posted "The tech story behind the Drupalcon Szeged conference website"

I had many requests for a case study on how we did the Drupalcon Szeged 2008 website. Granted, it was a long time ago, I just had time recently to do a writeup, sprinkle it with links to modules we used and attach some images for your viewing pleasure.

While it is waiting for consideration for a drupal.org front page promotion, since you are reading (an aggregation of) my blog, you'll get to see The tech story behind the Drupalcon Szeged conference website now. I hope it will help you get some insight into the good and bad decisions we made while we built the website, and the technology behind certain fun functions, like the registration system, the drag-and-drop scheduler, the wiki whiteboard and even the dynamic projection screen at the venue entrance. It was certainly fun to build.

Watch out, the next Drupal fest, Drupalcon Washington DC is coming up quickly in just two months!

Special thanks to Robert Douglass for proof-reading and fixing some of my non-native English writing.

How does the drupal.org upgrade / redesign help you?

On Drupal.org, user HongPong asked a valid question about our Drupal.org upgrade/redesign fundraiser:

I am curious if these codesprint efforts will be useful for other projects. I think it's fantastic so many people are organizing, but I wonder if whatever form the bulk of this takes will be released - or is it mostly a one-off effort that is too customized to be generally useful elsewhere?

I thought it would be useful to have a blog post about this instead of just sending the reply in the comments, since I think this is an important topic to talk about.

  • As Niel pointed out, the modules used on Drupal.org will get attention. I've just started to use the "drupal.org upgrade" tag over the weekend to mark issues requiring an attention for the Drupal.org upgrade: http://drupal.org/project/issues-term/346 General purpose existing modules used on the site including simplenews, comment_upload, comment_alter_taxonomy, image or imagefield, and so on will be tested and fixed where required. New modules will be used on Drupal.org and will get similar attention: CCK and Views are the first obvious contenders (right, Drupal.org is not using these modules as of now).
  • Drupal.org runs some custom core patches to improve performance by handling master and replicated databases. We will take a deep look on these changes and will implement a similar or better solution for the upgraded site based on Drupal 6. Our caching setup will have similar attention. Having this insight we will be able to document what best practice we found to scale drupal.org. This will join documentation on ways to make Drupal more scalable. Such efforts on Drupal.org also helped improve general performance in Drupal itself (both current stable and current development versions) in the past.
  • The upgrade is planned to omit some of the current features on Drupal.org such as the current search implementation and the custom Drupal based distributed login system. OpenID and a new search implementation are about to be implemented in place instead. It will be easier to find stuff on drupal.org for your day-to-day development and you will be able to reuse your Drupal.org account on any OpenID supporting site.
  • These items above all happen as products of our upgrade, even if there is no redesign. While all of the above items are great by themselves, the redesign will be the biggest hit. It will help you use a more fine grained navigation, move around the Drupal.org subsites seamlessly, find and understand modules needed for your projects, and so on. But what's even better is that it will be a site you can point possible customers to. It will help you market your services, consulting, books, courses and so on more effectively, since the Drupal site itself will do a better job to help the community and the project market itself and flourish in the times ahead of us. If you earn (part of) your living from Drupal related work, this will give you a boost. If you do not yet earn (part of) your living from Drupal, you'll be more tempted then ever to do so.

We are making exciting things happen, but your help is still vital to make this a reality. You can help by donating some money to get the expert teams together (use the ChipIn widget in this post) or by contributing to the sprints yourself either via the issues listed at http://drupal.org/project/issues-term/346 or by coming to the sprints. Thanks for being part of getting this huge improvement into production!