nedjo's blog

Last week's first round of the code sprint focused on improving multilingual support in Drupal core ended on a high point: a major improvement to the UI for administering string translations was committed, thanks to great work by Roger López, Jakub Suchy, and Stella Power and some careful review by Angie Byron. Several others pitched into additional issues.

With over a dozen active participants and major progress on four significant patches, plus several smaller fixes, the first day of the Internationalization in Core virtual code sprint was nothing short of amazing! And if you want to join in, please do! We'll be in #drupal-i18n on IRC tomorrow (Wednesday) starting around 9:00 GMT and going until after midnight GMT. Never applied a patch before or checked out code from CVS? Don't worry, we can get you started. Here's a rundown of the day.

Goals

Last term I the great experience of co-teaching an intensive, full time course on Drupal site development at a local computer school run by the folks at northstudio.com (who also do Drupal development) in my home town of Victoria, Canada. It was a small class and a diverse one. Some of the nine students were turning to web development after other careers in law, the building trades, or alternative health. Others had personal projects that required a content management system approach.

Working on Drupal core means that any change you contribute - even the most trivial tweak - is likely to go through multiple levels of review before being applied. Most contributors to core can expect delays of weeks, months, in some cases even years before a patch is accepted--if indeed it ever is accepted. And even if a new feature you contribute to core goes in, you won't get to actually use it for months or years--the typical lag time until a new major version is ready for production use.

So it's no wonder many Drupal developers choose to work instead on contributed modules.

In contrib, if you're developing your own module, you've got a pretty free hand to do whatever you want. You can get a lot of functionality out there relatively quickly. And you won't have anyone breathing down your neck while you code. Want a new feature? Easy: code it up, press that metaphorical "commit" button, and you're set.

So end of story? Put in the occasional minor patch to core, but otherwise stick to the easy world of contrib?

Not quite. Because it turns out that the ease of contrib can also be its greatest pitfall.

The degree to which privacy is protected on the web is determined not only by the policies and practices of a particular site. In a web application, it also depends on the software the site is built on. Drupal excels at enabling individuals to share information. How strong is Drupal's corresponding support for protecting personal information and privacy? To answer this question, we'll look at display of private information, IP address logging, cookie use, and users' control over their own data.

I recently suggested that the way we approach new development is the most important factor in determining the long term value of our work. But just how can developers using Drupal make the most of open source by ensuring that participating and contributing is an essential part of our daily workflow? Here are some practical tips that come out of our experience at CivicActions and that can guide you in deciding how to approach new development to get the full benefit of open source. Read on as well for a discussion of patching vs. hacking vs. forking and of how to get attention for your patches.

When developing in Drupal, should we hack something together that's specific to a site? Or should we instead take the time to do things "right" by improving existing modules or writing our own new modules to contribute to the community? When is one of these options better than the other? How do we decide? It's a key set of questions. All but the most basic projects will require some level of new development. The way we approach this new development is probably the most important factor in determining the long term value of our work, both for us and for our clients.

It's a specter ghastly enough to make the most seasoned Drupal developer quiver with fear. Yes, it's the dreaded Haunted Drupal Site! Oh, it may appear innocent enough on the surface. Just a typical business or organizational website that perhaps you've been asked to upgrade or enhance. But don't be fooled--lurking beneath the surface is a host of nasty surprises just waiting for the developer naive or foolish enough to venture in.

One of the many great things about working at CivicActions is that we get a stipend for work we do for the community. This month I decided to use some of my stipend time to code up a proposed solution for Drupal core for dynamically loading paged content. Why should paged content be loaded through AJAX? Well, take the example of comments. You're viewing a page with lots of comments. You click a link to bring up the next 30 comments. You wait while the whole page refreshes.

This morning my Drupal development environment came miraculously to life. I used the opportunity to learn more about how the machines view us as humans and what their terms are for communicating with us. Here's a transcript of our conversation.

---

So I've been dying to know, machine, what do you think of us humans? Um, come again? I'm not quite sure I get what you're saying.