What is the future of web development in CMSes?

I want to have a serious conversation about where the industry is going with web design and CMS use.
I’m speaking specifically in the context of building websites, whether blogs or business sites or info sites of any kind, just typical web design and development.

In the old days, a developer designed websites with pure HTML and CSS. Eventually dynamic languages and tools helped make code a little more DRY by having HTML includes and chunking out code blocks.
The problem with this was that the end users could not manage things because all the page content was right there in the HTML files and things could easily be borked by messing around in there. Routing was also a problem because every page had to be linked with an actual html file (or some file) in the web folder.

Then came the use of dynamic languages all the time, especially PHP. We could now run websites via a single endpoint (index.php) and route as needed, pulling in the content via a templating system. This setup has been evolving ever since.
But it suffered from the same problem. Content was inside the templates, it was hard for end users to edit. Technologies like Front Page and others tried to build “editable regions” to help end users have access to just the text parts.
These systems were quite rigid of course. The users might be able to edit some text, but change little else about their site.

The evolution of CMSes also happened. Developers could work with templates and code but put in the “user content” via template variables. The end users could then edit the values in these variables with some kind of admin interface, text boxes, wysiwyg editors.

These CMSes evolved but we found them still too rigid. Often a CMS would give you little more than a single wysiwyg box to enter the entirety of the content for a page. It was much harder to edit special blocks like headers, menus, footers, sidebars. It was also hard to enter custom code like widgets and forms and other things when all you had to work with was a single text box.

Now modular CMS functions enter the fray. CMSes built separate sections for editing content of sidebars and menus and widgets, and the developer once again stuck these sections into various places in the templates. Now the users had a pinch more control.

But it was still too rigid! There are too many 3rd party apps that need to be used. We’ve got headers and sliders and grids and forms and Google maps and the need for connecting any number of 3rd party APIs. It became too difficult or untenable to require a developer every time something needs entered in a page. But even then it’s not really possible for a developer to enter custom code in the “middle” of the end user’s wysiwyg content.

Now we get things like custom code blocks, shortcodes, or other types of “tags” that can be entered in a wysiwyg box which are linked to the actual code. Now end users have the power to install widgets and plugins which give them small code snippets which they can configure and place in their content where needed.

Once again we hit rigidity. A developer typically assigns an inner HTML area for end user content to go in. The end user has a hard time doing things like entering fixed width content followed by full width followed by fixed width again. They can’t do things like create their own column or grid structures unless those are entirely preassigned code chunks.
End users loose control over how many shortcodes are available or how to use them with their various options.

Now we enter the modern era. With tools like page builders and “live” editors, the end user themselves are able to create rows and columns as needed and stick in as many text boxes, title boxes, wysiwyg editor boxes, videos, code embeds that they need to get a page built.

This seems to solve most of the ills of the previous problems by letting the end user have so much control. But on the backend, it’s not so nice. The developer’s job now, rather than build nice things, is relegated to being a hacker, endlessly tweaking, fixing, adjusting the output of page builders, plugins, widgets, and code snippets. CSS becomes impossible, say bye bye to standardized nice markup or naming conventions, SASS files, etc. And hello bloaty mcbloatface output. The developer doesn’t have control over the HTML output of every widget and plugin an end user might find to install. Nor can they guarantee the safety and security and performance of using such tools.

Not only that, but when the end user gets to essentially design every single page with drag-n-drop glee and no standards, every page can look like something totally different from any other page.
This page gets a header and full width content. That page needs a purple background and black boxes. This page totally needs rounded corners and drop shadows on everything. That page is more “fun” and definitely needs all the fonts changed.
With great power comes great responsibility! If one is not careful, a page builder site can grow to 10s of thousands of lines of CSS, dozens of JS tools loaded for widgets even if those widgets aren’t used, horrendous output, endless CSS overrides and !important declarations, a dozen fonts loaded, and no real standard styling or branding locked in.

Now what I see in the industry is a combination of page builders and some small degree of developer control. The developer uses the page builder to design everything, then hands over the keys to the end user with some moderate instruction how to open it and find text blocks to update them. At this point if the end user starts changing styles and fonts and padding and margins and shadows and colors, it’s not the developer’s fault or problem. The developer can’t create generic CSS to handle the look-n-feel of every conceivable kind of HTML output that any plugin or widget might generate, there is endless possibilities. So any time the end user finds a way to change their content in some new way, a hacker dev needs to come in to fix the CSS jankiness.

Not only this, but the page builders themselves are little more than hacks! Take Wordpress for example. Early page builders were little more than front ends for sticking massive amounts of shortcodes into the main content editor. Have you ever looked at the raw text of a Visual Composer page? A sea of shortcodes. I imagine many page builders work that way, dumping their own custom code (which needs further interpretation later) into the single content box of the page. This feels very hacky!

