Comment by rquantz | Hacker News Reader

Comment by rquantz | Hacker News Reader

I've been thinking about what should replace Wordpress in the CMS space (as opposed to blogging). There are a lot of aspects of Wordpress that make it great, and a lot of things that make it absolutely terrible. I think part of its problem is that it seems intended to be a platform that non-developers can maintain themselves, while presenting features that really require a developer. As a result, it is not a suitable environment either for non-coders or coders.

I'd love to see a platform that is easily deployed on shared hosting (written in php, using mysql) but that lends itself better to version control and switching environments. It should keep configuration in plain text instead of in the database, and it should allow easy definition of node types in addition to the standards (post, page, comment, etc.). These should also be defined in plain text instead of in the database (I'm looking at you, Drupal). Meanwhile, theming should be just as easy as with Wordpress.

Anyway, it's good to see others trying to enter the blogging platform space and compete with Wordpress, but I really want to see a truly good CMS come along.

Why PHP and MySQL?

JavaScript, since it is the only thing that runs in the browser, is a much better choice since the barrier to building and maintaining a site isn't too far from the reach of a novice because only one Turing complete language is required.

With respect to MySQL. Given what WordPress does today and all the other options out there, is WordPress still the best tool for the job?

Why not Postgres or MariaDB? Or how about NoSQL options? Is there an option which would permit development to be just as easy, but that avoids the security complexity of a database exposed to code injections because it execute arbitrary code snippets?

Because almost all web hosts have php and mysql already installed. They would not necessarily be my first choice for any application, but for a widely disseminated CMS, I still think those are the best choices. I'm open to being shown I'm wrong, though.

There's a NoSql db on every host as well, the filesystem, and it works great for documented oriented sites like blogs.

Yeah, but doesn't the default number of open file descriptors limit how scalable such a solution is as a default to rely on?

Only if your number of pages exceeds the limit (assuming that you're serializing access to the files) ;)

I highly doubt that's an issue you'll ever run into on a blog.

True, but it's not hard to roll an entire self-contained bundle for which you can find a host.

Back in the 1990s, LAMP was the most widely available stack and finding reliable alternatives for which you had enough information to make an informed decision was hard. However, we are now far beyond that monoculture and there is enough information asymmetry that you don't need to choose a stack based soley on what is common and available. There is enough variety out there and the tools for deploying without having to rely on your hosting company's stack are good enough that we can have something besides LAMP become popular enough for hosting businesses and OS creators decide to include the the necessary dependencies as default.

Exactly, a new CMS should drop sequel and move to mongo or a similar document store. Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS.

MongoDB is definitely not a no-brainer - what actual benefit is there to being able to 'arbitrarily add fields to a page'? The whole application layer has to support an arbitrary schema anyways, which is bound to be a security and config nightmare.

Look at the mysql schema of a Drupal system. Either you support arbitrary fields at the database level, or you write a ton of extra code (which will have bugs) and piles of support tables on top of your relational database. It's a waste of time and effort and adds unnecessary complexity.

I still don't think the correct solution is to just give up on the relational model and store a bunch of denormalized documents. Just because Drupal has technical debt (which is not surprising to me) doesn't mean it's impossible to model a CMS in a relational way. Can you point me to a particular part of Drupal which is well suited to the Mongo document model over relational, versus simply 'well it's relational now and they cocked it up'?

Drupal has been moving towards Mongo, IIRC.

> Exactly, a new CMS should drop sequel and move to mongo or a similar document store.

Presumably, you are referring to SQL when you write "sequel"?

> Being able to arbitrarily add fields to a page, enabled by a store like mongo seems like a no brainer for a CMS.

You can do that using SQL-based databases, so its not really "enabled by mongo". With most SQL-based DBs, you may have to use a data model other than "one page is one row of one base table" to do it, but that's simple enough to do. (With Postgres, there's several ways to do it while still using a "one page is one row of one base table" model, as well, leveraging the XML, JSON, or Array types to hold the "flexible" fields.)

Check out dokuwiki. It's PHP, but it's good.

   data/pages/folder/file.txt  -->  site.com/folder/file

publishing means to sync your localhost data/pages with the one on your web server

There have been a ton of CMS's written I think the problem is just adoption. Without mass adoption you don't get much in the way of ready extensibility. Thats one area wordpress really has the space on lockdown.

Are there any other CMSs that are actually better than WP but that haven't been adopted? I've seen some that are intriguing, but ultimately most seem to have the same problems, such as stored configuration in the DB.

I've been using ProcessWire, and it's been fantastic to work with. However, it stores user-defined template schemas in a MySQL database. Does that pose a big problem for you? I'm really curious to know what kind of troubles you've run into with configuration in the DB.

It poses a problem for deployment, collaboration, version control, etc. For instance, a new data type (not a problem in WP, but you could substitute meta fields or something) will frequently require some new code as well -- a widget, template, or whatever. Once I've built this in my dev environment, tested in the staging environment, and deployed live I will have had to set up the new data type in three different places, or written a script that does it, but most CMSs don't provide those tools, so you would be stuck hacking around with internal functions that might or might not be stable. Meanwhile, any other developers will then have to replicate the same changes in their dev environment.

Version control exists to solve these problems, but when this stuff is stored in the database it is a lot harder to consistently reicate changes. I'm sure people come up with solutions that don't involve replicating configuration in the GUI, but my point is it should be baked into the CMS.

I think Laravel 4 would be a good start for something like that, with Twig as the templating engine. Use as many existing, open source solutions as possible.

Without too much effort you can integrate composer, symfony and twig into wordpress to make it more developer friendly. Hell I have all my wordpress installations maintained through a composer script with phing integration so I can maintain my plugins, themes etc... on top of a non-modified wp instance which makes it easy to update.

It's nice for those times where you don't want to reinvent the wheel just get some content up.

Sounds a little bit like Drupal 8... Configuration in yaml, Symfony components at the core, removal of a lot of the same NIH-related cruft that's weighing down most other mature players in the CMS/CMF field.

Reply on news.ycombinator.com