Hacker News Reader

I agree, I had a bit of a laugh when he called WordPress "grown up". I suspect he was just trying to be polite to WordPress fans.

I've had to deal with a lot of ugly WordPress hacks when maintaining legacy sites, and I'm convinced that anyone who defends it simply hasn't seen anything better.

Personally, I've been using ProcessWire for the last year, and I'm very happy with it. Although it doesn't do everything that WordPress does, it's extremely clean and simple to work with.

Most of my freelance work has been "saving" fairly new WordPress sites that just haven't worked out for clients.

I think you're absolutely spot on when you say that it's mostly people who haven't seen any better. There seems to be a real cult behind the use of WordPress as a CMS, and after working with some of the developers that have delivered the first WP sites nearly every single one of them seems sold on WordPress being the only tool required to rapidly build a website.

As a tool, WordPress does work, but the plugin-driven development nature of WordPress leads to some horrendous problems, ones that were solved years ago on other platforms. It also tends to attract a large number of poor developers.

More often than not, I use Umbraco for sites that need a CMS, or Django when the site has been hacked to handle an application, almost effectively scrapping most of the existing code, and the clients are always happy and have a much faster website.

I'd also suggest everyone to give ProcessWire a go. It has a really nice API and works nicely behind Varnish.

I completely agree with this. It's my go-to CMS for almost everything these days. I've yet to really hit any problems it doesn't help me easily solve.

Even a client completely changing their mind about site structure part-way through is rarely a headache these days. It just works perfectly for 90%+ of all things clients pay me to do. The final code is generally also very clean and well structured as well.

Serious question: Have you used Wordpress before? For what it lacks out-of-the-box 9 times out of 10 exists in the form of a plugin (sometimes multiple plugins). I don't see what Wordpress lacks personally other than a coherent file structure and clean codebase...

I'be be much more interested in a new modern, flexible CMS built for that purpose from the ground up than I am about a new blogging software.

Sounds like you're talking about Drupal here or ExpressionEngine which are both great and well-written content management systems. Wordpress serves many purposes, clean code doesn't matter so much at the end of the day unless you're a code purist who thinks languages and conventions matter if the end product works and is usable.

>clean code doesn't matter so much at the end of the day unless you're a code purist

Or you're unlucky enough to have to build a theme/site around wordpress

We build hundreds per year. Is it a huge pain in the ass to maintain a theme with 65 plugins that's 3 releases behind? Of course! But hey, that's part of the job.

Not all plugins are updated with the core program, plus compatibility issues sometimes, so it is not the same.

Isn't the problem that the end of the day never comes? A site is never 'done'. It always needs to be changed and this is why 'clean code' matters. It reduces the cost of change.

What would a proper CMS have in your opinion that Wordpress lacks?

I've actually contemplated the idea of doing a node CMS for use on client work. Wordpress lacks nothing, it is just a badly designed architecture with an inconsistent API (for example there are 3 different functions to display a 'loop' of posts, each one has options worded slightly differently with slightly different effects)

Some things that would be good:

1. Contenteditable from the frontend- for when the client just wants to change that one sentence on the third paragraph on the product page or whatever. http://createjs.org/ seems to be a pretty good ready made solution.

2. Repeating layouts- I design and code a repeating element (like photos on the team page or whatever), and the client has an interface to add or remove units, at which point they get updated wherever they are on the site.

3. NoSQL db. SQL is good when one is balancing the books of a large corporation, or doing a survey of the heights and wattages of every streetlight in the country, but it is not a logical solution for displaying documents on the web. It would also be really nice to have a database that could be put in revision control and deployed along with the rest of the site files, as the line between content and templates on CMS sites is a very thin one. https://github.com/felixge/node-dirty is intriguing, but I don't know if there are any unforeseen issues with this.

4. Blogging. Hopefully we could just integrate tightly with Ghost or something like it.

I'd keep the SQL database for where it shines -- structured metadata -- and push the raw documents to disk and let git handle them.

I posted about this last night, but this discussion is significantly more relevant to my new project, so I figured I would jump in and post again.

This is awesome because it's actually exactly something I'm building – a portable, open source, file-based CMS with a NoSQL document store, backed by Git, hosted in the cloud for social management/deployment, also runs locally. Eventually I'm planning to add easy blogging features for "non-techies" though my initial target audience is definitely professional, interactive web site developers who work with a big team.

If anyone is deeply interested in this space, I would love to learn more about your requirements and share more about my project so I can develop based on real user needs. You can also check out a data sheet I put together at http://grow.io. :)

Kinda hard to rationalize spending time learning a proprietary CMS.

Every CMS is proprietary once.

Custom fields similar to Drupal that doesn't rely on a pile of hacks would be a good start.

    new modern, flexible CMS built for that purpose from the ground up than I am about a new blogging software

I don't understand this.. Basically you're asking for a new codebase full of bugs over a stable codebase?

I don't buy this argument. This is only valid if you want something exactly like WordPress that grew up like Wordpress and has all the benefits and the baggage that comes with its unique evolutionary path.

It's 2013, we have a much better understanding today of how people use the web, from how they consume to how they socialize. Many of these habits are the product of things invented between when WordPress was invented and today. With that in mind, an experienced engineer familiar with the architecture of WordPress, it's history and the web as it exists today, would be very well equipped to choose a whole host of different abstractions at lower levels, which would permit a permit said WordPress replacement to support better features more easily, where better means "fitness for use" from now into the future (5-10 years)

Define "stable", there was an arbitrary code execution flaw in Wordpress just in the last version. A smaller, more efficiently designed codebase which isn't hampered by backwards compatibility might well have fewer bugs. Wordpress is kind of a sprawling mess at this point, and it's got bad practices baked into it.

What doesn't have these problems? Rails itself was not too long ago dealing with SQL injection vulnerabilities. Like stated by lukeschlather anything as widely used as either Wordpress OR Ruby on Rails is gonna have these problems.

any cms as widely used as wordpress is going to have regular RCE vulnerabilities. Wordpress core is well-debugged, and no matter how much better engineered a replacement is, it's going to have more bugs, even security bugs, for at least a year.

A replacement would be valuable if it could provide a better templating/plugin system that reduced the opportunity for bugs in template/plugin code.

Maybe. Choose the right language and "framework" (which for WordPress is Apache), and that language may enforce enough constraints to eliminate many many of the bugs possible and common on abstractions such as Apache, MySQL and PHP.

I know Apache is not a Framework, but a webserver. Here I'm using framework to mean operating system abstraction. Apache, being file-based and not data based first, means that it is full of abstraction holes that, while right for serving files, is all wrong for serving data and instead overly exposes the operating system for this world of dynamic web experiences we currently live in. If you knew back in the early 90s that the web would be more about streaming, real-time content, you would have designed a webserver that was designed for serving static, discretely changed content in a way that took advantages of as many features and benefits of the design of the Unix/Linux operating system (stdutils, etc.)