6 August 2012
New spam content posted

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 equals nofollow to Drupal Links

*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:

  1. New user registered (done, see previous article)
  2. New comment posted by “untrusted” user (described below)
  3. New content posted by “untrusted” user (also described below)
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.

5 July 2012
New Spammer Registered

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:

  1. New user registered
  2. New comment posted (by non-staff user or “untrusted” user)
  3. 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.

28 October 2011

Some time back, I promised another short article in the WYSIWYG set-up series for Drupal 7, one which covers BUEditor. First, we should note that the BUEditor is not actually “WYSIWYG”, but it offers some nice features which might make it a bit better than the WYSIWYG options, depending on your use case. It also does not integrate with the Wysiwyg module. You add it separately (and instead of Wysiwyg), but it does have some great supporting modules and code libraries. This article covers some of the basics about use and installation of the BUEditor on a Drupal 7 site (most of the information applies equally to Drupal 6, where the BUEditor module is also available). I’ve also got some good tips for some ways to extend the default button-set. (And you can download my modified button code here to easily import the buttons into a new editor profile.)

6 October 2011

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.

18 September 2011

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.

29 August 2011

Sometimes, when troubleshooting a Drupal issue 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.

16 August 2011

Working with Text format filters (aka Input format filters) can be a sticky point when building and configuring a Drupal site. Even experienced Drupal site administrators might sometimes forget a step when they turn on a module which provides an input filter -- then it can be confusing why things aren't working as expected. In this short lesson, we activate and configure the Internal Links module, which adds node titles as the HTML title attributes for links to other nodes on the site.