CMS Evolution: From WordPress Classic Editor to Modern Content Management

How did we get here?

CMS and Content management styles and what they’re good for

Back in the olden days, websites were made by writing code and content together in the same text file, and uploading the collection of files to the web server. Ta da! And to edit the content, add a page, image, video or banner, you had to know where it was in the code, and maybe edit the code as well.

The era of the Content Management System (CMS) grew from this tree, and this new style of “install and go” website allowed users to log in to an admin dashboard and edit the content from there. WordPress was one of the first, and made its name from a reputation for user friendly admin experiences.

This user friendly interface had a simple edit screen for posts: A WYSIWYG text editor (What you see is what you get) that resembled the Word Processing software most computer users were familiar with. This delightful monolith was, of course, what is now called the WordPress Classic Editor. You can write and format text, insert code, or format code not to run but to display as text for tutorials, and insert and format media all inside this one editor.

Of course, the thing is that then the content editors had to format the post inside the editor. Before you knew it, the website theme styles were being overridden and restyled in every post, and design and layout decisions were being made per post as well. That sounds like a lot of work, doesn’t it?

Developers and Designers wanted to make content administration easier

There were many CMS frameworks, not only WordPress, and developers and designers using Drupal, Joomla, Magento, and others began to think about what would make life easier for content admins, and also simplify the development workload, and tools for custom fields began to appear.

Drupal really was the star of the customized admin experience. With contributed modules enhancing the ability to deliver complex features, we were also able to build and customize the admin experience with custom “content types” and sort it all with tags and taxonomy. In a custom content-type, you make custom fields specific to what that type needs, so that all the admin has to do is put text and images into those set fields, and the coded template and theme would style and format everything according to the design. Nobody had to care if it should be a table or try to make columns, or try to make a banner or embed a video.

Over the years, WordPress and Drupal started to align with each other, learning from their strengths. Drupal grew to have an intuitive admin dashboard like WordPress, and WordPress now has custom post-types and plugins that give us the ability to make specialized fields. A developer and designer can make a custom theme for their clients that only has in it what the client needs, and is tailored to their admin’s preference.

Everybody wants “Drag ’n’ Drop”!

Technology keeps moving forward, and soon “drag and drop” interfaces began to pop up, allowing admins to move things around by dragging and dropping them into position. We do this so often now in software, we hardly think about it anymore, but this was an exciting new development. Developers and Designers began building tools for our CMS frameworks that utilized this capability, and clients wanted more!

As the admin interfaces became less clunky to navigate, Designers and Developers started to think about web projects in a modular way, and the structure of the CMS followed suit. Fewer elements were hardcoded in page by page templates, and more had partial templates, and the ability to move the elements around in different sections in the admin interface, and not in the coded layout.

New kids on the block arrive

Platforms like Squarespace, Shopify, and Wix have popularized a style of website where every part of the site is populated and placed by the content admin. Depending on the platform, you may have options for customization in the theme, or a way to insert code in the edit screen. But you are now building each page with each element almost entirely in the dashboard.

Drupal and WordPress have themes and plugins that give this experience now too, and WordPress has developed their new default editor style, called Gutenberg, to work in this way. Rather than being faced with that big Classic Editor, you can now click in to choose what kind of layout element you want in your post as you build your page. Some plugins and themes add more “blocks” to choose from. In one way, this is an exciting development that gives content admins flexibility. But I think you might have noticed what has happened.

Content admins also have to be designers and information architects with DIY platforms

Yes, you guessed it! Now that there are controls to do almost everything in the admin without editing the code, theme styles, or templates, it is the burden of the content admin to decide the layout of each landing page, featured article banner, sidebar menu, and whether they show up in this section or that one. Is this better?

Cut through the DIY overwhelm: You can still have customized support with modern tools
For many clients we’ve worked with, they needed their editors to be able to quickly get the new post up by copying and pasting in the words, and uploading any new images in place. In both Drupal and WordPress, we are still able to make specialized content “choosers” that give admins flexibility to represent the post as needed, but without the elements they don’t need. We are able to support these features with styles consistent with their brand, so they don’t need to worry about one page suddenly looking very different.

We are able to support a customized theme built on accessible and responsive base themes, to make our development and design work more efficient. And we can work together to create an information architecture or navigation structure that makes sense, so users can easily find what they are looking for. We can cut through the DIY overwhelm that having so many options at hand can create. With an ongoing relationship, we are on hand to add the new options or features when the need comes up, as well as providing education, support, and training.

So which is better? Classic Editor with specialized custom fields or Gutenberg blocks and build-in-admin layout tools?

The answer will depend on your use case, of course! Who is managing your website content? How many are on the team? What tools are they already comfortable with? How much time do they have available to work on it?

You can have either experience with most platforms, so these questions will be relevant in every case. And this is actually an important point, that I’d like to underscore:

You can have both Classic Editor and Gutenberg Blocks!

In WordPress, you can have both styles of editing enabled so that your admins can set it to their preference. If you have a development team to support you, it can be set up so that the code and styles will support both in the theme. This capability cannot be beat for flexibility and ease.

Today’s technology era is abundant

We are rich in options for website technology. Editing content no longer requires knowledge of code, scripting, or web servers. We can do everything ourselves if we want to, from the comfort of the admin dashboard. We can also have a lightweight, specialized website experience with the support and knowledge of professional developers and designers.

Do you manage a website? What kind of content editing experience do you prefer?