It can’t work with tooling, it requires a second interpreter of special codes into HTML. Page builders come with their own sets of JS and CSS files which always need to balance with the main site CSS, the list goes on. And I’ve seen cases where an end user accidentally switches from page builder to raw text or something, and lose all the page builder code. That is ridiculous!

Modern page builders perhaps use some other technique then dumping codes into the wysiwyg box, but it still feels like hacky stuff and a bit unnatural. Different page builders can’t work with each other, and widgets and plugins must be designed specifically for that page builder.

And that brings me to my question. Where is this going next? What is the next evolution of balancing developer design and end user editability? Because something is clearly lacking.

Recently I worked on a business site built on Processwire. I like PW as it adopts what one might think is a more modern way of doing things. Instead of the end user being given one single wysiwyg box to put in all content, the developer on PW creates individual and unique fields for all the custom content of any given template.
The developer creates fields, the fields are assigned to templates, and then any page that uses that template gets all those fields.
(Note that I see this style of design used on WP too by using custom fields editor and creating special fields for output)

At first glance this feels pretty good, because the developer is in control of exactly what fields are needed for any given custom template, and can design those fields into the templates which can be standard HTML/CSS/PHP files. We can develop with normal code and have control over the output and CSS! Yay!

But this system runs into the rigid problem too. On this site I’m working on, there are templates with as many as 40 custom fields or more, each field linking directly to very specific output in the template. This is great if you build a design that is never going to change much, but I feel very locked in to all these custom fields which are directly tied to the developer’s original output code.
If I want to remove a block or section, it’s not just a matter of putting no content in a custom field, I have to delete the field from the template, and then edit the template files to adjust the output and remove the field reference. This is all done by the developer but that shouldn’t be the case. Why should you need a developer just to get rid of a div block that shows a customer quote?
But in Processwire, the development of a template is pretty well tied in to the custom fields assigned to the template and presented to the user to fill in.

Again, PW is great if your site structure and design is not meant to change much. And the end user is going to need a developer if they want any kind of basic change to structure, or require new fields or to remove other fields.

In Wordpress if you want to delete all the page builder output and start again, you can do that with a dozen clicks and your general template output is not going to change much. On Processwire if you want to remove all the page content and start again, you have to delete all those custom fields, which will completely destroy the output of the template that links to all those fields.

It seems we have two extremes with different focuses on how templates and content are built up. It seems to me neither approach is desirable. I want the ease of Wordpress page builder, but the control and cleaner output of Processwire.
I want, as a developer, to work with plain template files, designing in HTML with the ability to use HTML/CSS/JS/templating tooling to get the job done, no funny business. But I also need to make it easy for the end user to add/remove content as they see fit without destroying my templates, creating bloat, dueling CSS structures, etc.

I don’t want rigid structures of a CMS preventing me from doing any design I want in the templates. And I don’t want rigid structures of templates preventing the end user from adding/removing their content in any area of the site they wish.

What is the next evolution of the developer/user CMS workflow?

Some might argue that there is no real fix. If you want a highly custom design that is efficient with great performant code/output, then you need to use a CMS (or nothing) which gives the template control entirely to the developer. Something more like PW. And the end user is given very specific data fields that can be edited.
OR you give more control over the end user, which is going to require automated builders, drag-n-drop editors, widgets and plugins, generic and wildly variable output that will require a lot of hacking up and overriding, and bloated code.

Is it either/or?

I have to believe there is another way to solve this problem. For all I know there is already a perfect CMS out there for the job and I haven’t seen it yet.

What I do know is that the future of design is probably going to allow end users to edit their content “live”. Literally looking at the page and just click text and changing it. Plenty of page builders and tools do this now, but I do think this is the future, rather than sending the end user to a backend where they have to find fields and type in plain text, not knowing how it will look live until they save the changes.

So heavy developer control, heavy end user control, live editing. Is it possible?

For the sake of this conversation, I’m speaking only about the future of wrapping all this up into an off-the-shelf CMS. Will we have a CMS that perfectly balances this conundrum? For the sake of discussion, I’m not talking about developing from scratch, you know building Laravel or Node or Symphony or whatever. Let’s just talk about CMSes in particular.

Where do you see design and development going in these tools? How can you balance developer and user control over content without sacrificing tooling, standard templating, performant and standard output, etc?

And…have you found a CMS that does this really well?

I think that you are erasing the lines between developer and client in this discussion. My feeling is that whatever tool the developer uses should be flexible enough for him/her to build what the client is needing, but that the client should not have total control over the website, unless the client is building his/her own website (hence a website builder and then who needs a developer).

I use WordPress, and sometimes Joomla or Drupal, for all my clients’ websites because it gives them the ability to edit their own content, add/remove pages and adjust menus to match, within certain set parameters.

When I build a custom WordPress theme for a client site, they are given the ability to place content blocks anywhere they want, depending on which of the set of layout templates I have provided for them. And they do not have to use shortcodes, etc. And every area of their website is editable by them. They don’t really want more control over their website than that, and I don’t think they should have more control over their website.

