4 Answers
4

For our web projects, we use a custom built content management system that uses a back-end database with a web-based console for management. Here's why:

Moves with the site - If the customer wants to move their hosting, there are specific requirements for hosting and the entire site along with its management features can be moved at once without having to reconfigure external tools.

More secure - There is a single point of entry: the admin login. No need to make the database server available to the outside world or have FTP access enabled all the time (only when code updates need to be pushed out).

Accessible from anywhere - If a client needs to make a change, they can log in from any web browser and do the change without having to worry about external software or opening holes in a local firewall, etc.

Flexibility - Since we have access to all of the code and database, we can make whatever we want on the site manageable without being constrained by the limits of whatever installed external software. Changes can be rolled out quickly and apply to everyone immediately.

The cons to using a system like this might include:

Training - With a proprietary interface, some user training may be needed. You're likely to run into this with any content management software though, external or not.

Speed - Using a web interface may not be as fast as using a native management application can be.

We've got a very large Plone installation. I'm not a giant fan of Plone because it's based on Zope and Zeo, both of which can be giant hogs as far as resources go. You also need to have a load balancer and squid in front of Plone in my experience if you expect any level of performance.

Personally, I like and have used most of the PHP-based CMSes, blogging software, etc.

From a security and scalability point of view, the type of software that writes static HTML files up to the server is easiest to implement on a broad scale (many sites, many users) -- whether it's web-based or client-based. You can host sites that way with a minimum of resources.

If your needs are small and you want to go dynamic, look at Wordpress. It's more of a CMS than a blogging tool at this point and has a really rich feature set, template set, and plugins, and is relatively easy to develop for.

If your needs are larger-scale, then you're going to get into systems like Plone. Plone met our needs because of it's rather extensive ACL system.

With any tool that has a broad user base, you're not going to run into a situation where you have major security holes sitting out there in the open for long. I'd be leery of anything that has a very narrow scope or a tiny user base. For the same reason, I'd be leery of rolling my own when SO MUCH work has been done already to develop and secure this kind of system.

Why would static HTML files be easier to implement/secure? I would think that would be akin to granting access to your file system?
–
Rob AllenJun 5 '09 at 18:24

In the situation we were working with, the files were on a read-only NFS mount that was written to by a hardened server secured behind a VPN. From the public internets, there really was no way to edit the files.
–
Karl KatzkeJun 5 '09 at 18:33

1

I set up a small Plone site, and it is nice for users to work with.
–
Clinton BlackmoreJun 5 '09 at 19:25

I've used Plone in several contexts, and have not seen the resource-hogging (since 3.0), nor has there been any need for load-balancing or squid to be in front of it. What kind of hardware are you on, and what version of Plone?
–
warrenAug 27 '09 at 4:07

warren: mix of some 2.x and 3 sites. We're in the process of migrating to 3. It's better than 2.x was, but still can be a pain in the butt. 3.x definitely still needs squid for the number of sites that we have in our main instance. If you have 1, fine -- we have several dozen. Some of the products we've had to use to respond to user requests are poorly written, which also creates it's own issues and we've had to silo those off to their own instances.
–
Karl KatzkeAug 31 '09 at 0:49