[thelist] MySQL as CMS

[Martin Paul Burns]

Hey Michael

Essentially, you've got the base layer of starting to think about a CMS -
separating the content and the presentation. This is exactly the basis of
most CMSs, including the one which runs the evolt.org site.

Another nice benefit is that you can store a lot of meta-data as well as
the main page content. So you might want to store author info, expiry data,
last update info, workflow info (who signed off the content, and when?),
location in the site, whether a page/section appears in the navigation
hierarchy, keywords, description (etc - you get the idea).

You might make a particular type of record one which acts almost as a
folder, containing other assets. Example: An image might also contain
assets for thumbnails, alt-text, description, links... all of which may be
different in different contexts.

Also, you can split up your output template into components and maintain
them separately. Take a look at my site - http://www.easyweb.co.uk. Each
page is put together by one template from about 10 sub-components, some
generic, some pulling data from the data object for the page and some (like
the breadcrumb string) writing the content automatically.

You might find the following interesting:
http://evolt.org/article/thelist/20/5127/
http://evolt.org/article/thelist/20/1449/

I can understand that if you have skills in MySQL you might want to base
your CMS on it - it's a pretty good basis for the data layer. What *might*
give you performance problems is the logic layer - the application you
build to access the data and ship it out to a webserver. You might want to
think about some caching so you're not doing database hits and logic to
build the output every time you serve a page.

Unless you either want to prove what a coding stud you are, or think you
can sell your application in a fiercely competitive market, you really
don't want to be writing your own application from scratch. Ideally, look
for a CMS which either:
1) Does 80%+ of what you want out of the box and you can customise the rest
of the important stuff
2) Is a base platform which does the hard stuff (like base content types,
version control and security/authentication) and provides lots of
content-aware hooks to add your site-specific stuff on top.

An example of the first kind is http://geeklog.sourceforge.net/ (it's a
MySQL backend IIRC) while a pretty reasonable example of the second is
http://www.zope.org/ (which is what I use to run my site).

Cheers
Martin



I was thinking that Library articles and the product data should naturally
be stored in a database. Then I got to thinking...
"Hey. Why can't I just put all the content in the database?"

I began scheming how I might put all the sites content in the database,
then
access each section of the site with one template and a query string.

I imagine a simple administrative tool allowing the client, or myself to
update the content of the site without managing a bunch of scattered HTML
files.

Are there any faults in this approach that I am not seeing?

This will not be a particularly high traffic site, so I am not concerned
about taxing the data base.