As such, the tools available to me right now as a developer have been flexible enough to accomplish anything that a client asks for.

I don’t think there will ever be any CMS in the near future that does everything without needing to add in extras, because thank goodness there is still a bit of resistance against bloat.

1 Like

I highly doubt that with Wordpress. I’ve never seen good output from WP nor a website where the output was completely in control by the developer. As soon as you add page builders and widgets and plugins in the mix, there is just too much different stuff being output, with every new piece sending along its own new css files and js and font registrations and whatever else they do.

And if you follow good practices, you avoid editing anything in a parent theme or directly in plugin code, which means a lot of stuff has to be overridden and tweaked to get final output.

Regardless, can you go deeper into your technique here? Are you giving them a page builder or just setting up extra custom fields or post types? How does switching templates give them new content locations? What do you mean “place content blocks” without shortcodes? Where do the content blocks come from?
What do you mean “every area of their website is editable by them”? You mean they can turn the footer on and off and change everything in it? Add an extra sidebar if they want? Make the main header/menu sticky? Change out a slideshow and put in a full screen background video instead? I doubt that “every” area is editable without having access to the templates themselves. But I’m not sure what you meant.

Don’t view my reply as hostile, I’m more just interested in the specific of how you set it up regarding templates, fields, blocks, widgets, builders, whatever it is you use, what plugins are involved. Of the 100 or so WP sites I’ve worked on, many built by agencies and custom theme designers etc. None of them felt like anything more than fragile hacks. My goodness, the fragility! Often the client wants something that appears to be super basic, like add a logo just here in the footer. Only I find out it takes 3 hours to figure out how the stupid footer was actually assembled. It comes from this widget leading to that shortcode put out by that template calling on that partial which calls this function in that functions file overloading that theme function… And I just want to put a logo by some footer text!

Anyway, so there is one vote for WP which is my least favorite thing in the whole developer world, lol

I don’t use ready-made themes and very few plugins. I build them custom themes to fit the design and layout that have been designed for them, and the only plugins I use are for contact forms, and an enhanced MCE editor usually. Every part of the content can be made editable using a loop with a custom query. The main parts of the page are the ‘pages’ and all the rest are content blocks made from custom posts and a custom taxonomy that sets the locations of the content. The templates can be built for the client to coose from: two columns plus left sidebar, single column with two sidebars, etc.

Most current websites can be converted into a WP CMS and retain their current look.

But again, this is after a design (any design) is agreed upon by the client, whether or not they want a slideshow banner, etc would be fixed ahead of time. They would not have carte-blanche to adjust everything in the basic design. If they wanted that I would just send them to a website builder and suggest they build their own website.

Sure, it sounds like it works for you, but to me the entire thing sounds hacky. In other words, a taxonomy chooses template positions. Custom post types become page elements instead of entire pages. There is a sense in which these are being used in a different way than the CMS designed them to be. Aren’t widgets supposed to be for content chunks?

My problem is not that I’m saying “something can’t be done in WP”. Of course you don’t even have to use any WP features if you just want to stick everything in a template file. But I digress. My problem is most all websites build on WP already require a handful of plugins out the door. Install SEO stuff, security stuff, sitemap stuff, custom post types and custom fields GUIs, page builder, slideshow editor, widget display logic, the list goes on.
I believe a good CMS should be somewhat functional right out of the box. WP isn’t. Unless you want a blog of course.

Certainly you don’t think WP is somehow web development nirvana? I assume not, and that’s all I’m talking about. It shouldn’t take 3 hours to figure out where some text goes into a footer by having to navigate through 37 template file layers. It’s far too complicated and intricate the way everything relates and everything is a function and most all HTML is output through functions and echo statements. It’s entirely unnatural. Output can come from WP settings, theme settings UI, theme customizer UI, plugin UI settings, widget, shortcode within content, custom field, template itself, a filter or action overload. It can be related to what post type and template they choose. It’s nearly impossible to answer the question “here is some output on the page, exactly where does it come from?”.

The next evolution of a CMS is going to combine the sorts of techniques we now have to “hack” into current CMSes. It’s going to combine some sense of custom data types, reusable content chunks, page builder-like functionality, template variations, custom fields, admin/developer parts and end user parts. And it won’t feel hacky or that the CMS is being used in a weird way, it will just be exactly the way it’s designed to be and everything will be in its place. The templates will make sense and we’ll know without much trouble where any given content came from. Whether dynamic or static or user-added etc.

Maybe my hopes are too high! I don’t know. Lots of CMSes exploded onto the scene in the last 5 years but I haven’t seen one of these new guys really get a foothold or solve the difficulties. I’ve tried many of them but haven’t felt comfortable yet.

Maybe I should build my own! lol

