How To Choose An Open Source CMS 191
An anonymous reader writes "Content management specialist Seth Gottlieb has written an easy to understand how-to on selecting an open source CMS. Gottlieb is also responsible for the whitepaper 'Content Management Problems and Open Source Solutions' which summarizes 15 open source projects and distinguishes between open source CMS and proprietary software selection."
Trial and Error (Score:5, Insightful)
I settled on Drupal only because it was the "hot thing" at the time and I enjoyed the fact that you could put php code into "blocks" and have it run custom code w/o much hassle. At the time I wasn't all that much interested in working on the actual code so the "blocks" allowed me to get some of my bash shell scripts onto the site w/o doing too much hacking.
CMSes are going the way of the dodo.. (Score:3, Insightful)
Not for everything.... (Score:2, Insightful)
Re:Dokuwiki ! (Score:4, Insightful)
How to install SomeProject - This article is a stub, but you can help by writing it!
No thanks.
CMS is less important than people (Score:4, Insightful)
That being said, I like a comercial solution: ClearCase, (paired with ClearQuest) as it allows me to enforce a certain percentage of behavior through the tool. And when you have people who feel it's their duty to violate process because it "won't work" (they didn't write it) it's nice to have the tool lock them down.
Re:Avoid PHP for Web-accessible CMS installations. (Score:3, Insightful)
Security is a function of the developer, not the language. To be sure, some languages have inherent security features that can help, but if you honestly think it's that much more difficult to muck up a Perl program than a PHP program, I've got some land near Baghdad you might be interested in purchasing.
"Best" (Score:5, Insightful)
Here are some things that greatly helped me:
There is NO awesome templating system. If you have web designers and you have programmers, don't expect something to drop into place with little hassle. We have been deploying html + mod_perl applications using a simple in-house templating system. This is actually elegantly simple compared to some of the systems I looked at. It's all very relative to the staff you have. Personally a JSP taglib solution works best for us (so far)
There is no one "best" system. People claiming X or Y is clearly superior are either not deploying CMS for a group of users, lack experience as a developer/designer/user, or are just crazy. I know of a Major Company(tm) who management told to the developers use X system for some inscrutable reason after reviewing a lead dev's evaluation list. While on paper X is great, there are a few very annoying problems for the template designers, and they don't have the mandate to go modify the code, which is open.
Part of the evaluation MUST include every level of person using the product. Developers,designers,managment (reports n such), and end users (archetypal secretaries). I tried to let people know what was happening a few times a week with my evaluations, keeping a blog would be great maybe. Other people accepting your choice is super-duper-key. I got some great feedback from docs on a few occasions that helped me steer my choice.
Get a clear set of requirements and wish list items established early on. CMS systems can be minimal or very very comprehensive, it's easy to get lost in nth's implementation of webDAV or whatever.
Blog systems may have elements of CMS in them, but are not (usually) full blown CMS systems. CMSmatrix.org and other great places for data lump all the products together. In my opinion there are about a dozen open source products that are clearly way beyond the blog.
Last piece of advice which you won't hear very often: if you think you may not need a CMS solution you probably don't! If you have a single site, with some updating you need to do frequently or maybe you want to have a team of designers working on it, check out subversion first and maybe that alone will give you enough of what you want. If you just need templating check out apache's tapestry or cocoon projects.
The only perfect CMS (Score:2, Insightful)
Re:The only perfect CMS (Score:2, Insightful)
Re:Avoid PHP for Web-accessible CMS installations. (Score:5, Insightful)
So basically, you have some well-intentioned but not experienced person with a good idea, and they sit down and hack together an application while learning PHP at the same time. Do they even know the definition of "SQL Injection Vulnerability" - probably not.
And a lot of the issues that I see on places like bugtraq are application specific, and I usually haven't even heard of the app. "The PHP app, Lyrus Extreme version 3.2 has a remote exploit." In your head, you subconsciously tally that up as "one more PHP problem" and if someone is gathering statistics on PHP problems by searching bugtraq for the string PHP, this one will be counted. But really, it's not a PHP problem, it's just an amateur programmer.
Go Native among the Users (Score:5, Insightful)
This is so true. End user input is critical, they will make or break the project.
My dad (rest his soul) was lead programmer (maybe the only programmer, I dunno) for the Star Tribune newspaper, back in the seventies. I was a teenager at the time, he taught me about For-Next loops and so on. Along with the coding, he emphasized:
The smart programmer
(a) Listens and nods his head while Management says "We want this, We want that"
(b) Sits down with end users (secretaries, etc.) for a while, every day, staying out of their way but watching them work, and asking the occasional question;
(c) Figures out what the end users really want, need, will accept;
(d) Codes for the end user, then spins the thing so Management thinks they're getting what they (foolishly) asked for.
Dad called this "going native among the users" (he took his degree in anthropology).
-kgj
Re:Go Native among the Users (Score:3, Insightful)
Re:Avoid PHP programmers for CMS (Score:2, Insightful)
While PHP is a truly awful language that strives against every programming principle and the very act of writingin maintainable code, the problem is not the language.
The problem is the sort of people that PHP as a language was designed for. It was designed for non-programmers and kids to easily hack together vaguely working web applications for pocket money or sweets. It excels at this, cast your eye around the uncountable fray of PHP programming forums and the people using them. (Witness also that people outside this set avoid PHP with great vigour).
However, people who like PHP are most definitely not the people you want to have writing a CMS that holds actual data. MySource is a great example of this. Because the people who designed MySource are basically idiots, a site with 5000-odd pages comes up against issues where on each page render every child page (And its children) has to be individually checked for access rights so the side menu can be generated. As a result, for the above-mentioned 5000-page site, on a fast 2-processor server with gobs of memory, serving a single page takes about 3 seconds.
3 whole seconds.
PHP programmers are the sort of people who write these ridiculous piece of code, and leave the issue scattered through the whole source tree without any hint of abstraction so that fixing it becomes a major rewrite. PHP programmers are the sort of people who release a 'commercial grade' CMS without having ever tested it with 5000 pages.
PHP programmers are great for small websites paid in sweets, but don't use anything they've touched for a CMS.
Re:Avoid PHP programmers for CMS (Score:2, Insightful)
PHP is a fine language if you're a strict programmer. People, by and large, aren't strict programmers: And thus you get things like older versions of Mysource Classic. Even completing second year computer science should expose you to enough good practices to identify badly-written, poorly-scaling code with poor abstraction.
Unfortunately there's not a lot of good programmers out there and they're working on rather large PHP projects - which leaves us unfortunate sods having to maintain their stuff when it doesn't quite scale the way it was intended.