Nov 19 2012
Nov 19

Drupal's highly granular permissions system allows site builders to control who can create, edit, and delete each type of content on the site. Third-party modules can add additional permissions to that mix as well, paving the way for extremely focused role-based permission setups. The interface for configuring all of those permissions, however, is more than a bit cumbersome. Thankfully, the Permissions Grid module offers a solution: a consolidated permissions page that only includes node and entity type specific options.

Screenshot of administration screen

Installing the module doesn't alter the operation of Drupal's standard permission forms. Rather, it adds an additional "Permissions Grid" page that exposes just node and entity related permissions. Because Drupal 7's entity system includes Taxonomy terms, Drupal Commerce products, Flag module flag types, and more. Because the permissions are organized by content and entity type rather than by name (the normal Permission screen's default), it's quite a bit simpler to set them up or skim them to review their current state.

Permissions Grid is a simple module, but if you're frustrated by the complexity of node type permissions, it's a quick and painless solution.

*/
Nov 05 2012
Nov 05

How to Tidy URLs and Relative Links When Moving From Dev to Go-Live (for Drupal 6 and 7)

Few things are as annoying as building something that works perfectly when you create it, but fails when you take it out of the lab. That's how site owners can often feel when content editors create piles and piles of Drupal nodes full of relative URLs in images and links. They look fine on the site, but if the content is syndicated via RSS or Atom, sent out in an email, or otherwise repurposed in another location, the links break. Even worse, hand-made links and images entered while the site is under development can easily point to the outdated "beta" URL. Who can save the day? Pathologic module, that's who.

Pathologic module's configuration options

Pathologic is an input filter -- to install it, you drop the module into your Drupal site and add it to one of your text formats -- Full HTML and Filtered HTML, for example. Whenever content is posted in a format configured to use Pathologic, it will scan the content for URLs and tidy them up. Relative URLs like /node/1 get turned into absolute ones like http://example.com/node/1, URLs pointing to alternative versions of your site like dev.example.com are replaced with your public URL, and so on.

Pathologic can also standardize the protocol of links inside your site's content. If users edit content over a secure connection, for example, it's easy to mix links using the http:// and https:// protocols -- something that can lead to annoying warnings on some users' machines. For developers with exacting URL-correcting needs, it also supports custom URL modification hooks. Using those hooks, your site's custom fixes (replacing MP3 links with a URL on a different server, for example) can piggyback on Pathologic's configuration and logic.

Pathologic is an efficient workhorse of a module that solves an annoying problem efficiently. If you've run into problems with relative links and staging-server URLs breaking links and images on your RSS feeds, you owe it to yourself to check it out!

*/
Oct 22 2012
Oct 22

Anyone who's ever talked shop about Search Engine Optimization has heard of meta tags. Those bits of extra data jammed in an HTML document's HEAD section provide search engines, browsers, and other software with important information about a document's contents, related links and media, and more. There are quite a few ways to jam meta tags into a Drupal site, and there are even APIs to set the contents of a page's meta tags yourself, if you're a module developer. Thankfully, you don't have to sling code thanks to the excellent Meta Tags module.

Screenshot of administration screen

Maintained by prolific Drupal developer Dave Reid, Meta Tags provides a centralized configuration screen where common meta tags can be edited sitewide, for specific types of pages, and even for pages belonging to specific entity bundles. Need one set of tags for photo galleries and another for user profile pages? No sweat. Meta Tags uses standard Drupal tokens to build the contents of its tags, and the configuration options themselves can be exported and saved in Feature modules for easier deployment.

Screenshot of advanced options

Third-party modules can add new meta tags to the mix, and add new types of URL paths that need to receive custom tags. The Panels Meta Tags and Views Meta Tags projects, for example, allow each view and panel to have custom, token-driven meta tags just like nodes, users, and so on. Meta Tags is already a popular solution to the thorny problem of sitewide meta tag customization -- check it out if you need more than Drupal core's auto-generated ones.

*/
Oct 15 2012
Oct 15

Almost a year ago, Module Monday featured the Views Datasource module, a tool for exposing custom XML and JSON feeds from a Drupal site. It's a great tool, but what if you need something a bit more... human-readable? A .doc file, or a spreadsheet for example? That's where the similarly-named but differently-focused Views Data Export module comes in.

Screenshot of administration screen

Views Data Export provides a custom View display type optimized for producing downloadable files in a variety of formats. Need a Microsoft Excel file with a list of the latest 100 posts on your site? Looking for a Microsoft Word .doc file that collects the text of the site's top-rated articles? No problem. The module supports XLS, DOC, TXT, CVS, and XML exports with format-appropriate configure options for each one. In addition, it uses Drupal's batch processing system when it's asked to generate extremely large export files, rather than timing out or giving out-of-memory errors.

Screenshot of resulting change to site

Whether you're putting together reports, giving users an easy way to download product data sheets, or conducting a quick, ad-hoc audit of your site's content, Views Data Export is a handy tool to have around. Its batch processing support makes it more reliable on large sites, and its support for a variety of "day to day" file formats means you'll spend less time juggling your data and more time making use of it.

*/
Oct 09 2012
Oct 09

With Drupal's custom content types, custom fields, and the addition of the popular Entity Reference module, site builders can whip up complex content models without a line of code. Editing those complex inter-related content types isn't always easy for content creators, though. The "Create a node, save it, then create its parent, then link the two" workflow is frustrating and error-prone. Fortunately, the Inline Entity Form module can help.

Screenshot of administration screen

Like many of the nifty Drupal tricks these days, Inline Entity Form is a custom field editing widget. On any content type with an Entity Reference field, choose it as the field's editing widget, and the rest is magic. When you create a new piece of content, you'll get the form to create the referenced entity on the same form. It works smoothly with multi-value fields, and can use a simple autocomplete picker to link existing entities if they already exist.

Screenshot of resulting change to site

The challenge of creating and populating complex nested content relationships has always been a tricky one in Drupal. Inline Entity Form was created by the Drupal Commerce team to simplify the management of complex product collections, and it solves the problem quite nicely.

*/
Oct 01 2012
Oct 01

Setting up geo-location data on a Drupal site is startlingly straightforward these days: pop in Geofield or Geolocation module and start adding latitude and longitude data to your nodes. Once you have the data, setting up maps and other complex geographically-aware content listings is easy. Unfortunately, it's that "getting the data" part that can be thorny. If users are willing to type in exact street addresses or latitude/longitude pairs themselves, there are more than a few options. If you need to transform other kinds of data into useful location data, though, Geocoder might just do the trick.

Geocoder Google options

Geocoder provides as a custom field editing widget for several popular location storage fields (Geofield, Geolocation, and Location module). Rather than offering a custom input form, however, it lets the site administrator pick another field on the content type that contains some geographical information.