WordPress is just a tool for me. I use it, I don’t let it dictate to me. But I do make use of the features and functions that it makes available to me. It allows me to build solid, robust (not hacky) content management systems for my clients. And I keep things simple and straightforward - no extra bells and whistles just in case, like a lot of theme developers provide. I don’t really care whether I use it exactly the way it was meant to be used. If I did, I would just build blogs with it.

There has been a history of so many problems with plugins, that I try to stay away from them as much as possible. And no, I don’t use plugins for custom post types. I code them myself.

Of course there are issues with all CMSs out there, including WordPress and with all website and page builders. WordPress is not perfect by any means, but it does the job I ask it to do for me. And the result is a website that my client finds easy and intuitive to work with.

When you say you believe a CMS should be functional out of the box, are you referring to functional for the developer, or functional for the client? There is a big difference there.

By all means, build your own CMS. That is a huge undertaking, but a great exercise in producing something that has all the good parts of what is already out there, and none of the bad parts. Isn’t that how the framework Laravel got its start?

Hi Zac,
I sympathise with a lot of what you said. Despite Wordpress being the most popular CMS solution out there it leaves much to be desired in terms of its internal mechanics and how it has been developed, as well, as you well put it, in how hacky building solutions for it can become. But this happens with pretty much every open-source CMS platform out there. Drupal is more powerful and flexible but also is a lot more of a beast and it all can easily end up being too slow or screwing up.
The thing is building CMS is not simple at all, so most of the platforms come up with a base solution that doesn’t really do much, and then you can extend that by installing 3rd party components. And I think the trouble is that there is no real quality or growth control for these 3rd party components so you’re always at risk that things will break up or do not work as expected or how you want them to work. But I guess that is the con of free and open source software.
I have been working with the most popular CMS solutions for about 6 years in different agencies, and I have been building custom CMS solutions for my company for the last four years.
In the end I am as frustrated as you are and started building my own about a year ago. I did so pretty much for the sake of learning, but also to explore and put into practice my ideas, and possibly business in the future, and also not to have to follow anyone else’s requirements, just my own. I wanted to build not just a CMS but a framework and development tool that eased the way for me to build websites, whether through a database and CMS or just through static class files or both combined. So I’m a good way in and so far I’ve put a lot of effort into making it easy to build forms because they are a very important part of a CMS, and that would allow me to make a form builder and a field system, much like Drupal has with content types. And I think content types conceptually are a very powerful and necessary part of a CMS, but also a pretty complex one to build, and that’s why maybe it is not part of the core of any popular open-source CMS out there. A CMS has one million parts, and some really complex ones too!
I’m having fun and learning lots but I do see how hard and how much work is to manage building a good CMS. They haven’t been around for a long time and they’re still evolving, and that is one argument more for me to go and reinvent the wheel, but of course try to reinvent a better wheel.

1 Like

I’m philosophizing whether it can be both.
With the patterns used in modern websites, there just isn’t much space for old school blog-style sites where a developer designs everything and then a client/user puts some paragraphs in a wysiwyg box in the middle of the page.

Page builders are the future, to whatever degree. As well as responsive designs, full width mixed with max-width blocks, and 3rd party integrations such as maps and forms.

When you install a fresh copy of WP, the default theme and a few posts will get you a blog, but out of the box, WP is not very secure, fast, SEO optimized, etc. At best, a user can place a few extra bits of content in the default widget locations.
All I’m saying here is that WP out-of-the-box can do blog stuff for an end user without a developer needed. But a developer can’t necessarily develop without a good understanding of how WP works, nothing whatsoever is intuitive. All those functions that are necessary, header, footer, sidebar. Meta data inside the CSS file. A develop cannot simply be given a blank something to start putting HTML in, they have to already know how to setup and configure a blank theme and how the file system waterfall works and what sort of file is needed. How to determine front page versus home page. How sidebars are not just sidebars but can be whatever chunk of code. Nowhere is it intuitive how to tell your new theme/design to enable theme “features” or create widget and sidebar locations in code.

Well obviously they need to have some docs open to work through it, but my general point is that the CMS gives no real guidance, nor is it intuitive, how to build a fresh site. This is not the case in other CMSes, where they perhaps have a blank template file already set up. It’s intuitive, just start putting HTML in the template. No weird CSS meta data and file system waterfall crap to figure out. Just build templates.

So all that to say, the “CMS of the future” will make it more straitforward how to either begin entering content, or to start with a fresh theme/templates.

But learning curve is not really my issue, every CMS has some degree of learning curve, but on WP, you can’t even accidentally click around and stumble on how to build a fresh theme, there is too much weird magic going on that must be learned. And don’t even get me started ranting about “theme frameworks”!

The bottom line is that in today’s world of page builders and drag-n-drop widgets, there is a ton of stuff in the control of the user. But this leads to a huge problem of bloated code and turns the developer into a hacker who must spend their time overloading files, resetting styles and making things work in the overall design. The developer, rather than develop, gets to tinker and fix instead the output of automation tools.

