Well, February is always a short month, but this year it seemed like it passed in just a couple of weeks… and now it’s already March and I’m only finally getting around to putting the final touches on this posting for the January “Modules of the Month”. How did that happen? Well, I won’t try to bore you or make excuses. It’s just been one of those months. I’m going to try to keep up my current momentum and evaluate and write up my favorites from February now… hopefully finishing that in the next week or so. If it’s not done by the 15th, it won’t be done till April since I’ll be taking off for my first trip to India in the middle of this month.
But I’m not here to write about myself. This is about some modules which I found might be worthy of notice… specifically those released in January 2013. It’s interesting to see the evolution of a Drupal version and what kinds of modules are being released these days. Almost no modules are being released for Drupal 6 and Drupal 8’s developer API is still far enough from maturity that there are very few modules being released for it, so almost all the focus is on Drupal 7. Almost anything really critical has already been done, so most modules now fit into areas of workflow improvement, integration of third-party libraries, developer tools, and addressing the needs of an increasingly mobile audience (responsive design). There are a lot of new modules for image display, for keeping a closer eye on site administration issues, creating better e-shops, deploying content from one site to another, and managing caching, among other trends. It’s clear that Drupal 7 is a mature product serving the needs of an extremely diverse community and it’s exciting to see all the new ways that, each month, developers encounter new needs and find inventive ways to further extend on the feature-set. So read on to see what new and fun stuff we got in January… (and I promise to try to get February’s review done in the next week or so).
Closing out the year 2012 with a bang, December brought us quite a number of new modules which look promising enough to cover; a few that I’m covering this time are far from ready or even only at the “concept” stage and normally would not be included, but they seemed particularly interesting or unique, and I want to see how they develop. Anyway, this month there were quite a few modules released for mobile support/responsive content. There were also several search-related modules, anti-spam modules, a couple of novelty modules, some interesting commerce-related releases, a number of Features package modules customized for various special-purpose distributions, lots of new “Third-party Integration” modules, theme enhancements, and more… I only wish I had more time so I could actually try out more of them, but there are several I do plan to get back to.
As usual, this post is sorted alphabetically and only covers modules which had their first release, or at least a new project created, in December. Selection for the Modules of the Month is a completely arbitrary process, but normally excludes common or niche items like a new payment method for Commerce that provides connections for a payment system used in, e.g. Romania. We also don’t normally include commercial service integration modules (unless the service looks really cool and is reasonably priced).
Anyway, it seems like only last week that I was putting the final touches on the November “Modules of the Month” story… oh wait, it was only last week: nine days ago, as I write this. Well I promised to try to get December’s published in early January, so I pushed some days around to make this happen. Let’s take a look at the modules, then, shall we? …
November 2012 was a busy month for a lot of people involved in Drupal contribution. It was the final weeks before the “feature freeze” for Drupal 8, so a lot of the focus was on new features for the next great release of Drupal. Many of the “new projects” were simply “namespace reservations” for new core modules or planned contrib modules which relate to Drupal 8; most of which had no project code committed at all (for some, presumably, it’s all in the main Drupal 8 repository). But there were also a number of new feature-enhancing modules released for Drupal 7 (and a few for Drupal 6), several which improve search functionality, a few for delivering mobile-friendly content from a Drupal site, some for commerce, others designed to help manage Drupal sites and ensure that nothing slips through the cracks when moving from “development” to “production”, among other new gems.
It’s fun, too, that we got a couple new “novelty” modules in November: one, Driesday, puts a “Happy Driesday!” message on your site every November 19th; another is a bit more insidious, with a fully-disclosed dependency on Bad judgement: Feature creep allows you to nostalgically hang onto the “good old days” when Features had a few more quirks. So if you want to remember that fun, just turn this module on and, as the module description says, “every time that you export or update a feature the Feature creep module will randomly add an extra component to your feature, what fun!”
Before we get into the module descriptions, of course, I should acknowledge the very late arrival of this month’s release of this column. It’s been one of those months… again. But let me try to hold onto my optimism that I’ll be seeing you with December’s write-up in just a couple weeks. I’ll be aiming for the first week of January. Now let’s have a look at the “new” modules.
I took a train from Frankfurt (Germany) down to Munich the Saturday before the DrupalCon. When I joined the Multilingual Sprint on Sunday morning, many of them had already been sprinting for a full day and a number of issues were ready for review, so I dived in, observing the behavior of Drupal 8 before and after applying patches, proof-reading the patches for anything odd (e.g. typos in the documentation), discussing the issues in comments and in IRC with people who were sitting just across the room (other times actually speaking in person). By the end of the day, instead of the dozen or so people that Gábor Hojtsy, the Multilingual Initiative team lead, had expected, there were close to 50 people at the location, some joining us in the work on Multilingual issues, some working on other Drupal 8 tasks, and some who were just arriving in Munich and followed the Tweets to where we were. Luckily, the location rented for the Saturdays and Sundays before and after the DrupalCon week was big enough to accommodate all the extra arrivals.
While on the topic of the venue we used for those weekends, I’d like to personally thank Stephan Luckow and Florian (“Floh”) Klare of the Drupal-Initiative e.V. for all that they did to find a nice place that would still leave us with a budget for food and for their valiant work on stretching the food budget while still serving up excellent fare, in keeping with the fantastic meals we enjoyed the rest of the week. Instead of ordering delivery, they prepared almost everything themselves, including beautiful open-face sandwiches, fruit platters, and lovely grilled specialties at a club we went to where you can barbecue in the Biergarten.
…thanks for the huge help to the local organizers, especially Florian Klare and Stephan Luckow. They helped us manage collecting and spending sponsor money wisely with the Drupal Initiative e.V, prepared great sandwiches and fruit plates for us and even organized a sprinter party night with grill food. It was amazing to work with such helpful and flexible local organizers. —Gábor Hojtsy, September 5, 2012
Since people were “fresh”, I think a lot of work got done on the first weekend and the Monday before the conference (more than 50 people joined us and worked on various core initiatives on Monday in the room we later used for core most conversations at the Sheraton), which also meant that issues were still fresh in our minds while we had days of sessions and conversations, so when we started sprinting again on Friday we had lots of new ideas for the tasks we were still working on. Friday’s sprints were at the Westin Grand, where there was great attendance both upstairs in the main room as well as a large room downstairs from it, where Drupalize.me hosted a core contribution workshop to ease people into the process of contributing to core. I decided to go to that workshop since I’m still pretty new to it all and found a few people sitting nearby who were I was also able to interest in some Multilingual tasks, so while the main group sprinted upstairs, we also worked downstairs. Later on, I came upstairs, and since there were not a lot of simpler tasks for “core newbies”, like myself, I took some time to sprint on a module I contributed some time back, before there was much of anything for Drupal 7 in the area of “multilingual”… and tried to make my module more multilingual-friendly. I got a few good commits and a new release out for Internal Links and also recruited a colleague to look at the code with me, provide some ideas, and become another maintainer. So I personally found Friday quite productive.
I started writing this post at the DrupalCon and then continued work on it on the train back home after a long week, last Sunday after the code sprints—even now, more than a week later (after being ill for a week—I think I was burning the candle at both ends for a bit too long), it’s hard to believe that it’s finally over. I arrived the weekend before to participate in the pre-con code sprints and stayed for the Friday–Sunday after the conference to continue that effort. I’ll write about the sprints in another post. This one will cover the highlights of the actual DrupalCon, what I think worked well, and recommendations for those attending their first DrupalCon; with two new continents getting a ’con this year, I think there will be more than a few at their first.
The food at DrupalCon Munich was great
For me, one of the major highlights of this conference was the outstanding food quality. It was so good I was distracted enough I never pulled out my camera to take photos of i, but it was attractive, gourmet, and delicious and there was something for everyone, even a fantastic salad buffet as well as more desserts than anyone could try… and hot dishes with plenty of options for both vegetarians and omnivores, alike. In the closing plenary, it was revealed that the catering costs for the event were about €352,000 for the 1800+ of us in attendance; not surprising for the quality and abundant variety of fare they served us. Food service tables were put in place in all areas of the conference so that there was no crowding into one area and the same dishes were provided at both the Sheraton and the Westin Grand, which were a few minutes’ walk away from each other. The conference occupied the three conference center floors of the Westin Grand and a few smaller rooms in the Sheraton, which were primarily “core conversations”. One might think I would gorge myself, but most days I had simple salad items, walnuts, and seeds… and gave myself a break before finishing with some fresh fruit and a light mousse from the dessert buffet. Despite the fact that the days were hot and many of the rooms weren’t well conditioned, people were alert and in good spirits and I think the food had more than a bit to do with that.
To continue a moment in the vein of “food”, since I really do think it was notable at this DrupalCon, I hope this reflects some new recognition of the importance of good sustenance when organizing a successful event like this. And I hope that future Drupal events will also place emphasis on food quality. That said, I also think that the community would pull together if we had commercial kitchen space and quality ingredients—we could prepare similar gourmet meals without quite the budget we used for catering at this conference; on the other hand, such a model might work better at one of the large DrupalCamps (a few hundred attendees) than at a huge (North American or European) DrupalCon. Of course preparing our own food would provide another place for people to connect (food preparation and more volunteer service), which I think would offset the downsides (not being able to be someplace else whenever you have “kitchen duty”).
Munich is a beautiful city I’d never really visited before the DrupalCon. Public transportation was not too expensive, but I got to see a bit more of Munich by walking almost everywhere, so my walks back from the pre-conference sprints and out to dinner (beer) in the evening were mostly through parks where I got to see the huge Olympics installation and unusual sights like Munich’s famous river surfing.
Sessions and participation
This was my second time attending a DrupalCon and I decided I wanted to primarily attend the “core conversations” track (with a few exceptions). For those who don’t know, the “core conversations” sessions are where plans for the future of Drupal are presented, discussed, and refined. It’s truly an amazing experience to sit in a room with dozens of top-notch developers as they hash out the architecture for new Drupal features or present the innovations they have already completed. Of course participating in the Drupal 8 (Multilingual initiative) sprints in Barcelona (a couple months ago) and before and after the DrupalCon session days probably also spurred my interest in the areas being covered by other initiatives, but it is definitely an interesting track if you are not sure what to attend. In the past, core conversations were often not fully recorded, another reason I chose to attend this track, but it looks like you can view most core conversations pretty well now, online. If you missed them and are interested in the future of Drupal (i.e. Drupal 8), there are many that you might want to watch.
Another first for me was helping the DrupalCon staff as a volunteer, mostly monitoring the rooms I was in and taking a head-count in mid-session. Other activities of a room monitor included being a bit early and making sure the speakers had everything they needed; I got to loan out a display adapter for one session and was prepared with multiple power adapters if anyone happened to be missing a way to plug in—we also tried to make sure that questions were recorded in session audio (either by having those with questions come to a microphone or the speaker repeating the question). I found volunteering rewarding and I thank Adam Hill, the DrupalCon Munich volunteer coordinator, for being a great guy to work with.
Drupal 8 will be great!
Angie Byron’s current overview of Drupal 8 (aka “Drupal 8: What you need to know”) had not changed a lot since I last saw her similar presentation at the “Developer Days” in Barcelona a couple of months earlier, but it filled the largest session room, so there may have been close to 1,000 in attendance. Some features are more polished, some of the features are not yet written, but are better conceptualized than they were a couple of months ago, but the general ideas are mostly the same so in a presentation providing an overview of Drupal 8, while much has changed, it wasn’t much that affected the presentation. I’ve take the liberty to add a few specifics which were actually covered in separate sessions (sessions which covered each core initiative, for example), just for the sake of brevity and consolidation of information.
One key point that was made by all Drupal 8 core initiative leads is that we are only 3 months away from “Feature freeze” for Drupal 8 (December 1st, 2012), so it’s time to pitch in and try to help get all the great planned features into Drupal 8. All of the major initiatives need help and have areas where they are behind schedule as far as being ready for the freeze deadline with all the features the community would like to have in core.
It’s been a busy past several days in Barcelona (for the Drupal Developer Days) and most of us who’d been sprinting during the week before seemed to be in the same condition by Sunday—rapidly running out of energy from progressive sleep deprivation from an increasingly later return to our hotels. But it’s been an exciting week for Drupal core (and contrib) development and significant work has been completed on the Drupal core (mostly building up Drupal 8, but also some for added features in Drupal 7) while a lot of important decisions have been made which will likely shape development in a number of initiatives for the coming months until the sprints at DrupalCon Munich.
In addition to the Sprint I was primarily involved in (I was just trying to get my feet wet with assisting the Drupal 8 core development process by joining the multilingual sprint, but I did write my first committed core patch—admittedly this was a very basic patch), there were also sprints running for “Views in core”, Entity API, Media initiative, Mapping in Drupal 7, configuration management, abstracting social networking, search-related sprints, the Drupal.org upgrade… and possibly more still. I’ll cover some of the highlights of the week that I’m most knowledgeable about.
The multilingual initiative sprinted all week before the Developer Days sessions, and even continued through the weekend. And a lot of key decisions were made and important code changes committed and pushed to the central Drupal 8.x repository.
New user interface translation improvements in Drupal 8
This is something I got to do a bit with, but Swiss developer, Michael Schmid (Schnitzel on d.o), of Amazee Labs, was the primary developer working on this task during the Sprint. He and his colleague, Vasi Chindris, were among the stars of the week. It was a real privilege to get to look over their shoulders and to get Michael’s support when it came to using Git to manage code in the sandbox we were using for the issue. (Thank you, once again, Michael!) Once everyone was happy with the work, it got committed to core. This new sandbox workflow, used for larger issues, helps avoid a lot of bugs creeping into the main branch, as has happened during previous periods of intense core development. Of course the tests and test bots catch a lot of issues which could otherwise be major headaches for all concerned (automated testing was also a part of Drupal 7 development). If you recall, the long wait for Drupal 7’s release was due to hundreds of critical bugs. Now this should be a thing of the past since we have an established threshold for critical issues; and the core team only commit new patches to the central repository when we are below that threshold (15 “critical” bugs, 100 “major” bugs… among other thresholds specified).
The new user interface translation system allows you to keep imported (community contributed) translations separate from customized translations and search for a particular translation within either or both categories as well as filter by translated strings, untranslated strings, or both. If you have any unsaved translations, they are highlighted to help remind you not to leave the page without saving them and there discussion about providing a dialogue to prevent a site admin from accidentally leaving the page with unsaved changes, too. There is also an issue to allow the string search to be non-case-sensitive (checkbox) to find more strings that contain a particular word or phrase, regardless of text case. Since this feature came up in discussion after the rest of the user-interface changes had already been made, we elected to put the discussion about adding this feature in a separate issue. If you have ideas for what might further improve the Drupal 8 user-interface translation workflow, your input is valued.
I was supposed to get into Barcelona at 10:30PM on Tuesday evening, but with delays in my flight, it wasn’t till after midnight that our plane landed; it was after 1 a.m. by the time I reached my hotel. Normally travel, when it runs late and long, makes me feel exhausted, but I was excited to be joining my first Drupal core sprint. I’ve been wanting to do a bit more to help build Drupal and it’s great to not only be somewhat aware of what’s coming in Drupal 8, but to also know that I’ve at least played a small part in making it happen.
I wasn’t sure I would attend the Drupal Dev Days in Barcelona till a couple of weeks ago, but I’m glad I’m here. We have a fairly sizable group of developers here at the Citilab helping work on cutting through the issues for Drupal 8 Multilingual Initiative (D8MI). I’ve been helping with some user interface quirks and since it had been long enough since I’d actually done string translations of the user interface, I started out yesterday as a “tester”… at least trying to look at the problem of translating the interface (e.g. translating “Add content” to German) as if I had never done anything like that before. And we did find some issues and, even better, we were able to address and correct those issues during yesterday’s coding. Others have been working on multilingual issues related to the new configuration management system, and a number of other issues which you, too, can help with, if you’d like to join us remotely (or in person, if you happen to already be in Barcelona — the Sprints continue through Friday, too). There are currently about 40 of us in the IRC channel for i18n and I'd say that at least half of those are working on the Sprint. There are about a dozen (give or take, since people are working on other sprints, too) who are here in Barcelona working on D8MI.
It’s a pretty common use case which requires a non-admin user role that can create other users for a Drupal site and I’ve frequently seen questions about how to best implement this. I recently also saw the suggestion to simply create a role with the 'Administer users' permission. At first blush, it might seem to work; if that’s the only “administer” permission they have, users with this role can only create basic users with the role “Authenticated user”, they cannot edit the user to add any other roles or upgrade their own role directly. In limited situations, this might even be appropriate.
What might not be immediately apparent, however, is that a user with this permission can edit any other user’s account… and I do mean any. This means that, if their intentions are not pure, a user with this role could easily change the password (or any other fields) on a more privileged user, even user/1, and then log into that account. Once they’ve done that, there is really no limit to what they could do to your site. Even if they have no means to add modules, ones which might be used for particularly nefarious purposes, if you have a module like Backup and migrate available, they could download your database with all sensitive user data; and even if this module is not available to them, you most likely have Views, which they could also use to harvest all user email addresses or other private data fields. And then they could easily cover their tracks, too. If they don’t do anything obvious (like deface your site or start sending spam from it), and only change the password on the admin account, you might be puzzled by why you cannot log in with your normal password, and follow the normal procedure to reset your forgotten password, then forget all about it. Meanwhile, your “user moderator” has collected lots of sensitive data from your site and still has the means to do it again one day.
We have a major upcoming project here at Cocomore which is in the initial planning phase. It’s too early to provide the finer details of the project, but it involves creating a product database for a large publishing house and Drupal 7 has been chosen as the project framework. By mid-June, we will likely have four developers working on it, full-time. Of course, anyone who deals with software development almost certainly knows the problems that tend to occur during the planning of large-scale, long-term projects like this one: in the beginning, the client is often not yet 100% certain of their needs or desired end results, so new requirements and ideas arise in the middle of project development. This means that projects built to the initial specifications often fail to completely meet the client’s needs, which can be disappointing for everyone involved.
Hoping to avoid this scenario, we (our software development team, and project and senior management) proposed implementing the project using Scrum. This allows us to flexibly respond to changes in requirements and keeps the customer closely tied to the project development process so we can avoid unpleasant surprises at the end of development. At a recent Cocomore “KnowledgeLab”, I presented a brief overview of Scrum methodology, a topic which is certainly too broad to cover, in-depth, in an hour-long presentation. So I limited the scope of my presentation to the most essential elements of the Scrum process: roles, events, and artifacts; then used Lego Scrum to try to better illustrate the model. This article provides an overview of the same basic concepts covered in our workshop session and describes how I helped immerse team members who had not previously worked with Scrum in the concepts and processes. We have been using Scrum for other “ambitious” Drupal projects and plan to provide in-depth case studies for some of them, with details about more specifics related to Drupal; this article provides a general foundation for understanding these upcoming case studies.
Scrum: a process model for agile software development
Agile software development is characterized primarily by an iterative procedure with alternating planning and development phases. The advantage this provides is that parts of the system are developed early on and can be tested before implementation of other parts. This reduces the risk that project development heads in the wrong direction. Rather, responding quickly and flexibly to changes in the requirements, the components of a system can be redefined to best meet a client’s real needs.
I was already planning to provide an overview of what’s been going on in the various Drupal 8 initiatives even before last week, when Dries announced the timeline for Drupal 8, which includes a “feature freeze” for Drupal 8 in only a little more than nine months from now, and planned release at the DrupalCon Europe, in late August 2013.
Drupal 7’s Plateau of Productivity?
While most of the top Drupal 6 modules are now available, in some state or another, for Drupal 7, and I would certainly choose Drupal 7 for a large Drupal-based project that is not expected to be deployed for some time, from the outcry of protests I think there are a lot of people who would not agree that Drupal 7 is yet at its Plateau of Productivity. I would choose development in Drupal 7 for most projects, but there is still plenty of reason for site builders to work with Drupal 6, especially if they need particular features (e.g Nodewords / Metatag functioning properly, among others) and if they need to deploy the site now, with those features ready for use. Dries indicated that he thought Drupal 6 reached its Plateau of Productivity in late 2009, about 18 months after its initial release. At that point, there were fewer than 20,000 sites using Drupal 5 and more than 200,000 sites using Drupal 6. While this order-of-magnitude-greater-usage is not likely to ever be seen comparing Drupal 7 vs Drupal 6 usage (at least not before Drupal 8 is released), I do think that it’s significant that Drupal 7 usage has finally overtaken Drupal 6. That said, I don’t think we are truly at Drupal 7’s Plateau of Productivity, the point where building a new site on Drupal 6 would be “pointless”. Both in terms of time-after-release and usage statistics, it is arguably premature to say we are quite to that point yet.
Quibbling aside, I also don’t think it matters whether we believe we have reached the Plateau of Productivity for Drupal 7, or not — and it certainly doesn’t matter whether we are all in agreement about that. I do think Drupal 7 is very “ready for use”, though and I do think we are ready to see core development for Drupal 8 get kicked into high gear and I don’t think it will significantly delay the development of certain lagging contrib modules or resolving core issues in Drupal 7 which are the final barrier, in my view, to truly reaching its Plateau of Productivity. Additionally, many of the fixes and features going into Drupal 8 are regularly being back-ported to Drupal 7, and there is increased discussion of relaxing the criteria for what can be back-ported to Drupal 7, so I see the increased attention to Drupal 8 core development as exciting: a win-win for the whole Drupal community. We now have a release date for Drupal 8, which is important for business decisions, and a better timeline to facilitate a roadmap for the final stages of determining feature inclusion.
Drupal 8 Core Initiatives
Currently there are 6 official Drupal 8 Core Initiatives which are working on various aspects of desired improvements to core. There are others likely to be added to the list as soon as a bit more progress has been made on the current list and/or as qualified individuals step up to take on some of the other “top 10” desired improvements we had on our collective community wishlist. Some of the improvements require fixes to issues plaguing Drupal 7 and 6 and have been backported. Most of the others involve dozens, if not hundreds, of related issues. Following is a brief summary of each of the current core initiatives and what their priority goals are for Drupal 8. In the interest of brevity, the explanations leave out a lot of juicy details, but for those who haven’t been paying close attention and who might like to get involved, I hope this summary is useful:
Web Services and Context Core Initiative
The Web Services and Context Core Initiative (WSCCI, pronounced “Whiskey”), formerly referred to as the “Butler” project, is a core initiative led by Larry Garfield of Palantir.net, aka “Crell” on Drupal.org. While the traditionally typical HTTP request has been for HTML pages, the modern Web has brought with it the need for HTTP services which deliver information which is not necessarily in the form of HTML. This is especially true for mobile applications, but also applies to feeds and other communications via HTTP. The goal is to “take Drupal from being a first-class Web CMS to being a first-class REST server which includes a first-class Web CMS”. Really, this initiative spans a huge range of related issues and without writing an article many times the length of this one, I could not possibly cover everything, but…