Skip to main content

Top Flaws of Today's CMS

Some of my criticisms on modern CMS, and how we can strive to solve content management problems.

Published
Last Updated

Overview

In this article, I'd like to go over the reasons why all of today's CMS fail, and some things we could to do fix them. It is my hope that in reading this document, you may have a better idea of what issues you may face in maintaining a cms, or better-yet, in choosing between using a CMS and a normal web application. The major flaws are as follows:

Visual Assignment

Today's most popular CMS all do their assignment from the back-end, using some kind of method akin to select boxes. There's a select multi element somewhere on the page, and we choose the page to assign the content to.

Although this works, there's still the fundamental problem of the user not knowing where the content will be appearing. For example, does top-a mean the first module, organized horizontally from the top of the page... or does it mean something else?. All of this depends on which template provider you're using (ex. YooTheme vs. RocketTheme). Some other templates could also be completely different.

Solution: Visual Content Assignment

What we really need is a visual way of doing things. We need an interface where we can drag and drop boxes of content on the page around, and then where, for example, double-clicking would begin editing the content. Something akin to this was demonstrated during the early stages of Joomla 3 Alpha (missing link, sorry). The video shows one of the creators of AdminPraise visually editing the modules. This would be ideal, as it would give the user immediate feedback on what the site will look like; no preview will be required (more below on previews).

Previews

As it currently stands, there is no accurate way of seeing your article as it's rendered without putting the content live first Wordpress offers an accurate previewing feature, but all the other CMS lag behind. Though there are some small exceptions like plugins that will do this, this i s a major problem in most of today's CMS. The reason this is a problem is that you should not be putting content you're not sure of (how it will look) online to be sure about it.

Of course, the content on your localhost, or, for Joomla, Better Preview, but these should be avoided; in most cases, users will be using the cms because they cannot always have access to their main machine. Employees may be posting articles or blog posts... there are limitless possibilities requiring the only the use of the built-in preview features.

Solution: Cookies or LocalStorage

What we could do to solve this problem is incorporate the full web page view into the preview functionality in any CMS. For example, when the user is creating an article, the system can present the user twith the option to view a preview of entire existing content with the new content. The preview could last until the user logs out, and could be associated with a cookie or with localstorage keys.

Bloated Stylesheets and CSS on Pages

Using a extensions in any given CMS can often result in the loading of undesired styles. Though the most expensive extensions or plugins use theming, your site will still suffer at load times. Even in Joomla, enabling a plugin you're not using on a given page can result in CSS or Javascript loading.

Solution: Coding Standards

Developers need to conform to coding standards. When I say coding standards, I am referring to all of the best practices for a given project: in this case, that's how styles are done. Developers should try to use the system classes included with the CMS, and they should make sure to follow all provided documentation for that CMS. If the enabled theme is unknown, the developer should test for all the possible template vendors (for example, check if the current enabled template name starts with yoo- or rt-. Template vendors should prefix their template names to indicate that they designed the template. By taking this approach, we can keep our existing markup, not have to import any styles at all, and maintain a similar look to the user's template.

Poor HTML Markup

A problem plaguing today's best extensions is poor HTML markup. It's sometimes as if developers wanted to use some HTML5, but they decided to start using divs again just because they were scared. I don't want to point fingers here, but if you take a look at YooTheme's markup, it's really poor: ids are everywhere, even when they aren't used for jQuery, asides aren't used, headers and footers are never used, and most importantly, sections are not used nearly as much as they should be.