Are you creating nodes whose titles are city names? Tell Geocoder to send that title to Google's geocoding service and store the resulting data in the Geofield. Are your site's users uploading photos with location information from a camera phone? Tell Geocoder to use the image field as its source, and the location data will be extracted automatically. The actual location storage fields -- the ones that hold latitude and longitude values -- are kept hidden from users and editors entirely.

Geocoder EXIF data extraction

Geocoder supports an impressive array of encoding APIs and data extraction mechanisms, from uploaded .KML files to Mapquest-parsed street addresses. It's an excellent swiss army knife for sites that need user-entered geo data, and a great addition to any site builder's arsenal.

*/
Sep 24 2012
Sep 24

Drupal's built-in support for generating RSS feeds has long been an easy selling point. Do you have content? If so, Drupal will generate a feed of it, easy-peasy! Unfortunately, that RSS support hasn't kept up with the flexibility of Drupal's FieldAPI. The RSS format supports extensions to handle data types like file attachments, location data, and so on. By default, though, Drupal, jams all of your custom field data into the body of the RSS feed as simple text. That's where RSS Field Formatters comes in.

Screenshot of administration screen

RSS Field Formatters is a collection of slick formatters for Date, Geo Location, User Reference, Taxonomy, File Upload, and Media fields. Just set up your content type with the fields you'd normally use -- then, for the content type's "RSS" build mode, select the RSS-specific formatters for the fields you'd like to appear in proper feed elements.

Screenshot of the RSS feed

The results aren't flashy, unless you're an XML aficionado, but the improvement is important. If you're using RSS your RSS feed to move content from one site to another, the properly-formatted data fields can be imported more efficiently. In addition, geolocation and media attachments can be parsed and presented to users by many news feed readers: it's always better to pass along the data in a format they can work with.

RSS Field Formatters is smooth, easy to set up, and does a great job of sprucing up your RSS feeds with complex data that would otherwise go to waste.

*/
Sep 17 2012
Sep 17

Drupal's Form API allows developers to easily integrate complex validation code into the workflow of a user input form. Unfortunately, the actual feedback from that form validation code is often a bit clunky by modern web standards. Fill out a form, submit it, and wait for a new page to load: only then do you discover that your cat's zip code was required. Providing speedy, immediate feedback on the client side is commonplace on modern web sites; fortunately, the Clientside Validation module makes it easy to implement on Drupal sites as well.

Screenshot of administration screen

Clientside Validation serves as a wrapper around the existing jQuery Validate plugin. It allows site administrators to set up the basic parameters for the plugin's work, like when validation actions should be triggered, where they should be displayed, and so on. Most of the display options look a bit clunky out of the box, but with some CSS styling to position them (positioned next to an invalid field, hovering contemptuously above an incorrect Zip code, etc.) they can be made to fit most designs.

Once the module is activated, basic FormAPI validations (required fields, for example) appear instantly on the client side without the need to submit the form. Even better, the module integrates with a host of additional modules like FormAPI Validation, Field Validation, and WebForm Validation. Custom validation rules added by those modules can be handled on the client-side, as well.

Screenshot of resulting change to site

If you're trying to smooth the rough edges off of complex input forms, providing better validation cues is a great place to start. The Clientside Validation module does a great job of integrating a slick jQuery library with a pile of other validation-related modules. Give it a try!

*/
Sep 10 2012
Sep 10

Drupal's Node Reference and Entity Reference fields do a lot of heavy lifting for complex sites with tangly content models. They allow one piece of content to point at another one, and those relationships can be leveraged when building Views of content, formatting individual piece of content for display, and so on. Unfortunately, when it comes time to display the output of a reference field, "Print the title of the referenced entity" is usually the only option. What if you want something else -- like its description, or the bio of its author? Sure, you could crack open a text editor, build a custom module, and write your own FieldAPI formatter plugin. Or, of course, install the Token Formatters module.

Screenshot of administration screen

With the module installed on your site, one subtle but important new addition appears: a "Token Formatter" for any FieldAPI node, user, or entity reference fields. Customizing the formatter's settings for a given field lets you use tokens to specify the text that will be printed and (optionally) the URL that the formatted output will link to. Want to print out a node along with the name of its author? Want to display a user reference with a link to the user's home page, instead of their Drupal user profile page? Just use the appropriate tokens, and the module does the rest.

Screenshot of resulting change to site

The only serious downside to the module is the difficulty of extracting complex field values (like formatted images) using the token system. While it's possible, the module is better suited for textual values and links. In addition, there's no token reference for site builders to look at when filling out the formatter's settings. Because there are so many tokens, it's a real challenge to guess the right ones. Token module provides a standalone page with just such a list, but if you're not familiar with it, this module's configuration screen can be a bit of a stumper. Those two issues aside, Token Formatters is a quick way of tweaking a reference field's output without writing any custom code.

*/
Sep 03 2012
Sep 03

There comes a time in every Drupal site builder's life when a content type must redirect to another page. Perhaps your site contains a collection of links, and you'd like visitors to see the destination site itself rather than the node that describes it. Perhaps your site features small chunks of promotional content that point to other nodes, and shouldn't be treated as primary content themselves. Wouldn't it be handy to redirect to the destination content automatically when the promotional node is visited? It certainly would -- and that's precisely what the Field Redirection module delivers.

The heart of the module is a well-implemented field formatter. If you have a content type that uses a Link field, a Node or User reference field, or an Entity Reference field, you can assign it the Field Redirection formatter. When the node (or any other entity with fields using this module) is viewed, Field Redirection doesn't render the field as HTML -- instead, it redirects the user's browser to the referenced user profile page, node page, link URL, and so on.

Screenshot of Field Redirection configuration screen

Because Field Redirection sidesteps the normal FieldAPI behavior of 'Building HTML for Display,' there are important caveats. The formatter should only be used on the Full Content build mode for an entity. If it's used for teasers, RSS feeds, Search indexing, Views listings, or other modes where it could be unintentionally triggered, your site will be redirecting itself to new URLs instead of executing important code. That warning aside, the module is an elegant and easily customizable solution to a common problem. If you're building lightweight "linking" content types that point at other elements or other URLs, Field Redirection can make life quite a bit easier.

*/
Aug 27 2012
Aug 27

One of the basic building blocks of a functioning publishing tool is the ability to view, edit, and preview content before it's published. In older versions of Drupal, that was an all-or-nothing affair: either you gave people the dangerously overpowered "Administer Content" permission, or you downloaded a comprehensive access control module and started building a custom permissions system of your own. In Drupal 7, it improved: roles can be given permission to view their own unpublished content, or given the ability to bypass all content access control, but it's still a bit clunky for a lot of very common use cases. Thankfully, there's the aptly-named View Unpublished module. It brings juuuuust enough control without requiring a complex permission matrix.

