Managing Your Content Management System

The first rule of content management systems is that you’re using the wrong one. Using WordPress? You’re a fifth-grader running a coloring-contest blog. Drupal? You should be using WordPress. An enterprise solution? You’re an open-source Judas.

This is how it often feels, at least, if you hang around the rough parts of web-dev Twitter or loiter in blog comments. But the real first rule of content management systems is that it’s not so much which CMS you use as how you use it. A bottom-drawer content management system implemented with care will often be much more useful than a top-drawer system pulled straight out of the box and shoved onto your server.

As a guiding text for implementing content management systems, I’m going to ruin your day by presenting a quote from Fyodor Dostoyevsky’s The Brothers Karamozov:

For our purposes, Dostoyevsky meant that the nicest thing you can tell your CMS users is that they don’t have the freedom to mess things up. When implementing a CMS, try to give your users exactly the level of freedom they need—but, when in doubt, err on the side of giving them slightly too much.

That’s the broad view of things, but it’s trickier once you get into the details—the fields and WYSIWYGs and permissions. What makes it even trickier is that, if you’re thinking about CMS implementation, you’re probably in one of two very different situations:

1. You’re creating a new site and the world is your content-management-system-implementation oyster.
2. You’re managing or refurbishing an existing site and the content management system setup brings you great sadness.

Although these situations each have their own individual troubles—which we’ll get to—they’re both governed not just by the first rule of CMSes but also by the second rule: no two CMS implementations should be exactly alike. Each site will have its own needs, and the CMS should be customized to match those needs.

With that in mind, instead of a set of prescriptions, I offer a handful of questions you might ask to limit your users’ freedom.

Can this element have its own field?#section2

With many content management systems—WordPress and Drupal spring to mind—content types come default with a big text field where anything can be entered. Anything you want! Consider limiting this freedom as much as possible by giving discrete elements discrete inputs.

Every element on your page that serves a purpose distinct from other elements should have its own input field. In a staff directory, a person’s job title and name ought to have separate input fields, even if they appear next to each other on the page. The photo should have a separate image-uploader field. The office hours in the sidebar should have their own field. The contact info beneath the office hours should be its own field as well. Remember: just because two items are near each other visually does not necessarily mean they’re related enough to share a field.

For those who think partitioning every element into its own field is excessive and unnecessary, remember that it gives you flexibility for the future. As Karen McGrane points out, breaking your content into chunks gives your content structure, and that structure gives you, the web developer, freedom. It gives you the freedom to make small design changes—like moving the contact info above the office hours—with just a quick bit of backend work. And it also gives you the freedom to make large changes to how that content is displayed, whether it’s on the site you’re working on, another iteration of that site, or a totally different product that taps into that site’s content. That’s the sort of freedom you want.

Can this field be more restrictive?#section3

It’s a good idea to use the most restrictive field you can for an element. If you’re going to use a big text field, ask yourself: could you make this plain text instead of anything-goes HTML? If it’s an image, consider using an image-uploader field rather than a general media field. If it’s a person’s first name, use a plain text field. If it’s a day of the week, make users select one of the seven days of the week. Don’t make them invent their own.

Restricting fields makes it easier for the people using the CMS to do their jobs correctly and quickly, and it can also help bring an editorial and visual consistency to the site. Having users select the day of the week from an array instead of typing it into a text field ensures that all days of the week will always be spelled correctly, and it keeps people from having to pause and remember whether the house style is to abbreviate days of the week or to spell them out. Also, if the house style changes, you can make a small tweak on the backend instead of changing the text in every day-of-the-week input across the site.

Restricting fields is also one of the most significant ways you can let CMS users know that they can’t mess things up. By using a restricted image field, you implicitly assure people that if they try to upload the wrong type of image file, the CMS will reject it. Likewise, using plain text instead of a WYSIWYG or rich text is a way of letting users know that they can copy text from wherever and paste it in without any problems, and that they don’t need to worry about styling the text.

However, there are a few areas where being restrictive will probably cause more harm than good. For example, it’s probably going to be more trouble than it’s worth to have a strict character limit on a text field. Even if it’s a field for, say, someone’s first name in a staff directory, you’re not going to cause much harm by having a character limit of 200 instead of 40. You also don’t stand to gain much by being too strict with so-called special characters. Allowing them might mean a slightly larger font file, but for most sites it’s not possible or advisable to avoid words with diacritics.

Does the WYSIWYG need this button?#section4