Just try to develop a WP site based on SASS and Webpack. It all breaks as soon as one plugin is needed. The developer already starts to lose control and must now tinker with other people’s code. Maybe that’s an insurmountable problem, but a problem nonetheless.

Again, I didn’t come to write a bash WP post. I’m just trying to imagine a new philosophy and structure of CMS. Something big is around the corner. Somebody is going to strike gold.

The wheel needs to be reinvented I think.

Let’s take one micro concept, a major one really, which is plugins. Plugins are module systems that contain their own logic regarding data storage, interfacing, output, business logic, styling, etc. But beyond a few basic function calls to hook into a system, they have very little control over how they operate.

What if instead of plugins being willy nilly coded, they were forced into a specific structure? How would this help? Well the CMS could have a common interface for editing the variable settings of the plugin and all the data it needs to work. The CMS could be in control of the template system needed to output the content so that the end user or developer could clone/adjust/tweak the very template itself. Or perhaps a plugin would have no template?

What if all plugins were required to be APIs instead? The data handled in the CMS, accessible to the user, and only the API exposed so that the content can be injected into the template as needed?

This is really a separation of concerns concept. If plugins where separated between their data storage, API, logic, and output, the CMS could inject itself everywhere in the flow, for whatever purpose. Filtering, logging, security measures, encryption, event management etc etc.

Not only that, but if plugins/addons were required to fit the structure of the CMS, this would make it easy to use tooling for actually building plugins in the first place. Need more data, click. More logic, click, more events, click, plugin done.

It would allow the CMS to more easily build refactoring code so that things can be updated and give plugin creators time to adjust to new stuff.

This structure means, to some degree, the CMS can handle conflicts between plugins better, detect inconsistencies, track bugs.

It means the CMS could even monitor and manage things like permissions control. I.e. “this plugin wants to do XYZ with your data”, and it would know this because the plugin has to register every sort of API and event it needs access to.
This would solve the rogue plugin problem like other CMSes where if you install anything at all, it immediate has full access to everything everywhere.

I have no idea if a structure like this would make a CMS plugin architecture better or not, but it’s a unique approach that could solve security, performance, design, template, and comparability issues. Maybe.

I’m just playing a mind game at this point. Dreaming of the perfect CMS.

If there were a tool out there that did the job better than all the available tools, I would definitely use it instead of WordPress. Like I said before, I believe a developer should be able to use a tool in a way that suits them, not be dictated by the tool as to how to use it.

You have a lot of good ideas there. After some more discussion (I hope others join in here), it would be interesting to gather together a list of all the specs an ideal CMS would have and actually start building it. I have complaints about all three of the top CMSs out there, but WordPress has worked best for me so far. However, I would not hesitate to jump ship to something better.

There is always room for one more CMS.

1 Like

I’m in!

That’s the sort of stuff I’ve been doing for the last 10 years with ExpressionEngine, and more recently Craft CMS. It’s nothing to do with a “next evolution”, the evolution has been here for many years already.

1 Like

A portion of the answer is that we need a variety of protocols and formats. HTML is a very weak link in all of this. Another portion of the answer is for internet applications to work more like desktop applications.

So let us back up. When I first began programming punched cards and magnetic tapes were prevalent. I first learned programming on a computer that used magnets for main memory. Most all programs were “batch” programs, similar to what is now called console programs. I have lived the history you are confused about.

HTML began as a word-processing format. You say that HTML and CSS were used originally. Actually it was just HTML initially. It is not clear when Perl began to be used when the first browser became available. Java was first released in 1995. PHP began to be used in the late 1990s and ASP was first released in 1996. The CSS level 1 Recommendation was published in 1996 but CSS was not fully supported until 2000

CSS does have classes but they are not object-oriented. We need an object-oriented UI like desktop systems have. There is absolutely no reason that can’t be done in spite of the internet being constrained by client/server requirements. CSS was not in the original design of HTML and I assume that is why it is called “cascading”; it is designed to not be integrated. We need a UI with better integration with the processing and the rest of the UI.

The internet is not designed very well. The design is more about something that just happened and then grew without proper designs. We need at least two systems because there are conflicting requirements. We need alternatives to HTML format and the HTTP protocol.

HTML is too limited for use as a word processing format. One feature that is not easily supported by HTML is proofreading and related features. HTTP is limited in that it is stateless.

One reason Wordpress is limited for purposes of applications is that it was designed to be more of a word-processing (blogging) system.

Do you know how PHP and Microsoft’s ASP work? They are essentially a CGI. The basic way that CGI systems work is that a form is submitted, some processing is done and then a HTML page is returned to the client. PHP and ASP are different in that the file type (such as “php” or “asp”) determine that the CGI is executed. CGI is good because the first thing that happens when the form is submitted is that a program is executed but CGI is limited by the HTTP protocol.

