Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Nov 12 2012
Nov 12

How to Hide Metadata From Showing on a Published Drupal Page

Drupal's FieldAPI gives site builders a wide variety of ways to attach custom data to content types and other entities. Sometimes, though, you're adding metadata -- stuff that shouldn't be displayed directly when a piece of content is shown, but can affect the content's relationships with other posts, or its overall appearance. The easiest way to do this yourself is to hide the field in question, then sneak extra CSS classes or IDs onto the node itself based on the field's value. A new module, Field Formatter CSS Class, automates that process and makes turning simple fields into extra CSS classes a no-brainer.

Screenshot of administration screen

As one might guess from its name, the module adds a new FieldAPI Formatter type -- "CSS Class." When selected, the field in question doesn't appear in the visible content of the node or entity in question. Instead, the field's value is turned into a CSS class and added to the entity's wrapper div. This is most useful when combined with a List field or a Text field with a small number of allowed values. When combined with some simple CSS rules in a custom theme (or added via a module like CSS Injector), this allows content editors to make easy choices that affect a node's visual appearance without hacking complex markup or embedded CSS rules into the content itself.

Screenshot of resulting change to site

Field Formatter CSS Class is also smart enough to sanitize the CSS classes that it adds -- even if you allow editors to enter custom text in a field, dangerous HTML attributes and CSS tricks will be scrubbed out. If you need a quick and simple way for editors to pass information about a node or other entity to the theme, Field Formatter CSS Class is a solution worth checking out!

*/
Oct 09 2012
Oct 09

In the first episode of Insert Content Here, Jeff Robbins and I chatted about the temptation and the danger of the "Dreamweaver Field" content model. When content types are just wrappers around giant chunks of hand-formatted HTML, editors have lots of flexibility but it's all but impossible to repurpose the hard-coded content for new designs and publishing channels.

In presentations, articles, and her upcoming book, Content Strategy for Mobile, Karen McGrane describes the problem as a war of "Blobs" versus "Chunks." The challenge is figuring out how to decompose a site full of inflexible HTML blobs into discrete, bite-sized fields. There's no magic bullet (a model that works for one project can fail miserably for another), but over the past several years we've accumulated a few useful rules of thumb for "deblobbing" a site's content.

The Basics

Don't skimp on the content inventory and auditing process. Figure out what's there, what's going to be tossed, and what you want to have on the site. This is step zero, really: the modeling process is infinitely harder if you're dragging around piles of HTML that don't match what your're trying to build.

Clump similar content. If your existing site doesn't have discrete content types, figuring out which pages are similar to each other is the next stage. Product reviews, staff bios, press releases, blog entries, portfolio slideshows… You know the drill. Remember to look for pages and content types that are really composites of other, smaller units of content. Often, some of the most complex pages and content types can be implemented as rule-based or curated collections of smaller, more management content types.

Look for common "chunk" types. Once you've grouped your blobby content types into similar pools, zoom in and look for patterns that are unique to each content type. These are are potential candidates for dedicated fields. Some of the common field types we encounter include:

  • Links to related content
  • Links to downloadable files and embedded media that occur at consistent locations
  • Publication or event dates
  • Pull quotes, hand-written taglines, author bios, and summaries
  • Business and event addresses
  • Geographical locations and maps
  • Lists of information like features or rules and requirements
  • Ratings, prices, and product codes

Most CMS's support multi-value fields that can be used to model repeating elements like feature lists or multiple file attachments. Be sure to note which elements occur once, and which ones repeat.

Rinse and Repeat. Once you've broken things into multiple content types and identified the discrete fields on each one, look for overlaps. Are there several content types that share the same list of fields? Consolidating them into a single type might simplify things. Is there one "Godzilla" content type with dozens and dozens fields? It might really be several types that should be teased apart. The first pass of a content model is a lot like the first draft of an essay: there are always rough edges and awkward parts that need work.

The Tricky Bits

After identifying all of that easy stuff, large and complex sites usually have quite a few ugly blobs that still need to be broken down.