Out of the box, WYSIWYG editors sometimes come with a few dozen buttons. Some are classics like bold, italic, and strikethrough. Some are leftovers from word-processing days, like justify text and background color. Some are inscrutable: looking at the full set of buttons on CKEditor, I see a button that looks like a T walking a baby x on a leash, a globe, and three variations on a clipboard.

Most content management systems let you edit which buttons appear in the WYSIWYG. Do it! If the field is a text field that will need an occasional link, get rid of all the buttons except the link button. If a text area only needs basic text formatting, leave the buttons for bold and italic, and maybe ordered and unordered lists and links, if it’s possible they’ll be needed.

For general text fields—like product descriptions or event summaries—I like to keep those same few formatting options. I often omit the button for underlining—it’s best to restrict that style to links. I always include the link button because links make the web go ’round.

For longer texts like articles, I also include buttons for formatting block quotes, punctuation like em dashes (not everyone knows the keyboard shortcut), and maybe indent and outdent options if it’s possible that users will need to create lists within lists. I also usually create buttons that allow users to apply markup like headings, and I label them something like “Heading 2” rather than “h2,” since most CMS users will be more proficient in English than HTML. I generally avoid buttons that change font, size, and color or background color, which are best set through CSS to keep form and content distinct.

Those are just some starting points. Beyond that, know your editorial team. If writers like to sarcastically use strikethroughs, give them a button for it. Or if you only want editors to be able to sarcastically strike through things their writers write, only let users with editor permissions have a strikethrough button.

View-source buttons can be a difficult call. My general rule of thumb is that editor- or administrator-level users should have a view-source button if they know HTML. Funky things sometimes happen in WYSIWYGs—you’ll make something a heading and the whole paragraph will turn into a heading—and users who know HTML will find it easier to look at the source code and fix the markup.

You should use WYSIWYGs as basic formatting tools, not design tools. WYSIWYGs sometimes have a bad rep because users and clients want to treat them like word processors, a tool that gives people full (if clunky) control of how things look. They’re called What You See Is What You Get, after all. But if you restrict the WYSIWYG to its essential functions, you can assure users that what shows up on the website will look great every time, and they won’t have to worry about what they see or what they get.

Does the user need this permission?#section5

Restricting a user’s permissions is the easiest way to make sure they can’t accidentally destroy the site. Most content updaters or editors won’t need to mess around with permalinks, so don’t give them permission to do so. If a user is only editing existing content, you should avoid giving them permission to create or delete pages. And so on.

Here’s something you can do to figure out what permissions a user will actually need: when you create a new user, turn off all permissions. Log in as that user in one browser, and then log in as an admin in another. On the non-admin account, go about accomplishing all the tasks that user will need to do and, as you go along, add permissions from the admin account as needed.

How can I hard-code accessibility into the site?#section6

What’s accessibility doing in an article about implementing content management systems and 19th-century Russian novelists? Well: you can make your site’s code as accessible as possible, using the coolest ARIA roles and testing everything on an actual screen reader, but if your content updater creates grey text on a dark grey background or doesn’t care about alt text, your hard work goes to waste. You can’t prevent all of this, but you can at least make it slightly more difficult to mess up the site’s accessibility.

Even if you’re not ultimately the person uploading an image, for example, you can often still hard-code alt text right into the backend. If you’re designing a staff directory, for example, you can pull the alt text from other fields, like this:

<img src="cool-guy-optimized.jpg" alt="<?php echo name_field; ?>, the <?php echo job_title_field; ?> of Cool Business Guys, LLC" / >

That way, alt text will always be there—and it’ll even be useful and accurate—and the content updater won’t have to worry about it.

Or: if you’ve given discrete elements discrete input fields, you can guarantee that everything has the proper, accessible structure. Most content management systems do this naturally for h1 headings—they wrap your page title in an h1 unless you code otherwise. You can extend this functionality to other items. Put that callout text in an aside. Put that time in a time.

How effortless can I make image-uploading?#section7

As a web developer, you’re likely up to date on all the latest image technology. You know when you should use img srcset (most of the time) and when you should use picture (only when you’re doing something art-direction-ish). You know the best image-optimizing plugin that’s only available from this one plugin site you found that one time. When someone asks you to Photoshop an SVG, you’ll tell them it’s not called Vectorshop, and you’ll laugh at your own joke and resolve to have outdoor time this weekend.

