Did you find this page useful? If so, please consider linking to it
- or use the bookmark facility at bottom right. Thank you.

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

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 of those 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. MySQL, then, has a very strong foundation, with a mega commercial backer and open source status. 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.

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. Maybe in ten?

 

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. 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 can 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.

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.

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.



Q: 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:
1. An enterprise level CMS with full ACL.
2. Mainly LAN or intranet use, but possibly a Net-facing section or two.
3. A reasonable budget.

So, if all those things applied, we might be looking at the commercial CMS Vignette, for instance.

If the budget is much lower then Plone would most likely suit. Note that both Plone and Vignette 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 may be needed here.

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.






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.



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 3,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-siteing; 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 - 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 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 10K products; 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 (ie 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. No buyer in that sort of market is going to put up with the heavy-JS pages and non-validating code the rest of us 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 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.



Q : What are the issues if you build your own PHP CMS? 
A : Jeez, you must like pain.

[more tags: grow your own cms, roll your own cms]
This is a surprisingly popular question, so there must be a lot of fearless devs out there. But have you seriously thought about what this entails? Teams of people, the best and the brightest developers in the world, toil for years to get their projects to a sufficient stage of maturity that they deserve the title of A Real, Working, Good CMS. You should be able to figure that out by reading some of these reviews - many are critical, because there is so much work left to do before some apps can honestly qualify for that title.

In any case, why try to reinvent the wheel? What's wrong with the best of the free OSS apps out there? Either join an existing project and contribute; or if you just want something simple, maybe, then use a simple CMS - we've identified a couple for you. If you don't like them - fine, then fork off.

Er, sorry about that :) I mean, start with the existing CMS, and create a fork, going off the way you want. It's a popular strategy in OSS. At least that way, a lot of the groundwork will have been done; but we don't advise it because, surely, somewhere out there in the 2,000-plus CMS in existence, there must be something you can live with?

Anyway, first select your codebase. Then comes whether you work at a server farm or not, and therefore have access to the boxes - 99% of the time the answer is no, so you'll be looking for a remote-install CMS. You can do the dev work on your local LAN. Then - what sort of CMS do you want? Basic, with your own Dreamweaver page as a template; or maybe with complex ACL; or with an existing shopping cart backend? Choose one, then extend it yourself, if by some chance you don't like it as-is; but you'd probably be better off joining the project.

Alternatively, if you simply mean a couple of PHP pages to give some dynamic capability, then you are probably going in the wrong direction - semi-dynamic sites are a poor choice unless every single aspect needs to be custom code. That's OK for commercial sites with big funding, but doesn't suit many others.

We see a lot of 'custom-built' ASP attempts at a CMS as well. Normally they are about as good as a home-made nuclear reactor - it might sort of do the job, but you really don't want to be anywhere near it.

For a skeleton solution, what about webDAV or .NET (depending on whether you want to go LAMP or IIS)? Unless you need something really special, though, you might be better off with something like CMS-MS, maybe with a couple of new extensions to fit your intended profile. Dynamic site webapps are a much better proposition all round if they are a community effort, these days, so be sensible and join a project.



To follow on from the last question, here is another one on basically the same point:

Q : CMS 'XYZ' is no good - I'm going to build my own. What do you think?
A : Er - are you sure?
 
It is fairly common to see, on forums and so on, developers writing something like this or a variation: "I'm fed up with XXXX CMS, it just doesn't do what I want, it's no good at all, it's buggy, I'm going to build my own." Or a variation on this theme. This has two major errors that need pointing out:
 
1. You chose completely the wrong CMS in the first place. They are often targeted to a narrow functional area and you picked the wrong one. You tried to use a CMS with no ACL for multi-group working; or a provider-consumer CMS as a portal. Your fault, not the CMS.
2. There are 2,000 or more of them out there - find the right one for your purposes. Join the project if it's OSS. If you find that only a commercial CMS does something you wish an open-source app did - then help to make that happen.

All CMS are incomplete or buggy according to one viewpoint or another. So is every piece of software. It doesn't do what everyone wants, because it can't - find one more suited to your purposes. All are 'buggy' to a certain extent, especially if you are trying to make it do something it is not suited for.