Identify composite content. Sometimes, elements of one content type need to be broken out into their own sub-content-types, with simple parent-child relationships connecting them. Galleries that contain multiple photos, albums that contain multiple songs, and curated pages that include teasers for other content are common examples. If several content types in your model contain the same cluster of fields (like photo, caption, byline, and link, consider splitting out the cluster into a its own dedicated content type. Treating those scenerios as relationships between discrete elements can often simplify complex models.

Look for common formatting complexities. If you have wireframes or existing pages, look for complex visual formatting around certain elements, in particular the stuff that requires lots of hand-written HTML to implement in a "content blob." Comparison tables are a common offender here. Breaking these out into dedicated fields whenever possible can help prevent massive pain when a piece of content needs to be displayed differently in new channels.

Watch for design elements that change based on context. If you're building a responsive or adaptive site, or have access to designs for mobile apps or other output channels, keep an eye out for elements that appear differently or conditionally based on breakpoints, target device, and so on. It seems obvious, but controlling small elements is infinitely easier when they're broken out as discrete fields.

Plan for searching and filtering. Try to identify as many different filtered lists of content as possible. Faceted search screens, topical landing pages, author-based blogs, product lists, and so on can't be built efficiently without the right data. If the lists and search indexes that you need don't correspond to fields you've already broken out, remember to add additional ones for the required metadata.

Isolate the crazy. Inevitably, complex designs end up requiring "helper" content that doesn't seem to fit the well-understood content types the site's stakeholders imagine. Slides for promotional rotators, free-floating promotional microcontent for landing pages… These tend to be highly variable and often need the kind of raw-HTML flexibility that we're trying to avoid. Isolating them in their own content types and living with the cordoned-off craziness can help simplify models with overloaded, field-heavy primary types.

Recognize when markup is good enough. Despite all the talk about the dangers of blobs, it is possible to go too far. Replacing every HTML div and span with a dedicated field simply to avoid raw markup is overkill, and can easily result in 'Edit Screens of Doom.' Modern WYSIWYG editors generally support plug-in systems, and developing a button to "insert caption here" or "style paragraph as warning" can be a simpler solution. This is where I repeat the warning: There's no perfect content model, only the one that works for your project.

Test the Model

The long-term impact of a bad model on a site's maintainability can be frustrating, but it's also impossible to predict every future application the content will be used for. Iteratively testing the model against real-world content and potential applications is critical.

Put real content into the model. It seems obvious, but it's easy to go down the structural rabbit hole and forget the existing pool of content. Circle around frequently and ask, "How does the content we have in hand fit into these content types and fields?" Look for odd mismatches, required fields that the existing content will leave unpopulated, and so on. Sometimes, the design and the model have to change for practical reasons. Other times, clients or your team will have to update the content to close the gap.

Plan for three channels. When building a model (or a software API), it's easy to imagine you're creating a reusable system while unintentionally baking in assumptions that make real reuse difficult. If you need content that will adapt to reuse in new channels, be sure that you keep at least three in mind -- think of them as user personas for the model. Desktop web, small-display devices, and rich HTML newsletters are common answers for some businesses. Even if you're only building one of them at first, proposed approaches can be compared against them to ensure you aren't painting yourself into any corners.

Social sharing is a publishing channel, too. Twitter and Facebook can automatically embed headlines, summaries, and preview images when users paste one of your site's links -- if you provide the metadata that they're looking for. If your model doens't account for those, it will be much tougher.

Let real users work with it. If you're using a web framework that allows rapid creation of a content model before the full site is finalized, or you can produce wireframes of some sample content input and editing screens, get user feedback sooner rather than later. The people who spend their time creating and maintaining the content can often spot problems and inconsistencies that would otherwise remain undiscovered until launch.

No Rules, Just Lessons

None of above ideas are hard-and-fast rules, obviously. At Lullabot, we've spent years building out complex sites (and the underlying content models) for media publishers, government agencies, corporate intranets, ecommerce sites, and more. And yet, every new client comes with surprises and challenges.

In the coming months, I'll be digging deeper into each of these ideas with follow-up articles and interviews on Insert Content Here. In the meantime, what useful heuristics do you use when breaking down ugly "content blobs" into reusable chunks? Feel free to chime in with comments!

Sep 14 2012
Sep 14

Listen online: 

We've got rhythm! We've got music! In the innaugural episode of Insert Content Here, Jeff Eaton and Jeff Robbins discuss the meaning of Content Strategy, reminisce about the dark days of Dreamweaver, and introduce a dazzling new jingle.

Release Date: September 14, 2012 - 2:00pm

Album:

Length: 38:59 minutes (20.93 MB)

Format: mono 44kHz 74Kbps (vbr)

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.

*/
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.

*/
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!

*/

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