Screenshot of administration screen

Once you've installed View Unpublished, a set of new permissions becomes available. You can grant individual roles the ability to view other users' unpublished content on a per-content-type basis. With that one addition, it becomes much easier to build simple editorial dashboards that give editors or contributors limited access to other writers' work before publishing, or for all the members of a team to see what the site will look like once content goes live.

Normally, we'd include a screenshot of the module 'in action,' but the simplicity of the tool makes that a bit tough. When View Unpublished is working, most users don't see anything at all! There are a few limitations to the module's streamlined approach, of course. Permission to publish and unpublish content is still handled by other tools, and it's up to you or another site builder to construct a functional "dashboard" for unpublished content if it isn't already listed on the front page or another easy-to-find location. For quick and simple access permissions on limited publishing workflows, however, View Unpublished is a great tool.

*/
Aug 20 2012
Aug 20

Managing user roles in Drupal is easy -- at least, technically easy. It's a bit trickier if you have a large user base and need to manage a steady stream of people requesting access to specific privileges, new roles, or additional responsibilities. If you're in that situation, get ready for some quality time with your email client, and set up a regular appointment with Drupal's User Management screen. Fortunately, the Apply For Role module can simplify the process.

Screenshot of Apply for Role management screen

With Apply For Role, users can visit a new tab on their user account page and request access to a new role on the site. The request is queued up for an administrator, who can review, approve, or deny requests from a central management page. Requests can also be deleted -- allowing the original user to re-submit their request later -- or denied, ensuring that they can't send in more requests for the same role.

Screenshot of Apply for Role configuration form

The module allows site builders to set up which roles can be applied for (to prevent users from getting a glimpse at roles they should never have access to), prevent or allow multiple simultaneous role requests, and so on. For site builders who want extra control, the module also provides full Views integration, as well as integration with Trigger module. You can easily build a custom administration screen to manage role applications, complete with notification emails.

There are a few noticeable gaps in Apply For Role's functionality. The application form that users fill out is spartan and lacks any explanatory text; giving administrators a way to add more help text to that page would go a long way. In addition, it would be great to customize the names of the roles that are presented to applicants. Most sites' roles are never shown to normal users, so they're often named for brevity rather than clarity. Both of those oversights can be remedied with some minor hook_form_alter() work in a custom module, but it would be great to see them integrated. Even without those wish-list items, Apply For Role is a slick solution to the problem of processing large numbers of permission-change requests. If your site's user management workflow is a good match, you should definitely check it out.

*/
Aug 14 2012
Aug 14

Drupal's standard node options cover quite a bit of ground: content editors can control the publication date, author name, revision status, revision log message, "sticky" flag, published status, and front page promotion status of every piece of content! Of course, there's no way to give content editors access to just one of those options. If you want an editor to control the "published" flag but none of the others, you're out of luck. It's all or nothing, and the resulting array of checkboxes and form elements can easily overwhelm users who are new to Drupal. Unless, of course, you install the Override Node Options module...

Screenshot of administration screen

Setting up the module couldn't be simpler; a new set of permissions to control access to each of the standard node options, on a per-content-type basis. That means a site builder can give specific user roles access to a restricted content type's options without affecting the others. In addition, there's no need to bring out the sledgehammer option of Drupal's "Administer Nodes" permission for most content creators.

Screenshot of resulting change to site

While it's possible to achieve some of the same results using custom hook_form_alter() code, the full suite of node options requires quite a bit of special logic to override effectively. Override Node Options is a quick, simple solution to the problem, and it makes a great addition to a site builder's toolbox.

*/
Aug 06 2012
Aug 06

The popular Features module is the current king of the hill when it comes to bundling up Content Types, Views, and other custom configuration data for reuse on Drupal projects. Sometimes, though, a Feature needs site-specific tweaks before it's ready for prime time. Changing the API keys for external web services like Google Analytics and Disqus, for example, can be done using those modules' native configuration screen. But if your Feature module is consolidating the configuration work, wouldn't it be great to consolidate the settings forms, too? That's where Configuration Builder comes in. It allows you to build custom Drupal settings screens that can be exported and stored in a standard Feature module.

Screenshot of the Config Builder in action

Creating a new configuration screen, or altering an existing one, is clean and simple. Site builders can choose what URL their config screen will live at, as well as what permission or role will be necessary to access it. Config Builder leverages the powerful but little-known Form Builder module for the meat and potatoes work of designing the config form itself. Drag and drop addition of new form elements and re-ordering of existing ones makes things fairly straightforward; if you've ever used the WebForm module, it's leveraging the same interface tools.

By default, the forms that you've created will simply save their settings like a standard Drupal system settings form. It's up to you to write code that does something with the values. However, if you manually set the names of the different form fields to match the names of existing settings fields on other Drupal configuration pages? Voila! Your custom configuration form will begin loading and editing the same values. This means that you can create consolidated configuration forms that control specific important settings, like the Site Name or the Google Analytics API Key, without forcing users to hop from one screen to the next.

Once that's done, the custom settings forms can be saved and exported into a Feature just like your content types, Views, or custom site variables. If you'd rather bypass all the importing and exporting, Configuration Builder can also output the form you've designed as a standard set of Drupal hook implementations that can be pasted into a custom module, with no outside dependencies.

Screenshot of a configuration builder screen, exported to code

Configuration Builder may be overkill for developers who are used to slinging around custom settings forms and are comfortable embedding them in Feature modules. For site builders who want to tide up their own features, or developers working on larger multi-site platforms that need cleanly encapsulated and overridable settings forms, this module could be just what the doctor ordered.

*/
Jul 23 2012
Jul 23

Yes, yes -- Drupal's FieldAPI gives us powerful tools for modeling content, displaying it, and customizing the administrative interface for content editors. That's all well and good, but have you seen the markup that FieldAPI generates? Setting up custom content types may be a pleasure, but the tangle of deeply-nested DIV tags that results is anything but awesome. While it's possible to override that clunky markup in a custom theme, the new Fences module eliminates heavy field markup with just a few clicks.

Screenshot of Fences field options

Installing Fences results in one simple change: when you go to edit a field, you're given and opportunity to choose what sort of markup element should wrap a field's contents. Want one field's text to appear in an <h3> while another's shows up in a <cite>? No problem. If you want to change fields globally, you can also switch all of your fields to a smart, <div>-based default until you have time to manually tweak them all. The results are impressive:

Default Drupal node markup

<div class="field field-name-body field-type-text-with-summary field-label-hidden">
  <div class="field-items">
    <div class="field-item even" property="content:encoded">
      <p>Body text goes here!</p>
    </div>
  </div>
