Incredibly flexible and modular as Drupal is, we’ve found several consistent issues come up with our clients when they actually get their hands on their new web site. Especially once they start content editing and site management in earnest. The element I’m referring to is the content management aspect of Drupal. There is some functionality that editors just expect in a CMS system particularly if they have a background working with other CMS systems, or Drupal is replacing a legacy system. I’d recommend everyone who develops for a CMS such as Drupal has experience of at least 2 or 3 other CMS’, even if that is just downloading them and seeing how they behave out of the box and how they create and edit content.
I should start by explaining what I mean by content management. To me this is:
- Creating, editing and removing content from a website
- WYSIWYG editing
- Managing media and file attachments, such as: images, PDFs, videos and audio
- Managing the links in content areas between content and from content to media and maintaining site consistency e.g. stopping dead links when pages are deleted
- Managing revisions and workflow
I should also make it clear I’m talking from the point of view of content editors or authors, and not administrators or other power users.
Obviously the first point is well provisioned in core, but all of the others are lacking with a vanilla Drupal install. While most of this functionality is available in one form or another through the addition of contrib modules, there are places where this falls down or has an awful user experience as these have been bolted around the core functionality. You can easily end up with a hodgepodge of modules all to do what I and many people consider out of the box CMS functionality. Worse still is that some of these modules don’t play well together and you end up with some weird bugs and some peculiar issues.
How should we go about resolving this? These are my thoughts:
WYSIWYG editing
I think that firstly the WYSIWYG module should be in core. Not only that but for most of this, I think the best solution would involve selecting one of the two main WYSIWYG editors to use in core, either TinyMCE or CKEditor. It seems crazy to me that so much work goes into trying to make a generic system so that any editor can be supported, when that time could be spent on making the WYSIWYG editor experience awesome. End users don’t care what editor they’re using they just want to get their content onto the website, quickly with all the formatting, imagery they need. Anything that makes this difficult puts people off using the CMS and by consequence makes the website worst, either less frequently updated or left to a few people in the organisation who take the time to learn the system.
Although this won’t appeal to everyone, people with use cases that require other WYSIWYG editors, or no WYSIWYG editor can disable the module and implement their own. I think having this out of the box would make the learning curve to getting a basic website up and running minimal, as I suspect this is one of the first things any new Drupal user tries to setup.
Configuring the editor should also be simple, content editors shouldn’t need to know about filters, and enabling an option for the editor should allow it through on the filters.
Managing media and file attachments
Drupal should have files and media in core, in such a way that you can quickly upload images to the website and add them into content, inline, with or without captions on images. The ideal experience would be to do this through the WYSIWYG editor. Even if the images are stored as nodes, it should be possible to have an inline media upload that creates the node and requires the user to fill in any fields or other data required on the node to upload the image. If the image you want is attached to another node you should be able to browse or search the media library to find the file and attach it, again through an interface in the WYSIWYG editor. The same should be true for file attachments, videos, audio, etc.
Managing the links in content areas between content and from content to media and maintaining site consistenc.
Another key content management feature is linking between pages, it should be possible to link to another page on the site in content areas. This would need some sort of popup with browse and search options to find the content page to link to. Currently something like node_picker will do this, although my last experiment with that module found it to be quite buggy. This may not be a problem with the latest version.
The other problem exists that these links are unmanaged, Drupal doesn’t examine the html blobs that exist in content so it isn’t aware that content A links to content B. Or content A contains image C. Because of this it’s possible to change a URL alias or delete an image or page that is being linked to from elsewhere on the site. Other CMS’ manage this in a variety of different ways. Some prevent you from deleting a page that is linked to from elsewhere until the links are removed or repointed, or at least warn you that page A is linking to this page so you know you are creating dead links.
This becomes quite a complex issue to deal with. Do we parse the HTML and update a table of which pages are linked to from this current page? Do we search for links in the pages of the site when deleting or moving a page or media item, which sounds like a bad ideas to me? Do we store links as tokens in the page and create the html when the node is viewed, not outputting the link if the page being linked to no longer exists?
Managing revisions and workflow
This is something that is probably better suited to a contrib module as I think it’s a more advanced CMS requirement. My first thought was the content_moderation module, but having seen Workbench at Drupalcon London, I think that module meets all the requirements I had for this element. My fundamental requirement is a way of editing content without it immediately going live, and without making the page unpublished. Especially for large edits which may be completed in several visits to the page. In addition to this extending workflow to have approval steps before new content to go live is a common requirement on large CMS sites.
