Drupal content management I: Improving the node form

The basics: get rid of some clutter

A common Drupal disease is unused functionality taking up precious screen space in the admin interface, but this is always possible to switch of or hide, one way or another. The first thing to do is to make sure you only have the modules that you actually need activated. If you don't need the Upload module for instance (maybe because you use the more flexible FileField instead), disable it!

The second fundamental thing to understand is permissions. When you first install Drupal and log in for the first time, you become user #1 – the all mighty super user who always have permission to do anything that the system allows. This is good for when you're building a site, but it's not very user friendly (or secure) to use in the day-to-day business of a website since this user is exposed to more functionality than is usually needed. With Drupal's permission system you can control which of these features you present to your users and which you don't.

Step one is, create a user role which will be used by whoever is going to handle the content of your site. Then, go to the permissions page and grant the role permission to add, edit and delete all, or only the users' own, nodes of the types you choose. Avoid the "Administer nodes" permission for unexperienced users, as it adds several fieldsets to the node form, and only use the revision related permissions if you really need that feature.

Now, a common problem is that the "Administer nodes" permission encapsulates a lot of little things that some users might actually need, like setting the Published status or changing the author of a node. You may want to allow certain roles this ability for certain node types while not allowing them unlimited access to all nodes. The solution is the module Override Node Options which breaks these things out into their own, more fine-grained permissions.

Another permission with a similar problem is "Administer menu". Users with this permission are able to assign menu items to nodes as they are created, on all node types. In most cases you only want this feature on specific node types, such as "Page", and not have them cluttering "Story" node forms for instance. Modules like Menu Settings per Content Type and Menuless Node Type let you do this.

Restructure the node form

Now that some general improvements are done, let's move on to reorganizing the fields and options that we do want to use on the node form. There are several options available, and we'll take some time to explore them.

First, CCK comes with the Fieldgroup module, which lets you organize your content fields into fieldsets on the node form (and also on node views, if you like) which makes it easier to read complex content types with many elements. You can choose to make them collapsed (hidden) by default if the elements they contain are rarely used, which makes the form more compressed. Also, a less obvious – but very handy – way of using them is when doing custom layouts on node forms, either with just CSS or by using templates (see below). All field groups have class names added to them which provides a quick and easy way to customize their appearance.

One limitation with field groups is that it's not possible to put other fields than those created with CCK into groups; specifically the Title and Body fields are "trapped" at the root level of the form. (What we've ended up doing a couple of times is to replace the Body field with two custom CCK fields: field_teaser and field_body. This may probably involve a small performance hit, but in most cases only to a small degree.) Another limitation is that you can't create nested field groups.

Easy node form customization

A couple of modules that can improve your node forms' usability in a quick and easy way is Node Form Columns and Vertical Tabs. Node Form Columns (written by our friends at GoodOld) lets you easily organize all of the fields and options into columns and a footer region, which is very useful for complex node types. Vertical Tabs on the other hand turns some of the administrative fieldsets at the bottom of the form (like Authoring information and Workflow settings) into vertical tabs, which is good for admins who have access to many of these options.

More control: node form templates and Panels

You may still need more control over your node forms than that. Things like mixing in other content into the form, or radically changing the page structure, might make it necessary to use a custom template file. Just like you can use node template files to alter the display of different node types, it's possible to do the same thing with node form pages, using the module Node Form Template. It comes with a well-documented default template which helps you get going.

A very useful workflow with Node Form Template, which isn't obvious that you can do from reading the documentation, is to create standard CCK fieldgroups and then have the template render them as large chunks – using variables like $group_{group_name} – rather than outputting the fields one by one. (Another simple thing that's actually took some time to find was the name of the variable $body_field.)

One final approach is Panels – the ultimate work horse of genuine Drupal-style flexibility for making custom page layouts from within a web UI. With Panels, you can create custom pages with configurable rows and columns and fill everything with any Drupal content you can think of: blocks, nodes, views, fields, etc. And all of this without writing a single line of code.

And the wonderful thing is, you can not only create these pages from scratch. You can also use Panels to override other pages, such as node pages, or (you guessed it) node forms, with a panel you design yourself. This means you can create a page structure of rows and columns and apply that to a node form, deciding which fields go where, as described in this handbook page. However, like with Views, just because there's no code doesn't mean using Panels is easy. Expect to spend a couple of hours before everything works the way you want it to.

Use a Wysiwyg editor – or don't

There is a constant discussion going on in the Drupal developer community (and many other places I'm sure) about whether or not you should use a rich text editor (such as TinyMCE) for web content. (See for example this, this and this thread.) There are definitely pros and cons, the pros usually being stated by end users who want easy formatting, while developers emphasize the cons as they don't like the rubbish markup that is often the result.

Regardless of which path you choose, you can do a lot to optimize the user experience as much as possible. Even if you don't use a Wysiwyg editor, you can still provide a toolbar for inserting formatting code so the user doesn't have to write it manually, using modules like markItUp or BUeditor. And there's other types of text markup than HTML, like Markdown (which this site uses) or Textile. These are both designed to be quick to type and easy to read even in their unparsed format.

Wysiwyg API is a new effort to provide one central method of managing editors and toolbars in a cohesive way. With Wysiwyg API, you can have multiple editors installed simultaneously and link them each to a separate input format. This also solves a lot of problems that wysiwyg editors used to have, like appearing in places where they're unwanted. And the killer feature is that when you switch input formats on a certain texarea, the editor is automatically swapped with JavaScript. Very very neat!

Wysiwyg API has support for a number of editors, but it seems to have the best configuration support for TinyMCE. If you want to use a simpler toolbar based solution, it's also compatible with markItUp (which has support for several different markup formats, including Markdown).

Choosing the right input format automatically

Speaking of input formats. They're a great way to choose what type of markup and what HTML tags you want different roles to be able to use. One limitation in standard Drupal though is that you can only choose one default input format for all users in all contexts. This means that you have to teach content editors to change input formats (if they're allowed) whenever the default isn't appropriate.

There's of course a module to solve this problem too. Better formats lets you choose default input formats per role, and optionally even set it differently for each node type. It also provides different ways of altering the appearance of the input format widget.

Conclusion

Drupal's flexibility and modular design can be a blessing and a curse. There isn't always the streamlined user interface you might have had if it would have been designed only for one particular use case. However, the rich supply of contributed modules in this and most other areas provide all sorts of ways to overcome this limitation.

This article has focused on the content editing interface. In an upcoming article we'll talk more about how you can provide convenient shortcuts to adding and editing content on a site, and also how to manage large amounts of content efficiently.

There are probably lots of smart tips that we forgot to mention in this article, so if you miss something, please put it in a comment!

Appendix: Modules mentioned in this article

• Better formats
• BUeditor
• CCK
• FileField
• Markdown
• markItUp
• Menu Settings per Content Type
• Menuless Node Type
• Node Form Template
• Node Form Columns
• Override Node Options
• Panels
• Vertical Tabs
• Views
• Wysiwyg API