</div><div class="field field-name-field-announce-date field-type-datetime field-label-above">
  <div class="field-label">Announce Date:</div>
    <div class="field-items">
      <div class="field-item even">
        <span class="date-display-single">Monday, June 18, 2012</span>
      </div>
    </div>
  </div>
</div>

Node markup with Fences module

<div class="field-body">
  <p>Body text goes here!</p>
</div><h3 class="field-label">Announce Date:</h3>
<div class="field-announce-date">
  <span class="date-display-single">Monday, June 18, 2012</span>
</div>

Impressed? I know that I am. There are a handful of missing features that would be handy, like adding a custom wrapper tag around a field in addition to controlling the field's own markup. As it stands, though, Fences is a great tool for simplifying markup and avoiding piles of theming grunt work.

*/
Jul 09 2012
Jul 09

For Humans and Androids

Out of the box, Drupal includes many useful features that are helpful for sites where one person wears the developer, site builder, and content administrator hats all at the same time. However, some of these features could be considered dangerous when a broader group of individuals are administering a Drupal site. The Paranoia module aims to help keep your site secure by disabling places where PHP code might be executed or important data might be changed.

Installing Paranoia follows the usual steps for any other Drupal module; download to sites/all/modules, and enable it from the modules page. If the PHP module is enabled on your site, you will be warned that such content will now be "plain text" and should be audited.

PHP module and text filter is disabled

Other changes that the Paranoia module makes include:

  • Only letting user 1 (the site administrator) edit the user 1 account
  • Disabling using PHP for block visibility
  • Prevents disabling Paranoia without direct database access (or using Drush)

By default, Drupal 7 permissions tagged as being "restricted access" are prevented from accidentally being added to anonymous or authenticated users. As well, permissions exposed by other modules can be hidden entirely by implementing hook_paranoia_hide_permissions().

Paranoia is a great example of a short and simple module that gets the job done. If you're running a site where you're sharing administrative duties, consider installing it to increase your site's security.

*/
Jul 02 2012
Jul 02

Thanks to the tireless efforts of Karen Stevenson, Drupal's Date and Calendar modules can be used to build slick agendas, calendars, to-do lists, and more. One client of ours, for example, has set up a handy view of upcoming faculty trips and outings for their university. Unfortunately, one of the most useful calendar applications can remain elusive: sending users an email when something is about to happen. That's where the Node Announce module comes in. It can use date fields on a node as cues to send out email to specified addresses -- notifying authors when their nodes will be published, attendees when events are about to occur, and so on.

Screenshot of administration screen

Setting up the module is relatively simple. Each "announcement" you set up can be associated with one content type, and one Date field attached to that content type. On that date -- or a certain number of days before it, a canned email can be fired off to the address of your choice. When combined with Drupal 7's dynamic tokens, you can also create emails that include content from the nodes themselves or other site data.

Screenshot of resulting email

It's possible to wire up similar systems (and more flexible ones) using tools like Rules or custom code. In addition, it would be great if the the module supported more flexible date options: for example, sending out messages based on the publication or creation date of a node, or the "scheduled publishing" date added by Scheduler module. Those requests aside, Node Announce is straightforward module with an active maintainer and a useful feature list.

*/
Jun 25 2012
Jun 25

Out of the box, Drupal provides highly granular permissions for administration and user tasks like creating content types, posting comments, viewing user profiles, and much more. With hundreds of discrete permissions to control out of the box, it's hard to believe that there are some things administrators can't control by default. Shocking, though, it's true: quite a few of Drupal's built-in administrative pages fall under the umbrella "Administer Site Configuration" permission. If you're looking for more granular access control, you'll need to write a custom module and cosy up to the hook_menu_alter() function... or download the Custom Permissions module.

Screenshot of custom permissions administration screen