So look at desktop systems. That will give you an idea of where the internet should go. Internet applications should be developed more like the way that desktop systems are. One possibility would be to create a version of the Android UI for use in the internet. I think that is generally where the technology will go but people will have difficulty thinking like that.

In some ways I miss the days of Applets and ActiveX. I was just getting beyond newbie level and starting to be able to do some interesting things but security risks quashed progress in that direction. I don’t know if it could ever be possible to trust websites to access OS files but I think if it could be it would save a lot of bandwidth bottleneck issues.

I think applets and ActiveX and Flash programs and all those sorts of object embeds was the industry trying to solve the same problem.
We want desktop-like ability and performance from websites. Even so far as having compiled executable programs. The programmers want all users to have the same experience on all devices.

But there is a part of me that wants things to stay as they are, fully exposed html/css/js/whatever.

To some degree, all CMSes do these things, because they have to at some level. But the problem I’ve seen when testing and using so many, is that they make it so freaking difficult, or hacky, or can’t manage it via CMS GUI alone, etc. To do something as simple as create a new data store for keeping some kind of custom data, is very difficult. In some CMSes there is no way to do it via the CMS itself, you have to go edit the database and create the tables yourself.
In another, you have to use extra tools or CLI apps to generate data maps or whatever is needed for their ORM to create the data store. Or maybe another requires you to define the new data as a class model, and perhaps gives you a generator tool if you’re lucky.
Whatever the case may be, none of it is intuitive or feels very “native” to the design of a site. It’s almost like the developers of the CMS were like “what do you mean people might want to store custom data? Who does that?”

And for those CMSes that do make this process a little easier, it tends to not be safe. In other words, there isn’t a clean process for adding data, or backing up previous data, or reverting changes, etc. Install and uninstall routines may or may not be programmed at all within a plugin. I’ve seen too many WP installs for example, with completely orphaned DB tables from old plugins long gone because there was no routine for getting rid of the data.
In fact I think in WP this is done on purpose. A plugin could be removed and added again without losing data. But is this the best way?

This is why I do wonder if a CMS actually should be much more rigid in structure, forcing plugins to play by the rules specifically to avoid sloppy programming, lacking uninstall routines, unsafe data management, unbridled access to every part of everything even if the plugin doesn’t need that kind of access.

This also means the CMS has to have some kind of control over the supply chain of apps/plugins/addons. Namely, an app store style, where apps go through additional analysis. Where things like digital signing could be used.
I just read this article this morning: https://www.wordfence.com/blog/2017/09/coordinated-plugin-spam/

It’s easy to just say “let’s build something where this can never happen” but that’s wishful thinking. I’m trying to figure out if it’s possible at all for it not to happen.
Just yesterday I spent over 5 hours with a client peeling over their Wordpress site and removed at least 3 backdoors and attempted changes to steal money using Stripe and Paypal. The bad actor simply installed a plugin, and left a backdoor in functions.php to log themselves in as any user.
Now on the one hand, if a bad actor has access to your file system, they can do whatever they want. And if they have administrative access to the CMS, they can install what they want. So this perhaps was not avoidable. But it does raise the issue of asking how a website owner can protect themselves in this age of micro-services and freelancing. It’s awesome that we can pop onto some website and hire a freelancer for a few hours and then drop them. But how can you be fully protected against them at the same time?
I don’t think this has a very good answer. Because I had another client so careful about security that they only let me work by remote logging in to their computer on Team Viewer and watching me do it, while they screen recorded everything! It was super weird to work that way, but they felt no security any other way. They had no way to feel safe that I wasn’t going to just ruin their WP site, install backdoors, change something important, or delete all their posts?
Even the idea of taking a full backup before I worked doesn’t help, because if I DID install a backdoor, how would they know? How long would it be that I could mess with their site before they ever noticed or could restore the backup?

This leads to additional wishlist for the CMS. Very finely grained access by logged in users. Perhaps a way to “snapshot” the CMS in a way where the website owner would be able to know exactly what files and data have changed in a given time period. Advanced or detailed logging and so forth. If there was some way in Wordpress where I could simply look at how the site was a month ago, to know exactly which files were changed and when, it would have been a 1 hour process, not 5. But this is their own fault, they didn’t have that many backups, I didn’t have anything to compare against, which makes me think it would be cool if a CMS could snapshot its own self to track changes.
They used DIVI theme which has a very large functions.php file, like 9000 lines. I only found the backdoor by using a text compare tool to compare a clean install of Divi with theirs and found the little 10 line added code block.

How can we always be sure that the CMS core is not compromised? There should be a way for us to quickly run a “self check” to make sure all the core files are as they should be, listing any changed, added, or removed files according to the CMS version. VBulletin forum has a feature like this, and tells me any additional files it finds that are not expected, and lists any changed files.