Good HTML markup is not easy. It involves taking multiple trips over to the W3C page to check for changes in recommendations. It takes practice too. Good HTML5 markup is semantic, and should not be bloated with unnecessary elements. Remember, the more nodes on the dom tree there are, the longer your page takes to render. In the same way, over-specified selectors in CSS is not going to make your page any faster; rather, it will lead to more code, and most importantly, issues with specificity (like the dreaded !important.

Proper Referencing

What every CMS needs is a wikipedia-like referencing system. As an academic myself, I'm highly accustomed to writing detailed reports with references, but that doesn't mean that others shouldn't follow suite. I think one of the most important features CMS developers have forgotten to focus on is the ability to properly indicate references, footnotes, indexes, and bibliographies.

Including proper references in your document is important. It indicates to your reader where you got your information, it gives your document credibility, and it prevents you from plagarizing other people's work. And it's not hard: just include a list of references at the end of your document indicating where you got your information.

The Solution: Integrated TOC Editor

We need to be able to assign references to series of words in our documents as we write them in our CMS. To do this, we can use non-standard notation in tags to show where the references are. To get an idea of this, check out how Wikipedia does it. If you haven't already created an article, do it now. Make an account, and post something, or even edit some existing content. References are begun with something like a { and end with }. So when the reference appears, the user can navigate to it, and their browser will navigate them to the corresponding reference in the list below.

Alternatively, you could use a lot of other much simpler solutions. Normal anchor tags will do just the trick; you don't have to give a full reference list at the end (though I encourage it).

Unconfigurable Text Editors

Text editors for today's modern-day browsers are flawed. You can download an infinite number of plugins for your CMS in the form of WYSIWYG editors, but they will all fail for one reason: what you see isn't what you get. All the editors today will load in some sample styles to get you on your feet when designing content; the styles will not be the ones you have on your front end, and could result in unpredictable output. For example, whenever I examine WYSIWYG editor output, I find them littered with the now-depreciated br tag.

Some vendors have tried to solve this by allowing the user to import their styles from their site front-end into the back-end. But this also fails because inconsistencies will arise from conflicts between the front-end and back-end styles. For example, JCE editor for Joomla allows for this. You can import a number of styles from your template directory to use for editing your articles. But after testing this, markup was never consistent because the editor itself (TinyMCE) was randomly injecting span elements and an html and body element into my articles. Markup was a disaster. If you're using Wordpress, you'll be familiar with the add_editor_style($stylesheet) function, which conveniently adds a custom CSS file to tinyMCE. Likewise, in Wordpress, the preview will not evaluate javascript, so you don't get an accurate idea of what your content will look like after javascript evaluation. Moral of the story: never use a WYSIWYG editor if you know HTML5.

The Solution: Shared Styles

If we used a shared stylesheet for the entire front-end and back-end, we would no longer need to worry about importing specific stylesheets with a given plugin. Given the editor doesn't load itself in an iframe, all the editor would need to do is allow for editing in a div. This is exactly the case in my favourite WYSIWYG editor, aloha. Unfortunately, Aloha imports thousands of lines of CSS.

In the latest version of Calipso, which I'm working on now, we'll be taking this very approach and removing the excessive styles. Content will be styled exactly as you'd expect, using system markup, allowing for a predictable and accurate output.

Inconsistent HTML over Template Switching

What is Template Switching?

With modern CMS like Joomla 2.5 and up, switching templates is easy, and even configurable to an on-page basis. This means that we can route a request for a given URL to a certain template; for example, the URL /index.php/home/blog could load with template A, and /index.php/home/apps with template B.

Why It Fails

Unfortunately, no template will use the same classes, markup, or layout. So when I load up a YooTheme template, and I code some content in a box-hint, expecting a hint box, I will get absolutely nothing but an empty element in another template. This is because the styles for that element don't exist.

Template vendors have tried to solve this issue by adding additional selectors to accommodate for all possibilities to their template styles, but this just makes for an even more confusing stylesheet. The web community has also seen a push for markup conforming with the popular CSS framework Twitter Bootstrap. All in all, none of these will work; Twitter Bootstrap is a poor excuse for HTML5 markup (no fieldsets used, no input[type="search"]s used, and TONS of unnecessary divs), and no bloated stylesheet, no matter how bloated the selectors are, will suffice in accommodating for all possibilities.

The Solution: Good Ol' HTML5 Markup

The reason I say ol' is because the HTML5 specification has been around for over 5 years now, and only now are we starting to see a push. By using HTML5, we guarantee cross-browser consistency in modern browsers, while using semantic, readable markup. For example, don't use custom classes or a plugin to make accordions; rather, use the details and summary elements. We can show and even hide content using these, and we don't need any Javascript! When you make a search bar, don't use input type = "text"... use input type = "search". This allows your site to appear natively as it should, without relying on extra styles, markup, or javascript. Doing so would allow for markup to remain consistent across switching templates, and it would encourage best practices for CSS selectors in HTML5.

Search input not appearing right?

Check out Chris Coyier's post on styling search inputs.

Simple HTML5 Selectors, Simple Stylesheet = Happy Users

As I began to learn the ropes of creating lean, quick, and efficient stylesheets, I learned to favour semantic HTML over layout-dictating HTML. What I mean is that, if you look back to my post on GGS using the 1140 markup, you'll see how this kind of markup can really bloat up the HTML file. I didn't really realize this until more recently, but it's much easier to maintain a markup file that has nothing to say about layout.

Take the following form for example:

<form action="submit.php">
    <fieldset>
        <legend>Basic Contact Info</legend>

        <!-- Firstname Lastname -->
        <label for="name">Name</label>
        <input type="text" id="name" required="required" placeholder="Firstname Lastname" pattern="[a-zA-Z0-9]+">

        <!-- Email -->
        <label for="email">Email</label>
        <input type="email" id="email" required="required" placeholder="Email">
        <!-- Firstname Lastname -->
    </fieldset>
    <button type="submit">Sign Up</button>
</form>

Compare the former markup to this bloated, bootstrap-friendly markup:

<form action="submit.php">
    <fieldset>
        <legend>Basic Contact Info</legend>

        <!-- Firstname Lastname -->
        <div class="control-group">
            <label for="name" class="control-label">Name</label>
            <div class="controls">
                <input type="text" id="name" required="required" placeholder="Firstname Lastname" pattern="[a-zA-Z0-9]+">
            </div>
        </div>

        <!-- Email -->
        <div class="control-group">
            <label for="email">Email</label>
            <div class="controls">
                <input type="email" id="email" required="required" placeholder="Email">
            </div>
        </div>
    </fieldset>
    <div class="form-actions">
        <button type="submit">Sign Up <i class="icon-pencil-2"></i></button>
    </div>
</form>

There are two problems with the bloated Bootstrap version:

  1. The extra div tags, notably for every input (of class = controls and every control-group). Why do we need div tags here? You can't float them like within rows, you say? I beg to differ
  2. The second problem is in the footer of the form, with the submit button: the appended icon.

Think to yourself: what if the user were to switch to another template that doesn't support Bootstrap? Obviously, you'd be left with an essentially unstyled page. There's no guarantee that the person adding markup to whatever site your stylesheet applies will have their form configured in that specific order: control-group, label class = "label", and div class = "control-group"; however, you do know that every form must have an input if it is used correctly, based off of the W3C. We know for sure, the user would not see an icon anymore beside the submit button... and since the parent elements of the form were styled, the grid would "break", and you'd be left with an unhappy CMS user.

I would like to argue that by styling only the basic elements that make up HTML, we can make our stylesheets less bloated, and at the same time, ensure that our stylesheet will work with valid html.

There is, of course, the argument that doing this doesn't allow for deeper customization; but upon deeper reflection, you will realize, just as I did that all customization should take place in one place: the main stylesheet. For example, you might want to say that in building a Joomla component or plugin that you should not use generic selectors like the aside or section tags. And in some cases, making highly specific selectors may be the right thing to do (for example, building syntax highlighting classes). But even in these limited, special cases, we can still reduce our styles to a minimum by only styling the necessary. For example, no padding, no margin, just the colours. You could then assume that the author has already specified their look and feel; if they wanted to change the way something looked, then they would.

We can achieve the exact same visual result as the one in Bootstrap without using bloated HTML. Using the power of modern preprocessors like SASS, we can easily "extend" classes to other elements. For example, we could add the icon to the right of the submit button like so, based on the fact that they have to have a button[type="submit"]:

//declare icon ascii
$icon-arrow-right: "\f061";

//icomoon helper class
%icomoon {
    font-family: "icomoon";
}

//icon class
.icon-arrow-right {
    content: $icon-arrow-right;
    @extend %icomoon;
}

//style all submit buttons
button[type="submit"] {
    &:after {
        @extend .icon-arrow-right;
    }
}

The above would produce lean CSS, with grouped selectors, like the following (assuming icomoon fonts have already been loaded via @font-face:

.icon-arrow-right, button[type="submit"]:after {
    font-family: "icomoon";
    content: "\f061";
}

This would be much more maintainable, and you could add on to this grouped selector later, in any other file. And it works with all standard markups!

I firmly believe that encouraging developers to style for HTML5 will fix this problem.

Conclusion

After reading the above, it should now be apparent that no CMS is perfect. When choosing a CMS, we need to keep in mind flaws such as consistency in editing and rendering content on the web page. WYSIWYG editors are never consistent in their output, and lack the flexibility and functionality of their desktop counterparts. Even today's best and most reliable CMS (Wordpress, Drupal, Joomla) rely on separate styles for the admin back-end and front-end, and this causes for inconsistent output. Even when using those plugins that allow for importing front-end styles, markup is inconsistent from the WYSIWYG editor's poor programming.

Readers should also consider the authenticity of their content. Without some configuration, using a CMS may require you to install a plugin allowing for table of contents features and proper footnotes.

Verdict: Realm of Tech-Savvy Only

If you're just a company starting up, you may seriously want to consider using a CMS. But if your IT department lacks the skills in setting up servers, or if your marketing team lacks the knowledge of proper HTML5, I would strongly advise against using a CMS. While CMS offer a great deal of accessibility and flexibility for the team, you are likely to find the process of setting up and maintenance to be difficult. Those using the system will need to learn to use the CMS back-end. In some cases, they may need to request admin rights, endangering the entire system. Comparing this to the traditional case of an writer sending the administrator the HTML markup, and then editing it as necessary, you can probably see how the latter can be more efficient in some cases. Especially, if the administrator for the CMS is installing plugins/component, he/she needs to make sure those are trusted ones and that they won't put the CMS offline.

Overall, understanding the risks of using a CMS over a traditional website can only be best understood by trying one yourself. I hope this article gave you some idea on the risks, and I hope that developers reading this take these criticisms as good pointers for the design of future CMS.