As one might expect from its name, Custom Permissions doesn't hard-code an explicit list of permissions when it's enabled. Instead, it provides a settings screen where administrators can enter the paths individual pages (or groups of pages) that they want to limit access to. You can enter the name of the permission, a list of paths (including wildcards if you'd like to control a path and all of its sub-pages), and... that's it! Once you've configured your list of permissions and the paths they control, the permission names appear on the normal Drupal permissions administration page.

Screenshot of resulting change to site

Custom Permissions is a simple, streamlined module that does what it says on the tin. While it's possible to use hook_menu_alter() in your own custom module to accomplish the same goal, it's another option to eliminate custom code with minimal overhead.

*/
Jun 18 2012
Jun 18

Drupal's user account system may not be flashy, but it gets the job done. User logins, email notifications, secure password resets... It covers all the basics, and third-party modules like Mollom can even add CAPTCHAs during account creation. What happens, though, if you want to add a bit of extra security to the user login process and the critical "password reset" function? That's where Security Questions comes in. It adds user-selectable security questions to each user account, and uses them to provide an additional layer of authentication.

Screenshot of administration screen

Setting up Security Questions is pretty simple. It comes pre-populated with a list of a dozen or so standard security questions like "Mother's maiden name" and "Your first pet." Administrators can choose how many security questions a user has to choose and fill out when creating their account. In addition, administrators can choose when the security questions are used. You can require that users answer their security questions when resetting their account password, for example, or go all-out and require that they answer at least one of them every time they log in. It even supports an optional "remember me" checkbox: when that feature is turned on, users only have to answer their security questions every n days or weeks, rather than every time they log in.

Screenshot of the user's edit form

They may not be the flashiest feature on a web site, but simple tools like good security questions can help keep user accounts secure. The Security Questions module makes adding and tweaking the operation of them extremely simple; if you're considering adding them to your site, check it out!

*/
Jun 11 2012
Jun 11

Drupal's comment module gracefully handles anonymous posters when they want to leave messages. Administrators can choose whether those comments are left unattributed, whether anonymous commenters must leave personal information like a name and an email address, and so on. When it comes to full-fledged Node content, though, Drupal's a lot less flexible: the authors of anonymously written posts show up as "Anonymous," and you'd better like it. Fortunately, fixing that problem is the purpose of the Anonymous Posting module!

Screenshot of admin page

Setting up the module is painless; just visit its settings page, choose which content types should use its expanded Anonymous Posting options, and double-check to make sure anonymous users have permissions to create those content types. Once you've done that, a special set of options will appear on that content type's settings form. They're the same options that normally apply to comments, transplanted into the world of nodes.

Once you've set it up, usage is a no-brainer. Authenticated users will be able to create nodes just as they did before, but anonymous users preparing to author a post will see a Comment-module style list of personal information fields. Name, email, and home page are all supported. The result? Easy anonymous posting, complete with "Unverified" next to the author's name to prevent visitors from impersonating registered users of the site.

Screenshot of an anonymously authored node

Anonymous Posting is available for Drupal 6 and 7. It's simple, streamlined, and because it still relies on Drupal's normal content authoring permissions it doesn't complicate the site permissions and security unnecessarily. Considering the potential for abuse of anonymous content creation, it's probably a good idea to combine this module with an anti-spam tool or a content moderation system.

*/
May 28 2012
May 28

Drupal's content modeling tools are unmatched in the open source CMS world: CCK and Drupal 7's FieldAPI give site builders a remarkable amount of control over every content type, its fields and properties, and how they're edited and displayed. Except, that is, for the Title field. Some content types, like links to other web sites or quotations, don't lend themselves to catchy titles; displaying the primary content underneath an additional title can sometimes dull the impact of the node's the primary information. That's where the Exclude Node Title module comes in.

Screenshot of administration screen

Once the module is enabled, it adds a centralized settings form that allows you to configure each content type on the site. For each one, you can choose whether to hide or show the title, which display modes should keep it hidden, and whether the display option should be controlled on a node-by-node basis by the author of each piece of content. When the affected nodes appear in listings like the front page or standard Views, voila: no node titles!

Screenshot of resulting change to site

If you've ever performed this trick yourself using theme preprocessing hooks, you'll recognize what's going on: Exclude Node Title module module is just removing the 'title' element from the rendered output of a node, and when it hits the node HTML template, there's nothing to print. The difference, of course, is that using a dedicated module allows you to drive the behavior entirely using configuration settings, rather than custom code in your theme or a site-specific module.

The only hitch I could find is that the option to hide a node's title on the edit form doesn't seem to work. The title is hidden on teasers, full node views, and more -- but the Title field stubbornly appears on the edit form itself. If you want to make sure your nodes have some kind of title for administration screens, the Auto Node Title module would make a good companion. It can hide the Title field and populate it with a default value.

*/
May 21 2012
May 21

Fixing unserialize() woes

Ever run into errors like the following on your Drupal sites?

Notice: unserialize() [function.unserialize]: Error at offset 74 of 75 bytes in variable_initialize() (line 749 of /srv/www/<sitename>/includes/bootstrap.inc).

This is a symptom of an invalid variable in the {variables} table. When the Drupal cache is cleared (or variable_set() is called), Drupal queries the variable table for all site settings and saves them in your cache for quick access. If you're getting errors like the above, odds are your variable table contains a corrupted or unserialized value.

So now that you know what the problem is, how do you solve it? For larger sites there can be hundreds, if not thousands of variables in the {variables} table. Finding the broken value can be time consuming and difficult.

Once the Variable Check module is installed, a new report is added to the Reports section in the site administration.

Invalid Variables administration screen

As we can see, Variable Check is correctly identifying an invalid string length, an unserialized value, and a missing quote from a string value.

Variable Check also adds an entry to the site status report, alerting site administrators if any invalid variables are ever added to the site. Note that Variable Check will only find variables that fail to unserialize; it can't detect variables that are syntactically correct but logically incorrect (such as a string that a module expects to be an array, or a TRUE that should be FALSE for your site).

Once a broken variable has been identified, the variable can be deleted in the user interface or with drush vdel. Or, drush can be used to correctly reset variables.

$ drush vset site_name "Kitten Emporium"

May 07 2012
May 07

It's the little details about a web site that make you smile when you're finished building it: the subtle CSS effects, the way it intelligently pre-populates forms for you, the great organization of a complex content model, and the just-so text copy that makes things feel "right." That's why little details can be annoying, too. Take, for example, the names of multi-value FieldAPI fields on a Drupal content type. You can label a field 'Photos,' for example, but what if an editor only enters one? Somewhere, a copyeditor is grinding their molars over that one, but a convenient little Drupal module can save the day: Field Label Plurals.

Screenshot of administration screen

Setting up the module is, as one might expect, pretty straightforward: turn it on, then visit an existing FieldAPI field configuration screen. You'll see a new option just below the field's normal Label: a Single-Value label. Set up both labels to match the proper pluralization rules, and the module handles the rest.

Screenshot of resulting change to site

When a multi-value field is displayed to a site visitor, the label will change intelligently based on how many values have been added to the content item. There is a hitch, of course: in some languages, there are multiple "plural forms" of a given word rather than just one. If you plan to translate your site into one of those languages (like Arabic and Polish), this module won't be able to account for all of those forms. If you're comfortable sticking with a boring old language like English, though, Field Label Plurals can definitely add an extra bit of verbal polish.

*/
Apr 30 2012
Apr 30

In a perfect world, every Drupal module would come with online documentation and support Earl Miles' Advanced Help module for in-depth instructions. In that same perfect world, ever site builder and administrator would read the INSTALL.txt and README.txt files that ship with complex modules before trying to install them. Alas, neither of those dreams is likely to become a reality anytime soon. In the meantime, there's Module Instructions -- a simple one-trick-pony that puts the contents of Readme and Install files right on Drupal's module administration page.

Module Instructions additions to the module administration form

There's not much to say about the interface: when you visit the module administration page, Module Instructions scans each module's directory, hunting for install or readme files. if it finds them, it adds links to that module's line on the administration form. It's simple, it's effective, and while it isn't of much use on a production web site, it's a great tool to have when you're experimenting with new modules or sorting out the installed modules for an in-progress site. (The editor of Module Monday, for example, feels the acute pain of installing dozens of modules for testing purposes. Anything that consolidates their documentation is a good thing...)

Module instructions displayed inside of an Overlay window

If you're a developer interested in customizing Drupal 7's module administration form, Module Instructions is also a useful example of how to alter and bend that notoriously complex administration page. It doesn't interfere with the normal documentation or configuration links used by Drupal core, and plays nicely with other administration-page tweaks like Module Filter.

*/
Apr 23 2012
Apr 23

Building a 'Frequently Asked Questions' page in Drupal is simple -- once you've picked the approach you want to take. Give content editors a simple 'Page' node, and hope for the best? Drop in a pre-fabricated 'FAQ' module and configure it? Add a 'FAQ Entry' content type and build a view to list them? All have been done, and all can work -- but now there's one more way to tackle the problem... FAQ Field module.

FAQ Field administration screen

Like most FieldAPI based tools, configuring the module is simple. Just add a 'FAQ Field' to the content type of your choice, and remember to specify 'Unlimited Values' for the field. When editing nodes of that content type, content creators will be able to add any number of FAQ entries, each with its own 'Question' and 'Answer' text. The module also ships with a handful of custom formatters to display the FAQ information. The simplest lists each FAQ as a header and paragraph; the 'Accordion' style displays questions, expanding each one to display the answer when it's clicked.

Screenshot of FAQ fields in action

Should you use the FAQ Field module? If your site has a single, simple FAQ page it's probably overkill. If you need to display FAQ-style documents in numerous places (for example, maintaining one for each product in a site's catalog), this module's approach really shines. Check it out, and consider adding it to your site-building toolbox!