We all know that in today’s world, you can get hosting for $3 dollars a month, install Wordpress in 3 clicks, grab Woocommerce and a free theme, and be able to take people’s money within an hour. On the one hand, this process is easy and cheap, but potentially very risky. If I hire a freelancer to work on my ecommerce shop and they sneak in and change the Paypal email where I get paid and thus steal some of my orders, well, that can perhaps be fixed and sorted out, but at the same time far too easy a thing to do. And perhaps not very easy to fix if the bad actor is overseas.

If I hire a freelancer, maybe I don’t want them having access to change certain things. But this granular control that extends even to plugins themselves, is a huge problem, maybe unsolvable. If a bad actor has access to the files or directly to the DB, then they can do what they want anyway I suppose.
But from within the CMS itself, a website owner should be able to create a user account, giving them access to only the things they are meant to work on.
Or alternatively, perhaps the website owner just turns on some kind of advanced logging and analysis on a given user, and then everything the user does is monitored, recorded, and reversible.

This is just wishful thinking I know. Perhaps these things already exist and perhaps they are so complicated to manage that they go unused. In today’s world it’s not hard to use a hosting company where you can simply snapshop or backup everything in its entirely every 10 minutes if you wanted to. Maybe that’s the answer? Just have completely open CMS/software/data where everybody can do anything, but we protect ourselves through constant backing up? I don’t know about that. Of course we need backups, but backups tend to be all or nothing. Restore the entire site or find a way to pull out individual files. Not so easy with the database in that sense. And not so easy to run a comparison of the live site to a backup to see what has changed.

Imagine a backup system where the CMS itself is in control. And now imagine that you wanted to erase all the changes done only on last Saturday, but not before, and not after. Maybe this is because you hired a copywriter to do some fancy SEO editing of pages, and they edited 28 pages and now you notice days later they sucked at it. Maybe you only want to revert Saturday’s changes but not those you made yourself since then?
Sure that’s a hypothetical, but if the CMS is keeping its own record of changes, why not?
Why not have a rollback feature where you pick one or more time periods and then tell the CMS to revert changes just to XY content pages? Or even to provide a more Git-like compare ability, like show me the difference of this page at this time versus that time.
This would create a much larger database to store all this, but I have a feeling that data storage is not our highest concern.
And obviously a website owner could turn all this off, or clear out storing of data past a certain age, etc. Maybe they turn it on only for a time where they hire someone to make changes, etc.

And boy is it fun to dream!

Quite a few years ago I started writing a WordPress plugin that iterated through files and stored their hash values. The script could iterate on demand and compare values, identifying any that changed.

It worked fairly well, but then I got lost in feature creep (saving “*.bkp” copies, automatically replacing changed files with their backup copies and sending me an email) and WordPress made a major version jump (to multi site) that broke a lot of it and I never finished it.

Around the same time, a bit before that actually, I wrote a plugin that found “orphaned” database entries left behind by plugins that didn’t do a proper uninstall cleanup and provided the option to delete the rows. Then RL and the change to multisite (instead of checking one folder and one table, now possibly many) got in the way and I’ve never gotten back to maintaining it.

I feel like these sorts of things should be in the core because it falls under the category of self-protection and correction. Or essentially maintaining the integrity of the very software and data itself.

IMO those are cool ideas which shouldn’t be given over to plugins.

1 Like

I agree with this and what you mentioned about having interfaces that would handle that kind of stuff.

For me a good core should have the following:


  • Scalable and extensible application architecture with interfaces that handle all common stuff, for plugins and modules, pages, page components, database objects… and factories for each kind of object, accessible pretty much throughout your application, which deal with the instantiations of these objects and storage in order to avoid running redundant operations.
  • A data API layer that takes advantage of the database object interface and factory.
  • An database ORM for producing filterable lists of results
  • A form class that makes it easy to build forms, with a field interface and field objects for each field type.
  • An ‘easy’, powerful and flexible way to build the backend programmatically
  • A good plugin interface for 3rd party modules

CMS Features:

  • A form builder and the ability to create custom content types with custom field types for any kind of content or media.
  • Access lists and user specific permissions
  • Categories
  • Menu builder
  • (Page) Component builder
  • Page template builder
  • Themes
  • Easily extensible settings page

These were the first that came up in my head, I must have missed many and feel free to suggest any more…

I’m sure there are a lot more.

In my head I’m organizing things into a few categories.

One is the balance between the user content and the developer content (i.e. templates and such). Where and how does content get assembled, organized, arranged and parsed for output.

Another is security based, with a very robust user management system and fine grain access control. The very same user management API could be used for just a single admin user, to a giant forum with 2 million users. One user management API should be able to handle any situation involving user control.

Another is GUI based. As much as I think CLI tools are cool, there is little reason to use them except for remote management, automations, scripting, etc. All features should be usable with a GUI interface, as well as accessible headless using just the API or CLI tools if desired…

