I have had the opportunity to work on numerous content management systems throughout the years. I even developed my own CMS back in 2002 using ASP.NET that I recently retired in favor of the others that are readily available and free. Every content management system has its pros and cons and you need to be aware of these before you start your project.
Many times IT people are so set in their ways in regards to the technology being implemented that they do not look at other viable solutions on the market. I have always tried my best to be technology neutral and look at the requirements of the client and the architecture the current systems are using. By showing favoritism towards one product over the other, can often lead you down a path that can be difficult to get the solution implemented. Being an IT person, we are always bound and determined to make it work or put the square peg in the round circle, even it requires us to sand the edges of the peg to make it fit.
A couple of years ago I found myself in this situation. The client wanted the ability to have a public Internet site and private intranet site locked down by roles and permissions. I created a quick solution using a DotNetNuke Portal. I met all the requirements, but the designers were only familiar with WordPress and stated WordPress was the best solution. I stated to them that if you have styled one site, you should be able to use their framework and style others. However, it fell on deaf ears. Not knowing WordPress well enough, I had no leg to stand on and went with their decision. Later, I found out that they were inexperienced themselves and made a technology decision based on what they were familiar with.
After the site was styled, they turned it over to me because they could not make the intranet portion work correctly. That’s when I had a chance to learn WordPress and determine the true capability of it. It’s a good product and I would use it in numerous situations, but probably not where stringent security is required. The client wanted to use only one instance of WordPress for their Intranet and Internet. I was able to find some plugins that offered the site to become an Intranet, but the documents folder was not protected even though I could set role permissions on the files, I was able to browse to the document directly without being prompted for security and could download it. I later decided to use the .htaccess file to protect the site, but didn’t have the permission needed to do it right because of where the site was being hosted. In the end, I was able to shave the square peg into a circle, but if we had stayed with a product designed to do just that, it would have saved me hours of work and the client money.
Since then, I’ve built several sites using WordPress, MojoPortal, and Concrete5. All these CMS solutions have their strengths and weaknesses. I would use WordPress for any business that might want to support PHP programming and have their content exposed publicly, but does not contain confidential information where an Internet/Intranet scenario exists. I would use WordPress if it was just an Internet site or just wanted an intranet site, but not both within the same installation.
I have enjoyed working with MojoPortal and found it to be very easy to customize. If you’re business supports .Net and prefers to work with a solid architecture that is very flexible, I would choose this product. It’s easy for users and it’s easy to add custom functionality by adding your own user control as a module.
Concrete5 has a very simple interface and it is built on a solid foundation. I would probably still choose WordPress for a public facing Internet site over Concrete5. WordPress is more mature and more plugins exist to extend the functionality. An annoyance about Concrete5 is how the main menu is created. After you build a page, it automatically shows up in the main menu as a link. You can change the role or permissions of that page so it doesn’t show up on the main menu, but there is no intuitive way to separate the menu system from the pages being created. However, at first glance it appears it might be a better option to create a Internet/Intranet scenario.
In conclusion, don’t lock yourself into one CMS solution when you are meeting with a potential client. Get their requirements first and then select the CMS system that best matches the requirements and their existing architecture. If you don’t know the capabilities of the CMS, take the time to spend an hour or two to investigate. Trust me, it will save you hours in the long run.
Please comment so I can hear your experiences!