*/
Apr 17 2012
Apr 17

Oh, scrolling multi-select form elements. Does anyone really like them? Picking multiple items from one of these widgets often requires option-control-alt-clicking your way through a long list, hoping you don't accidentally deselect the options you've carefully chosen. Drupal's default Select Widget allows you to use convenient dropdown select menus to choose the contents of single-value fields, but if you have a multi-value field, you're out of luck. Wouldn't it be great to give content editors a list of several single-select dropdowns, rather than the unruly multi-select box? It would, and that's precisely what the Multi Selects module does.

Screenshot of Multiple Selects being added

Like many cool Drupal 7 tricks, Multiple Selects is a field editing widget that can be used with multi-value list fields like Text and number lists, as well as taxonomy term references. No configuration is necessary -- just set the field's widget to "Multiple Selects," and you're ready to go. Rather than a single scrolling multi-select box, content editors will see single-select dropdowns, with the traditional FieldAPI 'Add another item' button below.

Screenshot of Multiple Selects in action

In addition to providing a slightly cleaner editing interface, this approach allows editors to choose the order in which their field values appear. Adding five taxonomy terms and then dragging them into the correct order is impossible with a multi-select box, but works fine once Multiple Selects is enabled. The only downside is that it doesn't support node, user, or entity reference fields yet. That addition is a minor change, though, and a patch to add it has already been posted. If you're looking for a simple multi-value select widget that also gives your editors control over the order of the values entered, look no farther than the Multiple Selects module.

*/
Apr 09 2012
Apr 09

Who hasn't had to build a content slider at some point? There's a huge number of Javascript plugins and Drupal modules out there to help us do just that. Enter into the ring Flexslider, a fully responsive (try resizing your browser window) jQuery slider plugin that utilises simple and semantic markup. It's supported in all major browsers, is very customisable with its Callback API and navigation options and also has hardware accelerated touch swipe support.

flex.png

You can configure your Flexslider options through the UI and also export them using CTools Bulk Export or Features.

Edit Flexslider option set screen

Usage of the slider is typically through one of the support modules included in the project. This includes Views Slideshow support, a field display mode and a Views style plugin. You can also call the Flexslider directly with flexslider_add().

The Drupal Flexslider module version 7.x-1.0-rc2 was just released and it's currently in use on nearly 1000 sites.

*/
Apr 02 2012
Apr 02

Drupal's much-loved Date and Calendar modules are great for storing and displaying calendar-style dates, and can store "time of day" information for extra precision. If you're trying to store a different kind of time, though -- say, the length of a song or the number of minutes in a video -- the Date module is an awkward fit. That's where the HMS Field module comes in.

Screenshot of HMS Field in action

Instead of storing an absolute date and time, HMS Field (short for 'Hours, minutes, and seconds') stores a simple integer representing a number of seconds. The field widget it ships with lets you enter a number like "5:45," while the field formatter allows you to display it in a similar style. There's not much to explain beyond that point -- HMS Field, as the Brits say, does what it says on the tin. It's easy to sort and filter Views based on the field's values, and writing custom display formatters for the field is relatively simple.

Screenshot of the HMS field configuration

The only downside to the module is the relatively limited display formatter it ships with. It's great for displaying the hours, minutes, and seconds that are stored, but it doesn't support natural language output like "10 minutes" or "4 hours." Even without those options, however, HMS Field is a great addition to any site builder's content-modeling toolbox.

*/
Mar 26 2012
Mar 26

Oh, multiselect form elements. When you need to display a long list of items and users can pick from several of them, they're the only way to go. Why can't they be prettier, though? Why can't they be easier to use? Why can't users select things in them without endlessly scrolling and holding down the control key? The standard HTML multiple-selection element leaves a lot to be desired, if you're looking to spruce it up, check out the new Improved Multi Select module.

Screenshot of an enhanced multiselect form element

Using Improved Multi Select is straightforward: install it, configure it, and any multiselect form elements on your site can be replaced by a handy two-pane "mover" interface that lets users keep track of what they've selected. In addition, it provides a simple search/filter mechanism: type a letter or two, and only the entries containing those letters will be shown. It's nothing fancy, but it can really speed up the process of picking entries from a long list. Since the entire widget is powered by jQuery and CSS, tweaking its appearance to match your site is relatively straightforward.

Setting up the custom widget is a bit of a change if you're used to FieldAPI widgets. Rather than providing a custom widget or form element, this module implements its picker using only jQuery and CSS. On its configuration screen, administrators can choose the URL paths or CSS selectors it should use to determine which multiselect form elements should be enhanced.

Screenshot of the module's configuration screen

The Lullabots are divided on this approach: On the one hand, it means that you can't explicitly choose the enhanced selection widget when building a new form or content type the way some site builders did with the venerable Multiselect module. On the other hand, the technique used by Improved Multi Select can easily be layered on top of any form or FieldAPI widget, even if it wasn't initially designed to take advantage of the swanky jQuery enhancements. Check out both modules if you're uncertain: either one will give some extra polish to your site's administrative forms.

*/
Mar 12 2012
Mar 12

When you're building a social site, one basic question always comes up: are users allowed to edit content and comments after they're posted? If they aren't, typos and simple errors quickly turn into huge annoyances. But if they can edit their posts after they're seen by other users, hijinks are inevitable. Write an incendiary comment, wait until angry people respond, then alter the original content to something innocuous. Voila! Instant flame war.

Ideally, you'd be able to give them a window of time in which edits can be performed (to fix typos or correct errors), then lock the content once other people are likely to have read it. Fortunately, that's exactly what the Edit Limit module adds to Drupal.

Screenshot of administration screen

Setting up Edit Limit is straightforward: install it, turn it on, and hit its settings page to determine which content types it applies to. Then choose how long users have to make edits after posting a piece of content. That's it! You can also choose to limit them to a specific number of edits rather than a specific timeframe, useful to allowing a single edit to fix typos, rather than lots of small revisions. The same rules can also be applied to comments, although the setting is global: you can't set up rules for comments on Articles while leaving comments on Events unrestricted, for example.

Screenshot of Edit Limit in action

Edit Limit has a few rough edges, including odd verbiage in its messages to the user. The amount of time they have left before a node is locked? It gets displayed in seconds rather than hours or minutes. Many of its options would also make sense on the content type editing form, rather than a single central configuration screen. Even with those issues, Edit Limit is a simple, useful tool that gives site builders a bit more flexibility when planning a site's interaction model. If you're a developer with a bit of time on your hands, submitting a patch to fix the issues would take the module to the next level!