Find a CMS - or especially an OSS CMS project - that suits your purposes better, then help to improve it in the direction you want. If you want ACL, use Drupal - don't try and make Joomla do that because the core is not suitable. If you want exceptionally capable ecommerce, then try and find a way to bridge a full ecommerce app to a CMS - no CMS right now has native ecommerce support on the scale of the full ecommerce packages. Don't try to make an application do things it is not capable of doing.
 
A lot of people have been down the road you are on. Don't try and do all that work again, there's no point.

And lastly: please, please, please validate your code. Research the requirements for search engine compliance, and accessibility issues - then incorporate that knowledge into your applications / extensions / sites / webpages. And validate the pages generated, before handing on to the client. Please.

Once again - for the Nth time - around seven or eight out of ten (that's up to 80%) of web pages we work with are code trash. Even clients coming to us with sparkling new websites that cost them a lot of $$ have sites where all the pages have 50 - 100 code errors. As far as we are concerned this is fraud.

If the vast majority of developers and website designers have never even heard of code validation, what point is there in talking about accessibility, usability or other SEO issues?



Q: How to install dreamweaver on xampp?
A: Umm, er, I'd have to think about this one. It is one of the hardest questions I've been asked, actually.

An excellent question to finish up with - and no, I didn't rig it. Truth is stranger than fiction and even my fevered imagination couldn't have produced this one...

OK, let's try and work it out by stages then. I think there are two approaches to this search query on Google that ended up on our site (the swine, why can't they send those tricky ones somewhere else?): the intricate technical possibilities of actually achieving the impossible here; or assuming it was a typo and that it should have read: "How to install Dreamweaver [websites] on XAMPP?"

First let's have a go at the improbable. Our task, should we choose to accept it, is to install a client-side visual / HTML editor onto a server. This tricky proposition might be just a little easier because it's going to be a local machine - with XAMPP it has to be a LAN PC - so at least we won't have to try it over the Net. On a Linux box.

We won't ask the obvious question (why would you want to do this anyway?!), we'll just wade in. Let's first install DW on the PC, that should give us a start. Next, how can we serve it? Interesting. Well - we can't really, as the visitor's browser will not be expecting a 100MB .exe file, they normally get web pages. On the other hand this could be a route to a new kind of webapp - you don't bother with a site, just serve them an HTML editor and they can build their own. It will probably need some AJAX. On second thoughts, Ruby on Rails would be the tool for this, you can do anything with it (apparently).

So, how about we serve a site we built in Dreamweaver instead; or would that be cheating? To be honest I can't see how we're going to serve an HTML editor anyway, so let's take this option - please.

1. Install Dreamweaver on PC.
2. Create website, using htdocs directory as local root folder. That means you can completely forget about the FTP procedure normally necessary - this should be an excellent timesaver!
3. Or, go completely the other way, and use a complex remote access procedure, to extend the job by around 5,000%. If the LAN server is in the next room and you can't be bothered to get up and go in there, and the government are paying - well, this is the standard procedure I believe.
4. Serve website as per normal.
5. Ignore the fact that the usual method is a whole lot easier, whereby the editor (Dreamweaver) resides on your PC back home and you FTP the finished site pages up to the server.

Or, assuming the question was just a typo anyway in the first place:
1. Build site on local PC as per usual; FTP up to site using built-in Dreamweaver FTP client; run site off server as per usual. Or just transfer the files by LAN or USB thumbdrive since the server is sitting right next to you.

Hope this helps.
They always say that, don't they, no matter how fatuous the answer.Though I think it originated with Auntie Jill (who is not the least bit fatuous).


Audience question, to panel: "How can I make sure Goggle indexes my pages correctly?"

Reply 1: Bruce, "You'll need a 5.75% k/w ratio plus a 3:1 PR sculpture on the critical pages along with a minimum CTR ratio for the landing page ROI profile of 3 ex 5."

(I was too far away but it sounded like that.)

Reply 2: Jill, "Oh, I shouldn't bother too much, just write it naturally. Don't worry, be happy."

Reply 3: Aaron, "Ignore them, they are parasites."

Or something.