Illustration of a small car towing multiple overloaded trailers of vacation equipment.
Illustration by

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.

Article Continues Below

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:

Man is tormented by no greater anxiety than to find someone quickly to whom he can hand over that great gift of freedom with which the ill-fated creature is born.

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.

About the Author

Rory Douglas

Rory Douglas is a web developer and writer working for the Washington community college system. He makes gardening jokes on Twitter and wrote the forthcoming book The Most Fun You’ll Have at a Cage Fight, which has nothing to do with web development and everything to do with amateur MMA.

22 Reader Comments

  1. Love the article and agree 100%.

    Do you know about MODX CMS ( It is one of the few systems that does exactly what you describe: give the freedom developers need, but allow you to limit the editor options any way you want.

    I used to work with WordPress and Drupal but since I found MODX 7 years also I have not looked back…

  2. Awesome article! 🙂 I’m in the same boat as Menno. MODX allows designer, developer and content publishers all work together on the same platform and framework. MODX works in the opposite way compared to many CMS’s – You decide how much you want it to be involved in your website or application.

  3. Great article. Having built a few CMS sites for a couple of clients, I can totally relate to the paradigm of giving clients the freedom they want with the limitations they need!

  4. “I haven’t actually used MODX. I’ll have to check it out”
    While you’re at it, make sure you check ProcessWire. From individual field permissions, to choosing the buttons in each wysiwyg field, and passing by field visibility based on the values of other fields, you just described it in your text 🙂

  5. I was going to mention MODX, but the others beat me to it, nice! MODX deserves more recognition in the CMS community for the scalability, power and customisation options it provides developers with.

  6. ProcessWire developer and designer here. Good read. One great advice is also to take the time to write contextual helps for users into your CMS. Knowing how many characters a field takes or what filetype to upload is great but does not help much. However, instructing users on tone of voice, image style or data specifics next to appropriate fields will help keep content consistent.

  7. This is a great article. I can get behind most of it. A good CMS is a customized one is spot on. A decent CMS (like Craft) makes this easy.

    A couple little things I found myself disagreeing with:

    It’s probably going to be more trouble than it’s worth to have a strict character limit on a text field.

    It’s helpful to have some kind of soft limiter, especially on something like a meta description. Your front end templates can define what to do if it does over but I agree with this.

    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.

    This completely does a 180 from the previous statement recommendation above. I get the gist of this but I think a better example is needed here.

    I fundamentally disagree with micromanaging (formatting) permissions. There’s a fine line between empowering people and creating animosity among users because they can’t do certain, basic things. “Why do Linda’s posts look so much better than mine? Why does she have access to the blockquote tool?” Just because the tools are available doesn’t mean someone is going to abuse them.

    I totally understand the need to lock down certain things and only allow privileged users with elevated permissions to do certain tasks—for example, a workflow where editors have the final say over a published document or simply making sure an intern doesn’t delete every page on a website is typical.

    But there comes a time when the best solutions aren’t technical, they’re teachable moments. If one group is forbidden to make a headline because an editor is afraid a content contributor is going to blow up the formatting of the site, you have bigger problems. In other words, if your users are constantly misusing features or not adhering to the style guide, you retrain them on how to do it right. And if someone still can’t get it after that, they’re not doing their job so you replace them with people who will.

    Training isn’t rocket science, it just takes time. There always needs to be someone being the “brand police” so to speak—basically an advocate to how the website is supposed the look and the way to accomplish it in the CMS. That’s never going to happen by itself, regardless of how much you lock it down. Yet I think a lot of organizations would rather take the easy way out and make it a programming endeavor.

    Sometimes it’s not even the users’ fault at all, maybe the way a certain feature in a CMS is broken or used in a way it really shouldn’t be. I see that happen often. If someone has to go through 6 steps to publish something when another CMS can do it in 2, maybe it’s time to revisit how you’re publishing.

    To paraphrase Karen McGrane… “what’s the cost of a bad authoring experience?” Just because the developer is the smartest guy in the room and knows how to do something in a CMS doesn’t mean the “average” user will be able to replicate the procedure. modX has a lot of power but its UI is terrible. When I hear “well, it shouldn’t be that hard” or “he’s clearly an idiot” from a developer after being told a user was struggling to do something, maybe it’s back to the drawing board and it’s the interface which needs room for improvement. There’s no room in an organization for developers who want their users to jump through hoops just to save their jobs.

  8. Agree with Ritter there, training should be part of every project and its best to choose a CMS that is easy to teach/learn.

  9. RE character limitations: just be careful if you manage multi-language websites. Certain languages are much longer than English. We once did a test on a travel website, and our German tester couldn’t input his full name on his reservation. Would you reserve if you couldn’t input your full name? I wouldn’t…

  10. Haha I love the reference to Dostoyevsky, though if the client doesn’t accept my reasons for wanting to spend more time on the CMS, I just might end up brooding like Fyodor with writer’s block.

  11. I love your sense of humour, Rory. And thanks for the tips – a lot of them feel very spot on, even if I bailed on WYSIWYG a long time ago. I was curious, though, how do you handle long-form articles? Say, an author routinely writes 6,000 word posts, any tips around securing the CMS against possible calamities in this situation?

  12. Great article. I think that being thoughtful when implementing a site into a CMS is one of the things developers and designers have to get better at if we want out clients to be successful. When a dev complains about a client doing a poor job of editing content, I just picture that poor client being endlessly frustrated with a poorly designed CMS solution. Often, the CMS implementation of a project is a one-and-done solution where the dev tackles it herself and not another thought is given to it. Indeed, a sad state of affairs.

  13. Hi Rory,

    I’m curious what cms you work with. I develop with Perch Runway because it’s straightforward to combine structured content with design flexibility. I’m always interested to check out contemporary content management systems and appreciate how Perch helps ease of entry while still powerful.

    Because it’s markup is so clean I can use Perch for React.js sites as well as regular HTML sites. They wrote up an interesting blog post inspired by your article. If you want check it out its here.

    I also want to look into Craft but have yet to dive in as I’m unfamiliar with the twig templating system. Point is that I’m finding a whole new class of cms are hitting the market that facilitate the kind of customization your article covers. For me, although popular, Drupal has a steep learning curve. WordPress, although vastly improved and popular still depends on plugins like Advanced Custom Fields and isn’t designed from the get go for structured content which impacts performance.

    Eric Mobley’s comment is right on. Pretty much any system, can let editors post quickly. It’s doing the upfront work to carefully model content and understand business goals to implement a well designed appropriate cms that is hard. However, a modern cms, of course with support and training post-launch — can make it pretty easy for editors to add rich content while still be keeping markup clean and help us publish in a variety of platforms and sites. I look forward with great optimism to see our tool sets develop.

    Thanks again for sharing your article and experience. Its an exciting topic and time for content management systems!

  14. Great article! I’ve found myself with the same issues many times. I’ve personally started using Craft ( and don’t expect having to use anything else any time soon. It’s extremely easy to template from static html to the CMS, image transforms for srcsets, etc. I’ve absolutely fallen in love with it! Will work well for anything from blogs to database driven websites 🙂

  15. WordPress is clearly the winner. Simple yet easy to manage. Been dealing with magento lately its a nightmare for a large store with mickeymouse caching plugins…

  16. With growing business and increasing expectations from the customers the need has arisen to have dynamic and responsive websites. Content has been a crucial part of business strategy that speaks about offerings and improves trust. Enterprise web content management systems are a great platform that allows a business to effortlessly design and maintain multiple websites. There are various CMSes available that vary in terms of features it provides and platforms that they use as base. It is important to consider CMS as a part of business strategy and ensure to select the one that suits best with business requirements. Once installed, make sure to update it regularly to keep it afloat with the changing trends. Updating plugins and extensions ensures website safety. It should be understood that managing websites is a regular task and must be given priority.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA