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.
October 2012 brought us a nice batch of interesting new modules. Of course I wanted to tell you all about them weeks ago, but without going into excuses and details, I’m afraid getting this published didn’t go as planned. I’d like to get back on schedule to release the next installation of this series in early December, though. Anyway, it’s great to see all of the innovations that have been introduced in the past month. You can tell that Drupal 7 has truly reached maturity by the kind of modules that are being released now. Many, if not most, of the new modules integrate with and extend the functionality of other contributed modules—for example, there are three new modules which provide plugins for the Facet API—or integrate exciting new jQuery plugins to bring a bit of sizzle to your site.
As usual, the list is in alphabetical order and I haven’t tried all of these modules (although I have experimented with quite a few of them and even eliminated a few from consideration since they seemed a bit too “broken” at this point.) Some of these modules might not be ready for use yet, but just show good promise and look worth keeping an eye on. Creating this monthly list is as much for me as it is for you, but I do hope that the modules I select work well for you, if you give them a try, and I look forward to seeing your comments about any of these modules.
Rules is an especially useful Drupal module for all kinds of tasks. One use you might want to put it to is providing admin notifications of certain events on your site, e.g. user registrations (covered in the previous post) and the creation of new comments and content by “untrusted” users (assuming your use case allows them to create any content at all). For some use cases, you may wish to put strict limits on the creation of user accounts and content, but for the purposes of this article we are assuming you are administering a Drupal site where you want to encourage growth and community involvement, so you might allow anonymous users to comment on posts (albeit likely with the rel="nofollow"* attribute added to their links). And you might also allow users to create and confirm their own accounts and then create some types of content (e.g. forum posts, bug reports, etc). The downside is that you’ll need to be vigilant about squashing all the spam this policy invites (or the flow of new spam will quickly increase and be damaging to your SEO efforts), but on a site with only moderate traffic you should be able to manage this without a lot of trouble. This post covers using Rules to provide notifications of new comments and content. If you keep a close eye on user registrations and immediately block the user accounts which follow a pattern like other spam accounts you’ve removed (i.e. accounts likely created with the help of a “spambot”), you can eliminate almost all of the spam that requires use of an authenticated user account.
*Adding rel="nofollow" to links posted in “Filtered HTML”, presumably the only text format you allow for “untrusted” users, is simple, but well worth doing if you allow “anonymous” or newly-registered “authenticated” users to make any kinds of posts on your site. In Drupal 6, go to admin/settings/filters/1/configure and select the “Spam link deterrent” checkbox. In Drupal 7, go to admin/config/content/formats/filtered_html and find the vertical tab near the bottom labeled “Limit allowed HTML tags”, where the same feature is enabled with a checkbox labeled “Add rel="nofollow" to all links”.
Getting back on topic, the three events we want to create Rules for are:
In each case, we simply want to send an HTML email* to notify at least one member of staff (anyone with the admin role and, in the case of comments on blog posts, we might want to also email the article’s author.) As with the past installment in this two-part series, this article does not cover configuring your server for sending mail nor setting up HTML mail, but we use Mime Mail for the “send HTML mail” versions of the exported code you’ll find attached. (See attachments to this article for code you can use to import these Rules into your own system—you’ll possibly need to tweak them a bit, but they could save you some time.) Where screenshots are included, we’ll display the Rules administration interface in both Drupal 6 and Drupal 7, side-by-side, since there are some differences that might otherwise lead to confusion. So this article should be helpful for administrators of both Drupal 6 and Drupal 7 sites.
In every case, creating a new rule starts by going to the “add rule” page: D6:admin/rules/trigger/add D7:admin/config/workflow/rules/reaction/add
Notify Admin (and/or content authors) when new comments are posted
This rule sends an (HTML or plain text) email which includes the comment title and body, along with a link to quickly edit it. Here at Cocomore, rather than delete comment spam, we’ve been unpublishing the comments so we can still observe patterns. So we don’t get an email for each of our own responses to comments, we configure the rule to only notify us when “untrusted” users (i.e. any users who don’t have a “staff” or admin role) post comments.
Rules is an especially useful Drupal module for all kinds of tasks. One use you might want to put it to is providing admin notifications of certain events on your site, e.g. user registrations and the creation of new comments and content by these “untrusted” users (assuming your use case allows them to create any content at all). I recently created such rules to help monitor the creation of users, content, and comments on drupal.cocomore.com/.de. Since we use the Project module (and supporting code) to host and track issues on some Drupal modules, we allow users to create accounts and “Issue” nodes. But there hasn’t been much recent change to the modules we host, so most of the “users” turn out to be spamming scumbags who post “issues” with links to questionable sites (you know the type). Since we allow anonymous users to comment on our blog posts, we also get our fair share of comment spam, but a tricky Captcha (we’re using Riddler, these days, to filter out visitors who don’t know or can’t take the time to search the answers to simple Drupal trivia questions) helps keep comment spam to a minimum. Keeping vigilant about stomping out spam is important since leaving spam published looks unprofessional and is bad for SEO… and since it also attracts more spam (spammers see that your site leaves spammy links in place); but of course it’s also important to keep an eye on the valid posts, too, and to respond to them in a timely fashion.
So we will assume that you have a site without a massive flow of new user registrations or new content and that you want to be alerted with some useful information whenever these events occur so that you can take appropriate action (block users and clean out the spam… or respond to valid content/comments). This article will lead you, step-by-step, through the creation of three different rules on both Drupal 6 and Drupal 7 -based sites, identifying particular set-up differences between these versions of Drupal/Rules. The three events we want to create Rules for are:
New user registered
New comment posted (by non-staff user or “untrusted” user)
New content posted (again, by some kind of “untrusted” user)
In each case, we simply want to send an HTML email* to notify at least one member of staff (anyone with the admin role and, in the case of comments on blog posts, we want to also email the article’s author.) This article does not get into the various particulars of configuring your server to be able to send mail; there are a number of factors which might differ from server to server and it’s not really within the scope of a Drupal-related article. *Note: This article also does not cover setting up HTML mail, but some modules, such as Mime Mail help make this a relatively pain-free process and provide a “send HTML mail” action for Rules. Adding specialized modules is probably not justifiable if you don’t plan to use HTML mail for anything more than admin notifications, but if you want to email users, such modules can help you create much more attractive and useful emails.
In every case, creating a new rule starts by going to the “add rule” page: D6:admin/rules/trigger/add D7:admin/config/workflow/rules/reaction/add
Notify admin when a new user registers
This is a simple rule which sends an HTML email with a link to a new user’s profile, along with their username. If you allow users to register themselves on your site, you will likely notice patterns that persistent spammers follow and be alert enough to just block the most suspicious user accounts before they even start spamming your site. I won’t specify the suspicious patterns I’ve been reacting to here (I don’t want to teach spammers how to be sneakier or more effective), but if you have a spam problem, you probably already know the patterns or will quickly recognize them.
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.
April 2012 delivered a fresh batch of promising and useful-looking new contributed modules to the Drupal world. Perhaps because the immediately-preceding DrupalCon gave developers some time to collaborate and work on their contributions more than they normally might, this month seems to have a notable number of interesting new projects, especially considering the relatively “mature” state of Drupal 7 at this point. To help keep abreast of some of the most interesting new developments we have planned a monthly article to showcase these new modules; this is the first edition of our “Modules of the Month”. At this point in the release cycle, newly released modules are mostly only being released for Drupal 7, but a few have also been released for Drupal 6 as well; where Drupal versions are not mentioned, you should assume the module is only for Drupal 7.
Caveat: I have tested some, but not all of these modules. Be especially careful if you choose to use any of the “pre-stable” releases on production sites. I should also note that some other awesome modules released in April may not be included—I did my best to select the modules I’d be most likely to use, but there are some “special use case” modules which were not covered, but which might be very useful for some sites. The 30-something modules included here have been sorted into very loose categories.
3rd Party Integration / Social Media
Twitter Follow Block
The Twitter Follow Block module, by Pradeep Saran, provides a nicely styled box to show your Twitter link and followers in a jQuery-loaded block that can be placed in any region of your theme. You can configure the dimensions of the block (and thus, the number of “follower thumbnails” displayed) and you can choose from different color schemes to better match your current theme. It currently only displays the Twitter feed for one Twitter user, but what might be an interesting development would be a way to dynamically load the Twitter username (e.g. from a Profile field) so that the Twitter follow block would link to different users (based on the author of content currently viewed or the profile page being viewed, if applicable). The module is currently available as a “stable” 7.x-1.0 release and I look forward to seeing this get further developed.
The Social Buttons module by Linnovate’s Raz Konforti, provides a field that can be added and configured for any content type (or any fieldable entity) and includes default button code for Facebook, LinkedIn, Twitter and Google+, but you can also easily add new buttons. Since it’s a field, you can also determine where and whether it is shown for each display (node view, teaser, RSS, etc). It has a 7.x-1.0-beta2 release as well as more recent commits to the developer branch.
Content Access Control
The Hidden Nodes module, created by Bryan Ollendyke of Penn State University, helps allow staff to hide nodes from regular visitors while still allowing users with “staff” permissions (admin or author/editor -type roles) to see the content in the menu as it will appear when the content is finished. This helps get around the issues caused by the “black-and-white” absoluteness of published/unpublished status (and only being able to access content through the “administer content” system). It was created to integrate well with the Outline Designer module, another project sponsored by Penn State. Hidden Nodes has recently had its fourth beta release and is certainly an interesting project for streamlining team-based content workflows.
Restrict node page view
The Restrict node page view module, authored by Christian Johansson of Sweden’s Kodamera AB, helps prevent users from viewing content outside of its intended context. The example use case for this module involves a requirement to prevent users from directly viewing Views slideshow nodes (via their node/xxx paths), but of course there could be other content you want to restrict access to but still have its information available in a Views display, so direct access to the node by most roles can easily be blocked with this module. The initial release is shown as “stable”, and it’s simple enough, so may never require any fixes or updates. That said, I do hope that they modify the module so that full-node access is only restricted to selected node types (i.e. blacklist). It currently adds a set of permissions for all node types, which defaults to no view access for all roles and content types, which would be a pain on sites with lots of roles and content types, especially if the goal is only to restrict non-staff access to one limited node type out of many.
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.