Home arrow CMS FAQs 2
CMS Questions - 2

CMS FAQs - Part 2

CMS FAQs - Part 1
CMS FAQs - Part 2  [this page]
CMS FAQs - Part 3

Here we carry on with the CMS questions resulting from site searches that are too specific to feature on the main pages.

Q: Is PHP - MySQL still an up to date way of running a dynamic website ?
A: Oh yes.

Not only that, it still looks like the best bet both currently and for the foreseeable future. The only realistic challenger is Ruby on Rails (which also uses MySQL), but that is still in the very early stages of infancy as far as a full-on challenge is concerned.

Yes, it's surprising that this is still the case, since PHP has been around a long time and technology tends to move on fast. But let's look at the challengers - other competing codebases. Probably the biggest challenger is ASP (surprisingly, as it's a proprietary technology), but it can only run on an IIS server and that wouldn't be most people's first choice. But if budgets are extensive then the elevated costs are not an issue. ASP-based applications are proven heavy-duty, enterprise-level software so there's no argument about their capability. However, there are a lot more options in every possible area for LAMP-based applications, so ASP-.NET apps are inherently limited.

Other codebases are remarkable for their lack of heavyweight opposition numbers; maybe Java has the edge here on numbers, but we're talking about strictly corporate apps here because the development and support costs are so high. Perl, Python and TCL are represented by much smaller numbers. There are many minority choices such as C++.

PHP is still everyone's favourite for webapps, and instead of losing ground, more new PHP webapps are being developed every day. As far as capability, speed, robustness and usability are concerned, PHP stands up there with the best of them. It might be possible to find a codebase that scores higher in one or two areas, but PHP has the overall top score. Some of the best webapps of all are built in PHP, and since it is particularly suited to a distributed developer community, more power is added daily.

It's hard to see how things might be different in 5 years, as PHP is so strong. Remember that no matter how good a codebase or development framework might be, there have to be very strong practical-use examples in existence for 4 or 5 years before they can even be considered as good, working, practical, community-usable webapps. It takes that long to get over the teething troubles. So to build up another codebase to replace PHP as the world's favourite webapp code will take 5 years at an absolute minimum. Therefore it's difficult to see anything overturning PHP even in 10 years.

And then, looking at the MySQL question: the same thing goes but even stronger. There are only a handful of challengers to MySQL in any case, and none could get far in 5 years. PostgreSQL is a strong and capable contender, some say better, but it only has a fraction of the resources at present. Microsoft's MS SQL Server will never compete in numbers, whatever the other issues might be.

The only way MySQL could crash is if the owners (Sun Computer) suddenly decided to make it a proprietary technology instead of open source. The quickest way to slow anything down to a crawl is to restrict it 100% to one or the other: OSS or commercial. The best way to make it take off like a rocket is to combine the two. Projects that combine the two modes are among the most successful of all: MySQL database, Joomla CMS, and Ubuntu Linux for example.

MySQL, then, has a very strong foundation, with a mega commercial backer, open source status, and a multitude of commercial resources. It's probably one of the 10 best-supported apps on the planet and at present it can't go wrong. Look at the Ubuntu Linux situation for a comparison; this is a rocket-powered business model that benefits the entire community to a tremendous extent. Web applications that feature an unrestricted mix of commercial and open-source resources are very successful. And PHP fits hand in glove with MySQL.

So you could say that PHP-MySQL is the Dream Team; and that doesn't look like changing at all in the next 5 years, and most likely in 10 years either (this is stated in early 2008). It's fun to make definite statements on future technology that will be proved utterly wrong! Here, though, something new would have to come in and sweep the field at an astounding rate, as there's nothing much on the horizon that looks a threat right now. Java can't do it as it is far too complex and restrictive; Ruby would have to accelerate to warp speed and beyond in order to move PHP over within five years. RoR (Ruby on Rails) is often proposed as the 'next best thing' but what CMS or ecommerce applications use it? Well, Radiant CMS of course - but this has a tiny user base and is simply for developers, running on a dedibox, at present. It can't be installed remotely so at the moment cannot be considered as a normal user CMS. If it stays in this mode it will never have any size of user base. PHP / MySQL is the king.

As regards compiled code for webapps, that seems to be a dead end - very few projects use it. Of course it is faster, and probably more secure, but those advantages don't seem to translate into real-world benefits as far as web software is concerned. Text-based codes rule for server software.

Q: Best cms for designers ?
A: OK, that's a fair question. Let's maybe look at what might be meant by that question in the first place.

There could be two interpretations: (1) a CMS for use by web designers, which often means website builders; and (2) one for use by graphic designers, art-skilled people who wish to present a website's visual aspects optimally.

As far as (1) is concerned CMS-MadeSimple would be a good place to start. It won't suit all projects - you would need to know a wide range of applications in order to do so - but it is a good starting point for the journey into CMS. When you can handle that, other apps become a feasible proposition; you'll understand the way CMS works by that stage. CMS-MS also suits both types of designers.

And for (2), we can also start with the same application as it is one that uses a grow-your-own template. So you can come up with any design you like, convert it to an HTML page, and that's your template. Another CMS that uses this approach is Radiant, but that won't suit a designer working alone; you'd need experienced help here.

Alternatively, you could try the Joomla route, using an extensive template mod approach. This CMS has a combination of the most templates available plus one of the best systems for customisation. For this, a graphic designer would again need some assistance, from an expert Joomla user this time.

And don't forget, whenever you build your own template, validate the basic page first, before you go any further. It's a waste of time building a site on a template that's code trash to start with. Build it using divs (layers) and CSS, then validate it - you'll have the best possible foundation.

Q: Best cms with acl ?
A: A CMS with full ACL is more easily found in the commercial market, since this is often a prerequisite - and a core function of an enterprise-level CMS, since without it the application does not qualify. As a rule, CMS with good ACL are complex applications, since ACL affects the core functionality more than any other feature.

Of course, you may have budget limitations, in which case semi-commercial software might suit; eZpublish is the obvious candidate here as it has strong ACL. You could also try Plone, which although being full-OSS, is very hard for anyone unfamiliar with it to set up for complex functions, and may therefore need commercial support. Both of these require specialist hosting - even though eZpublish is a PHP app, it uses a different form of PHP accelerator and does not sit easily with other standard webapps on shared hosting. Plone is a Python-based CMS that uses another app, Zope, as middleware, so it needs a dedibox or perhaps a server where all other apps are Plone.

Moving along to open-source PHP apps that have a wider community base, then Drupal and PostNuke have good ACL, but not at the level of the previous applications. These are suitable for shared hosting. Drupal is a good bet because it has excellent support and is going to be one of the most important CMS available (if it isn't already). However, it's not an easy task for a webmaster to learn it, due to the core ACL, which always makes a webapp far more complex than one built for a single team to run.

Joomla has a very basic implementation that may suit the simplest of user roles. As usual there are plugins to expand its capability, but ACL support is really something that needs to be in the core application. If the ACL implementation you need is restricted to having a few groups with access to their own pages, then this will suit.

Flat file cms drawbacks ?
A: Well, there are several, as might be expected. These resolve to:

1. Slower speed than an SQL database-run CMS.
2. A maximum page number limitation.
3. Reduced robustness.
4. Less plugins.

Taking these in turn: as page numbers rise, speed reduces. This is because a flat-file app stores the data in a plain text file, and as the filesize increases, it takes longer to extract the data.

The maximum page number is around 20,000 as by this time speed is reduced to a crawl, and stability is affected. Of course, this is much larger than the vast majority of sites. However, a page limit of 1,000 would be more sensible, as larger sites than this will probably need a lot more capability than a flat-file application can offer. The exception is where the pages mostly comprise simple plain text, with one person editing, and no fancy features. If this is the case a flat-file WCMS is a practical proposition and page numbers can be extended.

A flat-file CMS is far more vulnerable than a database-run app, as it's easier to corrupt the files or even delete them - the data is in files in the webroot, so they are more vulnerable than if in an SQL database. Backup schedules need to be religiously observed in case it all goes down the pan. A flat-file app is not the way to run a mission-critical website.

Because these applications are simpler and have less reason to seek extensive functionality, there are many fewer plugins. You cannot do an all-singing all-dancing job with one of these tools, they are well-suited to smaller, text-based sites. Anything more adventurous needs an SQL database.

There is a demand for these flat-file CMS apps because some webmasters are limited to an IIS server, with either no MySQL or no access to the management apparatus; or because they have management restrictions on their LAMP server, such as no database access. This implies that the cost of a new, normal LAMP shared server account cannot be afforded; and since this comes in at $10 a year for a basic provision then we must be looking at users who cannot afford or arrange this. Essentially, that means applications in this area cannot be expected to have full functionality. Of course, there are other reasons for needing a flat-file CMS; but since any server can have PHP and MySQL installed, or an additional database supplied, the market is limited to those who are under the most extreme restrictions.

Q: Best teamwork cms ?
A: OK, let's try and rationalise this.

A CMS for teamwork implies several things that may or may not be true in your case:
  • An enterprise level CMS with full ACL
  • Mainly LAN or intranet use, but possibly a Net-facing section or two
So, if those things applied, we might be looking at a basic commercial CMS.

If the budget is much lower then Plone would most likely suit. CM systems of this type tend to need skilled administrators, if advantage is to be taken of their capabilities.

eZpublish has good ACL, plus some strong additional features that suit here, so it would do the job if a PHP CMS is preferred; but keep in mind that it doesn't live happily with other PHP apps since it uses a different PHP optimiser system. Extensions are often commercial.

If a full-on enterprise-level CMS is not really required, and the teams involved do not require extensive workflows and audit trails for their work, then Drupal is a straightforward PHP CMS that will install and run anywhere. It has the ACL that is necessary for multiple group access rights, together with good versioning. Alternatively, Radiant is suitable for this role if there is access to the server, as it cannot be installed remotely. Some custom work will be needed here. Umbraco is an equivalent in ASP (Windows-based) CMS.

If by 'teamwork' you just mean one group of people, who need to work informally on a project without extensive adminstrative guidance and controls, then Joomla will suit. It installs anywhere easily and will be up and running in basic mode very quickly. It is especially suitable as an office single-team / community tool, for building a resource for use by a single team, and also growing the team's usefulness and team value. This form of use is undervalued at present and many enterprises would find it a valuable tool. However this particular content management system has little in the way of ACL, versioning, audit trails etc.

Q: Can cms limit future development ?
A: Nice question. Let's think about this.

OK - there are a great many CM systems so what applies to one, often doesn't apply to another. However, what most have in common is that they can handle many more tasks than a standard website. And, it's a thousand percent easier to implement those functions as you can simply add a plugin. The functions are normally more extensive and more easily added than any kind of semi-dynamic site (like ASP).

One or two CMS have such a vast number of plugins that functions and features are available that would never even occur to most site owners; and most such functions can be added with a few clicks. This is part of the attraction of a WCMS - it does so much more, so much more easily.

However, it is a perfectly valid point that none of these systems will handle specific custom tasks, either out of the box or via plugins, because that would be impossible. In such a case, with a normal hard-coded site, you would normally hire a developer to work up the
new functionality you need.

With a CMS the situation is exactly the same: you hire a dev to implement those new features. In fact it is often easier, for several reasons: the system is built to be extended, and there are APIs to hang such custom functions on. They don't have to be part of the core apparatus (and in fact are best not added like this), but can be high-level or low-level plugins - normally referred to as components or modules. There are a bunch of advantages to this, not the least of which, for the developer, is that he can then maybe repackage the component and sell it again. This is a main improvement path for many of the big CMS projects, and one of the reasons why they have such a very large number of extensions available - over 4,000 in some cases.

And in the case of a function that cannot be contained within a CMS in any way, then you would develop that new functionality as a discrete
website section and just link it in (or bridge it) to the CMS. No problem.

So it's probably fair to say that in most cases there would be no disadvantage to running on a CMS; and advantages even where future custom work is envisaged. The trick is to choose the right one in the first place, since your future direction is determined by this as much as anything else.

Q: A comparison of CMS and Flash websites ?
A: OK. These are two completely different entities but let's explain why.

A Flash site is essentially a cut-down movie. It's a short video that tells a story; or a collection of Flash movies that each show an aspect of the site's business. These sites look great when done well - no question. They are especially popular in the media world, and where the subject matter is very visual.

Unfortunately, the search engines largely ignore them because search is based on text, and the type of code that a Flash-based website is based on has been virtually indecipherable by search engines up until recently. It's true that the most sophisticated search engines can now interpret some of the content of many Flash sites; but they are still heavily handicapped. There are workarounds but they are only token attempts in damage limitation. Since there will not be great natural search traffic (unless the site is a monster and cannot be ignored by the search engines), most traffic has to be generated by advertising. That's like running your truck on Glenmorangie whisky - it may work but it won't pay as well as 'free' traffic.

Also, of course, a Flash site is about the most difficult there is to edit or update. If you build the site in Flash, it's basically going to stay as it is. In contrast, websites today need to be easily updated, which is why CMS will gradually take over.

Flash sites are severely handicapped in a commercial environment and that's all there is to it.

A CMS is a way to publish large amounts of pages and other content; and/or to manage it in a super-efficient way that was not possible with hand-coded web pages. For example you edit your own pages, you don't have web publishers or webmasters do it; it takes a couple of minutes to do a quick text edit, and it goes live on the site immediately. A CMS runs off a database and there are no pages in existence on the server (apart from error pages etc). Because content is separate from presentation, which is due to the way the applications work, you can make radical changes to either without affecting the other. It's hard to appreciate the benefits of this without experiencing it, but in practice it means you can get a big site live in a fraction of the usual time; pages can be added or deleted without worrying about links; a whole new look to the site is accomplished by a ten-minute template changeover.

CMS is the way all large or complex sites will be run soon, and all sites that aren't owned by a webmaster who likes doing text edits. And that adds up to a very large percentage of websites.

So as far as a comparison of Flash vs CMS goes, they don't do anything similar so there is no comparison. One is the ultimate new media site: all tinsel and no content, almost ignored by search engines. The other is the modern way to publish to the web. On the other hand, a well set up CMS in a visual market area can look pretty flash...

Q : How to set up two separate websites on a local server ?
A : Go to our XAMPP install guide for this.

You can set up multiple sites on a local network with this full server package. All you do is place each site in its own folder, in the web documents directory of the server. You can have a hundred sites on your LAN if you want.

This is ideal for development work. XAMPP installs Apache server and all the other apps needed for dynamic site working. Of course, XAMPP installs MySQL database functionality so that your multiple sites can be database-driven CMS or ecommerce; or just flat HTML, it doesn't matter.

Q : Comparison drupal vignette ?
A : Vignette is a LOT more expensive.

All right, all right, let's get back to sensible mode. Vignette Storyserver, and its variations, is a major commercial CMS, and possibly the third most expensive there is (behind Broadvision and Interwoven Teamsite). Drupal is freeware. Vignette will cost you thousands of $$ for a license, plus support. So one would have to assume that budgetary requirements will be the key factor here - if you're BigName Corp, go with Vignette, otherwise it's Drupal.

We should also mention, however, that there are many people who would still choose Drupal in this situation, even with a substantial budget available. There are several examples of this. Given a budget of $100k we'd still pick Drupal, as PHP developers can work up whatever you need, on-budget.

Q : CMS comparison plone drupal joomla multiple domains ?
A : Do you mean a license for several different domains to be hosted on separate sites, on the same server - or at different locations? Cost-wise, these are all free CMS, so no difference there. Main costs are likely to be for implementing features. These are done with plugins, and if they don't exist, a developer has to create one. Joomla has the most, at around 4,000, so logically it should be cheaper, by this measurement. Drupal has around 1,000 and Plone has about 700. As regards high traffic or huge page numbers, Plone is the strongest, but needs a dedicated server - the others don't.

As regards running several sites on one CMS, there are pros and cons to this - mainly cons. Unless they are mostly very small and simple (and of course with different content since you can't run duplicate domains), then we wouldn't advise this anyway. And if they are all small and simple sites, then use a small and simple CMS to run each - then you are more independent and have better redundancy. Drupal is reported to have multi-site capabilities. The RadiantCMS project, though, gives some advice on multi-siting; and it would also be a good choice, perhaps, because anything like this would probably be a dedicated server job, with physical access to the server, and require plenty of dev work - so RoR / Radiant is a good candidate. Joomla has some multi-site enabling plugins, that assist with multiple sites on one server or with sites on different servers.

The SEO factor: Plone and Radiant have a very high SEO rating so search optimising here is a pleasant task. As ever, templates and plugins cause the problems. Drupal and Joomla are in the same boat here: the base applications are fine but plugins can wreck the code. It's just an unfortunate fact that many developers (and website builders in general) have never even heard of code validation. Ignorance is bliss.

To give a definite answer we would need to know a lot more: what is the budget, what sort of websites, what codebase if anything pre-exists, do you have a dedibox - etc.

Q : Multi-site shopping cart cms ?
A : Firstly, CMS with a shopping cart (ecommerce plugin) are rare. To clarify that, many if not most CMS claim to have one, but on closer inspection you'll find it very limited. Crippled, in fact, compared to any proper ecommerce app. As regards multi-site, you mean for the license? If you go with OSS, it's free. For commercial CMS, multi-site is serious money - depends what class of funding you're in. For an open-source ecommerce CMS, try Plone if you have a high-traffic site with only a few products; VirtueMart-Joomla if you need the full works, but not with more than  about 1,000 products or so; eZpublish for a strong semi-commercial set-up that starts around $5,000 or so for a fully-supported install, maybe half that for DIY. If you had $50k to play with it's a different story. To answer any question properly on multi-site, a lot more background needs filling in.

Q : Any good java-based cms out there ?
A : No.
OK, OK. If they output flat HTML pages, with a teensy bit of JS, we'd consider them. If it's a .jsp page (with too much JS on it) - there are better alternatives. The big joke is that many developers can't figure this out, and have never heard of search engine compliance or accessibility; even now there are coders working on yet more Java / JavaScript CMS, when a capable one like OpenCMS has already shown that this not commercially acceptable on a wide scale in the value commercial CMS or open-source CMS areas.

This is due to (a) the unusual server requirements; (b) the cost of development and especially extension; and (c) questions about the page code / fileformat acceptability now. Java CMS only works on a wide scale in the corporate CMS market area, because of the very high development, extension and support costs.

As far as OpenCMS is concerned, their sites' pages are looking a lot cleaner now, with less obvious JS weight on them. This had to be done as the modern climate rejects the old heavyweight JS attitudes.

In any case, how do developers think they can come out with something better than OpenCMS, which is a fine CMS? To do this, a Java CMS would have to comply with these points:

1. Able to be remotely installed.
2. Will run without a monster Java install on the server (ie can use a standard LAMP server).
3. Has an HTML file extension or similar, preferably not .jsp (only because that tempts devs to add more JS as if it didn't matter). Of course, a .jsp page with no JS on it is the same as any other page and perfectly acceptable.
4. Has little or no JS on-page (needs to be minimised, and in any case in server scripts, not on the page).
5. Has frontend multi-user editing.
6. Has granular ACL.

If you can handle that, then by all means go with Java.

The first and major problem is that few Java coders have even the remotest idea these points exist; and if you try to tell a JavaScript coder this kind of thing, they explode...

There are some successful big commercial Java CMS out there - but they are in the big-buck market where developers can spend time on getting it right. A buyer in that sort of market would be able to sort out the heavy-JS pages and non-validating code that less well-resourced buyers may have to make do with.

Ultimate coding skill now is to accomplish what needs to be done with CSS, plus transparent script like PHP that search engines don't choke on, with redundant JS (browser-optional JS) where unavoidable. Search optimising for heavy-JS sites is a nightmare and there's really no other way to describe it. We strip it all out as the first job, whenever possible - then watch the search positions rise.

Can't really put it any simpler than that.

If a Java-based CMS didn't use excessive on-page JS, and didn't need a servlet container, and didn't need an extensive Java SDK install on the server - then it would be a contender for wider use. But we don't know any like that, they all need a dedibox and a big budget. And it would be nice if this always resulted in a high-quality application, of course. Unfortunately, this is not the case.

The low-quality Java CMS problem
If you perform the simplest and most basic quality checks on some of these Java commercial or semi-commercial CMS, you'll find that the observed quality of the installed result is often poor. The application developers and/or the implementers seem unaware of the meaning of the word quality, and the results are not good. For some reason many of these projects do not appear to have had anyone in charge of quality control, with the result that the developers were in charge of quality. A bit like putting Dracula in charge of a blood bank.

The end result has often been very poor quality, with a total disregard of web standards, accessibility, and therefore legal compliance. Hard to believe, at the cost levels that must be involved - but easily checked. Try it.

Did you find this page useful?
If so, please consider linking to it. Thank you.


Web Business Managers