Your content updater probably does not know these things. Even if you yourself are the content updater, you do not want to have to remember this when you are just trying to upload a picture of your arugula. That’s why you should code all of this into your system. When possible, every image on your site should have its own image-uploader field, and you should be able to drop an image of any size into that uploader field and have it resized, optimized, and put into the appropriate responsive markup.

All of this content management system stuff takes some work—but you can do it. I believe in you. I saw how robust your arugula was.

A few other questions you might find yourself asking#section8

I have an absolutely impossible CMS implementation problem. Any ideas?#section9

Let me guess: you’re dealing with articles that have pictures and embedded Tweets and maybe even an interactive graph, and the person creating the article is going to need to reposition those elements for every article. That’s one of the trickiest and most common CMS issues. Let me point you to Jeff Eaton’s “The Battle for the Body Field“ for some answers. That sort of problem is absolutely solvable with a CMS, and while my guidelines will send you in the right direction, Jeff outlines some ways you can approach that specific case.

If the problem you face is that you want your final CMS implementation to make all who use it proclaim its brilliance, check out Eileen Webb’s “Training the CMS.” Among other things, she has some awesome ideas for making the actual setup of your editorial pages helpful and easy to use.

Sometimes when you get into what seems like an intractable problem with a CMS, it’s because you’re thinking of how your content will appear on one particular page and not within your overall content/data structure. For that, check out Karen McGrane’s talk “Content in a Zombie Apocalypse.” She’ll help you rethink content modeling, and also kicks some dirt on WYSIWYGs, which is fun.

Okay, great—but where do I start with all of this?#section10

At the beginning, I mentioned that CMS implementations come in one of two types: with the first, you’re starting fresh, the world is your delicate cold little oyster, you’re not going to make the same mistakes this time; with the second, you’re refurbishing a CMS, things are broken, love isn’t real, God is dead, and so on. How you get started with asking these CMS questions depends on which situation you’re in.

If you’re in situation one, life is much easier in some ways. Keeping these questions in mind when you’re putting your design into CMS templates will make the field-related parts easier, and starting with reasonable WYSIWYG buttons, a functional image-uploading system, and built-in accessibility will give the site a solid base that you can tinker with later on.

The hard part is predicting exactly how the site will be used. It’s easy to think that you can replace the sidebar field with a location field and a contact information field, but what if someone wants to put a special message about holiday closures in the sidebar but they don’t have a place for it? If you’re redesigning a new site, I recommend using the gnarliest, most edge-case-y content on the current site for your sample content. That can often keep you from limiting things too much. If the site doesn’t have any content yet, that’s not really the best way to build a website, but if you live in the real world and have to do it anyway, you’ll likely have to err on the side of giving users too much freedom, and then restrict it later if you can.

If you’re in situation two, buck up. You don’t need to demolish your current site to implement all of this—you can slide into it gradually. Some parts are easier to do than others, and some of it’s more important. If you have a free afternoon, you can adjust all the user permissions appropriately and remove buttons from the WYSIWYG. You may even be able to adjust your image-uploading system without breaking images already on the site. But it’ll likely be more difficult to divide discrete elements into discrete fields or to restrict field types. Databases are sensitive like that. But the next time you create a new content type, you can make sure it has discrete fields and that they’re restricted appropriately. Even doing little bits and pieces of this can make your CMS more effective.

But what about politics?#section11

For both situations—really, for most web-development situations—the technical part will likely be easier than the political part. How do you sell the client or your boss on spending an extra week or so on making the CMS better? Did you pick a bad CMS or something?

In my experience, not only is it possible to get approval to spend time on this, but you can get outright gratitude. I recommend making a financial case: spending x number of hours on the CMS now will save five times as many hours later. The more specific, the more compelling. For example, if you estimate 16 hours of work to implement an image-uploading system that takes care of all the image sizes behind the scenes, you can then estimate how long it would take for the content editor to save three different image sizes and optimize and upload them every time an image needs to be changed.

If that doesn’t work, here are a few sound bites you can use:

• “This is a special, one-of-a-kind organization, so we need to spend a little more time making sure the CMS meets its unique needs.”
• “You have talented staff doing important work, and we don’t want them to have to spend their valuable time troubleshooting errors on the website.”
• “We want to make sure there’s no way you can do anything to mess up the site. That way you’ll never have to pay us again.”
• “See this page where someone uploaded a dog GIF and typed some flashing red text? I can prevent that from ever happening again.”

Just don’t quote Dostoyevsky and expect it to go over well.