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.
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.
This article covers the configuration and use of IMCE (and related modules) to integrate uploading and inserting images within your Drupal content. We assume you are using either TinyMCE or CKEditor with the Wysiwyg integration module, but in a separate post we will cover using IMCE with the BUEditor, a simpler text editor which also works well with Drupal. Note: This article uses Drupal 7, but most of the tips should also be helpful if you are configuring a Drupal 6 site for the same functionality. Indeed, this site is still running on Drupal 6 and also uses a Wysiwyg-integrated CKEditor, IMCE, the Image resize filter, and Lightbox2.
In Drupal, there are actually a number of ways to add a WYSIWYG editor to a text area. The new “Drupal way”, used on over 150,000 Drupal sites and arguably not so “new” anymore, is to use the Wysiwyg integration module, which has support for several of the editor libraries. I would personally suggest using it, if your needs can be met by it, since it's becoming more and more powerful and offers a fair bit of flexibility to easily change the configuration or editor used. That said, there may still be reason, in Drupal 7, to use one of the single-library integration modules, such as the still-popular CKEditor project. The TinyMCE integration module development has already been abandoned in favor of Wysiwyg, but it's good to have alternatives. Note: In this post, we assume you already know your way around Text formats. Text format configuration can be one of the most tricky parts of properly setting up your WYSIWYG experience, so if you don't already feel you know your way around this common stumbling block, be sure to read our recent post about Text formats / Text filters, too. This article is a companion-post to that one, but it also includes some degree of overlap, since when we turn on the Lightbox and Image Resize Filter modules, we have new filters we'll want to use in some text formats and we will want to pay attention to the order in which they are applied, so we will briefly revisit this topic here.
Sometimes, when troubleshooting a Drupalissue on a site, it's best to determine how much time you are willing to spend on fully solving an issue and be willing to accept a reasonable compromise. We encountered such a situation recently with a rather odd issue: If an authenticated user attempted to post a comment on any of the German blog posts here, they were unable to complete the operation since the "save" button was missing ("preview before save" was required) and for some odd reason, "preview" was not working for admin or other authenticated user roles.
This is the second part in a series of posts which should help you get your Drupalblog fully configured. Last week we covered a lot about multilingual settings and basic configuration. This week we'll continue to configure the site and discuss our choices for other options. There's still more to come.
We recently decided to add a blog to our Drupal distribution site, and I jumped at the opportunity to help get it set up. Since it's a new feature for our site, I decided to document the steps I took in my development environment so that we can be sure to replicate what works on our production server.