Data management. The CMS should make no assumptions about the data someone will need to store for their site. They might require a few basic things like an ID field and timestamp fields, but otherwise users should be able to generate and create any kind of data structure they need. Data used by code, data attached to user accounts, data attached to global state, templates, pages, or anything else. Any data should be relate-able to any other kind of data. And an audit trail should be possible so that the system could always track what kind of thing changed/added/deleted/updated at any data at any time.
If I create a custom data set to track car sales, it should not be too difficult to link that to my user data so that I can store which agent sold a car.


Let me explain another problem I’m having with ProcessWire, not to keep talking about them, but it’s something I’m working in at the moment.
PW is very good in the “add custom fields as needed” department. You create a template and then attach all the fields you might want to it, and the end user can edit those fields. Then you edit the template to make use of those fields. So far so good. You can even create many WYSIWYG fields for different content sections on a single page.
But here is the problem, it’s still heavily focused on the template design where to put these fields.

Let’s say I create a repeatable field for something like customer testimonies. And another field for something like “our clients”.
Great, I then add those fields into the template.
But now the end user decides they want the testimonies to be up top and the clients to be at the bottom above the footer. Welp, can’t do that! Because the fields are placed where they are placed in the template, not in the GUI. So the end user can edit content in the fields, but don’t have control where the fields show up in the output. The developer has to change this because it may require major changes to the HTML structure.

Compare this to Wordpress using shortcodes or widgets, you can easily move a shortcode to a different spot, or change the position of widgets in a sidebar. Not so much with PW.

If I were to have my way, I would have custom fields, but also a way for the end user to make use of those fields how they see fit. If all I’m doing is creating a bunch of fields which act like rows, or widgets, then why have a rigid structure of defining exactly where those widgets and rows go hardcoded in the template? To me, the hardcoded templates should be little more than very basic structures defining major content areas like header, footer, sidebar, etc. But what appears in those general sections should be controlled from the admin somehow.

This is perhaps not an unsolvable problem in PW. I’m sure I could create some kind of logic, like a custom field for defining a field order, and then parse that custom order field in the template logic and move pieces around. But as always this stuff gets very hacky very fast and doesn’t feel like the way things are supposed to be.

I had another website with an interesting layout. They had a regular old page where the text content would be broken up by full browser width images or blocks. This was impossible to program in a normal template because if all I’m doing is outputting a “body content” custom field, the template is going to contain the grid logic within. In other words, the template already defined a CSS grid with limited-width column for body content, so there was no way to mix full-width content and limited-width body text at the same time!
I would have had to create a ton of custom fields like fieldtext1, full-wdith1, fieldtext2, full-width2, field-text3, full-width3, and so on, just to make it work in the template. OR, i would have to NOT put any of the CSS grid into the template, and keep that in the body content field itself. Perhaps using something like Wordpress shortcodesor editing purely in HTML rather than WYSIWYG mode.

Why is that such a hard problem? This is solved in Wordpress by either elaborate shortcode schemes, HTML mode, or page builders. Because a page builder lets you stack “widgets” on top of each other and define rows and columns. The widget itself outputs the necessary HTML structure, whether full width or limited width, etc.
But page builders are 3rd party plugin tools and are fraught with problems of their own! Namely, developers like me have no control over the structure of the output in the first place! Nor the CSS used by them.

So perhaps ideally my dream CMS would have a page-builder-like functionality, but within it, template code that is editable, using whatever CSS I create for the site. In other words, makes no assumptions about anything, but rather just providing the functionality of page builder drag-n-drop layout for the end user.
The developer would define the widgets and blocks and output templates and so on. The end user would just make use of whatever sections and widgets the developer programs for them to use.
I don’t know how this would fit with the idea of being able to have a plugin system and install new things, but one problem at a time!

I care a lot about what the CMS eventually outputs, and I want as much of that in my control as possible. Even things like the CMS automatically adding wrapping paragraph tags bug me. There are many times I don’t want that and it’s a hack to turn it off, rather than a simple setting somewhere, like in the output settings of the field/content itself.
I mentioned earlier in this thread, if plugins were required to separate their API/controllers from their templates, this would make it easier for developers to install plugins and then adjust the output of the plugin if desired.

The day I use a CMS that just works the way I want and I don’t have to feel like I’m hacking it to pieces to make it behave, will be a wonderful day indeed!

1 Like

Yes this can be solved by having a form interface which holds the settings for that form and stores them in the database. Then you have a field interface with its own field options in the database. Each field type will extend the base field interface options. Then in order to leave the field open to be reusable across different forms you have another table which will relate the field ids to the form ids, and in that table have another field for ‘order’ or ‘position’. Much of the rendering should be programmatic in order to allow these kind of things to happen. In my apps there is programmatic rendering by default, keeping templates to a minimum but always allowing the developer to override the default output with their own custom template or options if needed be.