*/
Mar 05 2012
Mar 05

Most complex Drupal sites eventually accrue a few... oddball content types. Sometimes it's a collection of ad nodes that should only appear in a rotator, other times it's special nodes that are only used when constructing a user's profile page, and many times it's impossible to predict until the site is complete. No matter the details, it's often useful to mask the normal node/1 URLs for those "ugly duckling" content types to ensure users don't stumble onto them accidentally. Unpublishing them entirely can be a pain, though, complicating Views and permission management. Enter... Rabbit Hole.

Screenshot of administration options

Rabbit Hole is a curiously named module that lets you control the behavior of the node view pages for each content type. Pop open the administration page for each content type, scroll down, and you'll see options to leave it as is, mask it entirely and generate a 404 error, or redirect to a different Drupal path or URL. Administrators can be given permission to override these redirects, viewing the normal node pages for these content types while users see the redirect or 404.

The only downside to Rabbit Hole is its lack of support for tokens in its per-content-type redirect paths. There's no way for the node/1 path to redirect to the user page of that node/1's author, for example. Adding token support would allow tricks like that, but even without that the module is a useful addition to any site builder's toolbox. Writing the same functionality in a custom module is a common task on most large sites, but Rabbit Hole. solves it for everyone. Give it a spin!

*/
Feb 27 2012
Feb 27

Drupal's permission and access control system allows you to carefully control what functionality and content can be seen by different classes of users. Sometimes, though, your carefully constructed access rules can be a hindrance. What happens when you want to give just a few users temporary access to areas of the site that are normally off-limits? Letting your boss preview a new feature with a throwaway account can be useful, for example, but keeping track of those temporary accounts and ensuring that you clean them up when they're no longer needed can be a real pain. Guest Pass module solves that problem by giving privileged users the right to invite and manage special time-limited "guest accounts."

Screenshot of Guest Pass creation

Setting up Guest Pass is straightforward: drop it in, install it, and choose which user roles have the right to create new guest passes. On nodes that they own, these users will see a special "Guest Pass" tab: on it, they can create new passes by entering an email address and invitation message. The module generates a unique invitation URL and sends off an email. Once the recipient visits that URL, a fresh new Drupal user account is created for them automatically, they're granted the "Guest" user role, and redirected to the node that the guest pass was created for. Using Drupal's permissions system, you can control what content and site features those guests are able to use.

Screenshot of Guest Pass invitation email

The global Guest Pass settings page allows administrators to control which content types guest passes can be used with, the verbiage of the default invitation message, as well as the mechanism for cleaning up old guest accounts. The users who created each guest pass can go back and delete the passes (and their matching guest accounts) manually, but the module can also clean up old guest passes every few days.

Screenshot of Guest Pass administration options

The module does have some idiosyncrasies. Although guest passes are created and associated with specific nodes, they do not have any connection to per-node access controls. Every guest user who receives a pass will have the same access permissions, so there's no way to give one guest access to one node while keeping it hidden from another. It might make sense to decouple the creation of guest passes from the node page entirely, or to use Drupal 7's more robust access controls to give Guests special access just to nodes they received an explicit invitation for. In addition, there's no easy way for a user to "upgrade" a guest pass to a full user account if they want to stay. That's no problem for temporary previewing, but it makes it less useful as a tool for inviting potential new users.

Those issues aside, Guest Pass is a great tool for giving specific trusted people time-limited access to special areas of your site. Check it out!

*/
Feb 20 2012
Feb 20

Since version 2.0 of the Views module shipped back in 2008, site builders have been able to use its Exposed Filters feature to create slick user-filterable lists without writing a lick of code. Unfortunately, complex views with lots of exposed filters can easily become cluttered -- some filtering options only make sense when others are also selected, for example. Views Dependent Filters solves that problem, allowing to hide and show exposed filters based on other filters' values.

Screenshot of dependent field configuration

Configuring the module is a bit opaque: using it requires adding a "Global Dependent Filter" to your existing view, then positioning it between the two exposed filters whose behaviors should be linked. For example, you might add an exposed Content Type filter, then the Global Dependent Filter, then an second exposed filter that's only applicable to one of the content types. The Dependent Filter's configuration options will allow you to choose which values from the first filter should hide or show the second exposed filter.

Screenshot of resulting change to site

Once the filter has been set up, Views Dependent Filters does what it says on the tin. Exposed filters appear and disappear automatically, and your complex view gets simpler.

Developers familiar with Drupal's FormAPI and the new States system will recognize what's going on under the hood: the same tricks can be done in a custom module with careful use of hook_form_alter(). Using Views Dependent Filters, though, means that the visibility tweaks are an inherent part of the view, and can be exported and saved cleanly. If you're looking for a way to simplify complex, user-filterable views, check it out!

*/
Feb 13 2012
Feb 13

If you've ever needed to assemble an iPhone or iPad-ready Drupal site on short notice, you know that it's easy to miss some of the details. Once you've finished a responsive design and figured out how to avoid burying mobile users in heavy images, it's easy to forget the high-res Web Clip Icon used by iOS when a user saves your site to their device's home screen. Without one, a squeezed-down screenshot of your site will be displayed on their home screen. It's possible to hard-code a Web Clip Icon into your theme's markup, but with the Touch Icons module, it's as easy as uploading a custom favicon or logo image.

Screenshot of administration screen

Installing and enabling Touch Icons adds two additional checkboxes to every theme's settings page. Like the Favorite Icon and Site Logo options, activating them lets you upload a custom image file that should be used as your site's iOS home screen icon. That's it -- there's nothing more to configure or set up!

Screenshot of a site's touch icon

Technically, nothing prevents you from customizing your site's theme and embedding these touch icons yourself. If you're using an out-of-the-box Drupal theme, however, it's easy to forget. If you need to add a bit of extra polish for iOS users, this is an easy way.

Touch Icons is simple and problem-free based on our testing, but only the Drupal 6 version has an "official" release available for download on Drupal.org. The Drupal 7 version of the module is only available as a "developer release." If you're interested in helping maintain the module or want to keep track of its status for Drupal 7, check out the module's issue queue.

*/
Jan 30 2012
Jan 30

Whether you're building a Delicious-style link archive or a personal portfolio site, Drupal's Link Field is a great solution for storing user-entered URLs as part of a node. If you want to display something more visual than a URL, however, things get tricky. Third-party thumbnail generation services can create screenshots of URLs, but most rely on clunky client-side scripts to layer the thumbnails on top of your design. The Pagepeeker module offers a slick alternative: it leverages an up-and-coming thumbnail service to generate site screenshots without any Javascript code.

Screenshot of PagePeeker setup

