I have been creating my own Content Management Systems since the mid-80s, and web-based content management systems since 1998. Some were really simple; others developed into fairly complex software packages with features the big players are only now implementing.
I’ll admit to a bias against widely distributed web design and management platforms which I mostly experienced early on in the Internet age. Issues with ancient packages like Microsoft FrontPage, Adobe PageMill, GeoCities, and Anglefyre, to anyone who remembers them, have become fairly obvious – the slow-running, bloated code they would produce, for example. Another problem, on a wider scale, is a theme-based platform where a lot deep customization requires far more work and investment learning the proprietary system du-jour than if the developer had just started building the site from scratch to begin with.
My more recent CMS experience is with .NetFusion, Wix, and Volusion on sites that I took over. The .NetFusion site had the slowest back-end I have ever encountered, sometimes taking minutes to update something as simple as a product’s price and almost 15 minutes of multiple-page load time required to relate two products to each other once the site had a significant amount of content. Like most of its predecessors, Wix suffers from page code bloat and severe slowness – a product of it’s drag-n-drop design interface. Although it has speed, and Volusion is pretty easy to customize the appearance, underneath it all is a hacker’s paradise. On the one site I took over, around 90% of the traffic were bots successfully exploiting easy weaknesses that just shouldn’t exist in modern software.
With all of them, the search function has much to be desired. It’s a CPU resource drain for a CMS to account for misspelling, so software programmers limit keyword usage to “exact.” This also means that if there’s a dash in a product name and the user doesn’t type it, that product just won’t show up in the results. It also takes server CPU power to sort by relevance of how two search keywords are in relationship to each other, so many don’t do that, either. Also, it can be important to weigh results differently depending on what fields the keywords are found in, such as in an article’s headline as opposed to in the article, itself. There are so many tricks to increase the accuracy of results, both for what the end user wants and what the website manager wants to give priority to, that are lacking in all these distributed CMS packages — simply because the processing time can be a little slower. If you build your own search engine, customizing this is fairly easy. You are in control of how many CPU cycles you are willing to add for more accurate results.
I have created this site in WordPress simply to get the experience and use it as a sort of sandbox for other WordPress sites I manage.
One of my WordPress sites I had to move to my custom platform because it would have taken longer to program a WordPress Plug-in for a very basic feature, one that could break at any time with an update, than to start from scratch.
I did incorporate some of the things I learned working with WordPress into my custom platform: mostly just added WYSIWYG capability and URL slugs/shortcuts for content.
It still appears like a WordPress site when you look at the code sent to the browser, so people try to use whatever exploit they know or recently discovered. However, I get notified whenever someone tries to hack my platform, as well as anytime anyone does something even remotely suspicious, and I can block their IP instantly.