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.

How do I allow a user to create other users?

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.

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.

This is the second part in a series of posts which should help you get your Drupal blog 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.