I can not recommend anything. I think there are three major problems of the existing ones (that imply other issues as well):

1. Insufficient separation of concerns: The model should be separated into "business layer" and "data access layer". But this is not the case, even with Doctrine. For example in a symfony project I see thumbnail generation in Doctrine classes. Sub optimal.. No chance to easily switch the underlying data access layer, say.. to CouchDB..

2. The CMS stands in the way of the developer instead of helping to get things done. Too much complicated configuration. Too much premade things that nobody wants the way it was made.

3. CMSs are created from the view of developers instead of users (both developers and web admins).

Naturally I recommend TYPO3 if you need a CMS. If you need it to be flexible and a joy to develop for - and with - then tackle the learning curve of TYPO3.

But: If you plan to build a social networking site, look elsewhere. If you need to build a website for a sports club with two editors that just know enough of the internet to understand it's not inside that fancy program called browser - look elsewhere.

It's not ideal, of course not. But it's not a monster either, the documentation is good and you should never confuse the quality of some available extensions with the what the core offers.

You should look at it again, three years are a lot of time. If you have more time, wait for TYPO3 v5 - that is, until late next year at least. If you want to know more about v5, get in touch with us, we are easy to find on the net. :)

@all: I just want to clarify once again, if the CMS does not provide an efficient solution for syncing development machines, staging and production in all directions, then I am not interested. With this I mean I want to be able to add some new module, content or whatever and easily be able to move that across the development team onto staging to production and back. From what I have seen no PHP CMS is able to do that and still enable content administrators to add new modules and content types via an admin tool.

Lukas, are you basically complaining about CMS's storing content (i.e. contact page content) and configuration (i.e. structure of that contact page) in the database, thus making synching between servers a pain?

I can see why it's nicer to have the config out of the DB but it's likely all CMSs will need some reference to the page types in the CMS in order to operate (even if its just page type name, ID and a reference to a content model class).

Obviously if the config was file-based it would make synching content types easier, but it wouldn't solve synching content itself. To some degree, the CMS itself should take on the job of versioning content (i.e. have dev and live copies). Still doesn't help if you want to try content out on a local dev version of the site first though.

Perhaps some form of XML export/import is the way forward for circumstances like this, which can depend on natural keys like URL paths?

My main gripe is that the two are mixed together and that the use of sequential auto generated ID's makes syncing a pain. Sure some export/import tools would go a long way indeed. There are many ways to solve the problem no doubt. What I am complaining about is that the issue seems totally ignored by CMS developers, which I find quite confusing because its the single biggest problem I see our development teams facing when they use such applications (again the same issues exist in web shop solutions as well .. really anything with a powerful admin tool).

I think any data that both the end-client and dev teams wants to update is going to be difficult to keep in sync between dev and production servers.

In our agency we tend to export and import SQL which works fine since the end-client isn't changing the content types of the site.

But for more complex CMS scenarios the only obvious way is to re-input the data by hand which is a real pain. So I can see why CMS providers should be looking to improve this.

Maybe the problem is not only the developers but also our "old school" SQL databases with their auto increment ids which makes synchronization impossible at all. Using another database system like CouchDB is really a big problem solver (even though they introduce some new, but these can be handled by some additional application logic) and we are currently planning to migrate a large project to this database to finally get rid of all our synchronization problems. And start to relax. ;-)

Btw. I just had a look at the diem-project's code which runs on symfony 1.4, but IMHO this is again way too much. After installing it you must learn a new symfony variant, I'm not sure if I want to.. I don't understand it. I only need some additional convenience tools to get my things done - not a ton of strange stuff where I suddently need to enter the pound sign in templates for template helpers.. really strange thing.. where is the pound sign on my keyboard?

Actually I don't want it.. but it seems I still need to write my own CMS. And you will probably also need to do so.