Content Management System use DB or XML or ...?

We have a Content management system (cms) developed inhouse. Based on requests from our clients where moving to a new version.

All content is stored in one table. This table has pre defined collumns, 10 varchar, 5 text, 5 date fields and so on...

Based on custom insert/edit templates some collumns are filled and some are not. Each category of content has its own template in this system.

Example:
- category1 uses fields varchar1, varchar2 and text1 (title, author, content)
- category2 uses fields varchar1, text1 and date1 (event, description, date)
And so on...

The problem with this stucture is that the table layout has to be altered when for example more then the reserved 10 varchar collumns are needed in a template/category.

In the new version I want a solutions to this problem. I thought of the following scenario's:
1. - Build table altering functions in the cms to let contentmanagers adjust the general content table.
2. - Build a new table per template / category to fit needed collumncount.
3. - use xml to store all content data in one large blob field with corresponding collumns as xml tags.
4. - use the database just to save some administrative date about the content title, publishing date... Save the content data in xml files residing on the filesystem of the server.

I am a paranoia type so I am not so happy with the idea to give content managers rights to alter the database (scenario 1 and 2).
My personal favorite is scenario 3, store contentdata as xml in a large blob field. My only big concern is performance; searching trough the database, xml parsing in php and so on...

Can you give me some tips, pro and cons, ideas about of the different scenarios. Or maybe I am looking in the wrong direction and you folks have a completly different idea about this.

Thanks,

Your observations on XML are correct.
For example, if you want to find all content for a particular
author, it would be damn tough because there is no Author
column, everything is in XML.

Why not maintain the same design that you have currently
i.e one table with 10 varchar fields. And a secondary table
which will store additional columns in case a category
requires more than 10 variable columns.

You can keep a foreign key to the secondary table in
the primary table, which will be NULL whenever the
columns in a category are less than 10.

The above is just a suggestion, I dont know much about
how exactly you create a new category and the template
for that. But I have faced the same problem in designing
databases for other kinds of systems e.g equipments database,
experiment data management system, etc.

Maybe we can discuss further on this.

Ajay