Setting up the module is simple: create a Link field, then select the PagePeeker display formatter. You can choose from several thumbnail sizes, or pull in the 16x16 Favicon for the linked URL. If you're working with links that aren't stored in FieldAPI fields, the module also provides a helpful theme function. Just toss a URL at it, specify the size of thumbnail you want, and it will output a linked image tag.

Screenshot of PagePeeker in action

If you're looking to set up a link-heavy site, and need an easy way to generate thumbnails without taking screenshots manually, Pagepeeker is a great tool. Its long-term health will depend on the health of Pagepeeker.com -- the third-party service it uses to generate the thumbnails. Other services like Websnapr have had similarly flexibly systems in the past, but now force users to choose between client-side script solutions or premium plans. For the time being, Pagepeeker.com is working great and this module is the slickest, easiest way to get it working on your Drupal site.

*/
Jan 16 2012
Jan 16

Back in the olden days of Drupal 5 and 6, the venerable CCK module came with a useful add-on: Content Copy. While it had rough edges, Content Copy allowed you to export a given content type and all of its custom fields into a snippet of PHP. The same module could be used to import that snippet of PHP code on another site and re-create the content type, with all of its settings and custom fields.

Sadly, that feature didn't make the cut when the CCK module became Drupal 7's built-in FieldAPI. While the Features modules has eclipsed Content Copy for serious site deployment, sometimes it would be handy to have the same easy "Export, save, and reuse later" option in Drupal 7. Enter Bundle Copy, the successor to Content Copy.

Screenshot of the Bundle Copy export screen

Like is ancestor, Bundle Copy is pretty straightforward: visit Content Types administration page and click the Export tab, then choose the content types you want to export. Pick the individual fields, submit the form, and voila -- a pile of PHP that can be saved to a text file, and re-imported to another site running Bundle Copy. The module also supports the new entity types that ship with Drupal 7: Users and Taxonomy Terms. If you've heavily customized user profiles with Drupal 7's FieldAPI, it's a quick and easy way to share the tweaks.

Screenshot of the Bundle Copy import screen

Although the Features module is a great solution for full-fledged deployment of Drupal configuration, it carries its own list of module dependencies. If you're simply trying to share some quick tweaks to a content type with a friend, or you'd like to move a content type from one of your sites to another without the overhead of a dedicated Feature module, Bundle Copy is worth checking out.

*/
Jan 09 2012
Jan 09

CCK in Drupal 6 and FieldAPI in Drupal 7 give site builders a variety of structural and formatting options for carving out new content types. Multi-value fields in particular allow a node or other content element to store lists, collections of links to taxonomy terms, and more. The downside, of course, is the formatting: by default, Drupal's HTML output for multivalue text fields is a big old bag of DIVs. Taxonomy fare a bit better: they're output as proper HTML lists, a semantically proper approach. Both still require considerable CSS wrangling if you're interested in displaying multiple values simply, however. And that is where the Text Formatter module comes in.

Screenshot of administration screen

Text Formatter is a simple CCK/FieldAPI formatter for Drupal 6 and 7 that outputs multi-value text and taxonomy fields as comma delimited lists, or customizable HTML lists. It can do a few other fancy formatting tricks, as well: the last item in a comma-delimited list can be preceded by a grammatically correct 'and', and comma-delimited lists can be closed with a period. Ordered and unordered lists can also be chosen, and a custom CSS class can be specified for a particular list if you're interested in targeting special CSS rules or JavaScript behaviors. The module even allows you to format single-value long text fields as lists if they contain multiple lines of text.

Screenshot of Text Formatter in action

Text Formatters was originally part of the much older "CCK Formatters" module. Its list formatting options were by far the most popular, and were split out into a separate module for ongoing maintenance. The module is stable, trouble-free, and does just what it promises. If you need to whip a few multi-value fields into shape, check it out!

*/
Dec 26 2011
Dec 26

Here at Lullabot Headquarters, we try to make sure that each week's Module Monday article highlights a lesser-known tool that's simple, useful, and efficient. In honor of the holiday season, though, this week will show off a Drupal module that's 100% fun: Konami Code!

If you played video games in the 80s, you might remember the infamous secret code that could be entered on the first screen of Contra and other games produced by Konami. An entire generation of gamers learned that up-up-down-down-left-right-left-right-b-a was the key to eternal life, and more recently the code was the key to activating east eggs on web sites like Facebook.com and Marvel.com. Now, thanks to the Konami Code module, you can hide the easter egg of your choice on any Drupal site using the same key combination.

Screenshot of the Konami Code module's configuration screen

The module sports a staggering number of configuration options, most centered around what should happen when visitors to your site enter the code. Would you like to redirect them to another URL? No problem. Would you like jQuery-powered snow to fall on the page, turning your site's design into a winter wonderland? Easy. Covering the page with bacon, launching an in-browser game of Asteroids, and popping up an alert box containing custom text are all easy to do with the module. You can also customize the exact key commands used to trigger the easter egg.

Screenshot of Drupal content experiencing heavy precipitation, thanks to the Konami Code

Hiding a secret picture of a unicorn on your web site and activating it with the Konami Code may not be mission-critical functionality, but it's a traditionally nerdy way to sneak some light-hearted fun onto a small site. Check it out -- and enjoy the holidays!

*/
Dec 19 2011
Dec 19

Keeping visitors to your site reading and clicking (and -- let's be honest, viewing ads) once they've finished an article can be challenging. Often, lists of related articles or hot news are embedded at the end of each article to provide readers with an easy "next step," but these can easily be lost in the noise of a dense footer or link-heavy site. Enter Slidebox, a svelte module that uses interesting jQuery tricks to prompt users who've finished an article with a smoothly animated link to another one.

Screenshot of the Slidebox module in action

Setting up Slidebox is a snap: just turn it on, tell it what node types its "Next article" box should appear on, and you're ready to go. While it's possible to tweak the values that control how long the Slidebox animations should take, the defaults it ships with are sensible. The magic happens once you pop open a node and scroll to the bottom of its content: a tidy little box slides out from the right side of the window, prompting you with the title of the "Next Article." It's simple, attractive, and easy to dismiss. Also, because it appears when the user scrolls to the end of the node content, not the bottom of the page, it doesn't require that readers wade deep into a crowded site's footer or other "below the fold" content to see the link.

Screenshot of Slidebox settings

Slidebox's settings are currently pretty sparse: there's no way to exercise more control over what list of nodes should be used to find the next article, and you can only customize the contents of the "Next Article" box by cracking open theme template files. There's a lot of interest in the issue queue around turning the module into a more API-driven tool that supports Views and other entities, however, so keep a close eye on how it evolves. For now, it's a clean and simple tool that does one thing and does it well!

*/

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web