in reply to A CMS That Doesn't Suck

Is it just me or is keeping your content in a database and having the CMS generate static pages containing the same content redundant?
Yes it is redundant, but it's a useful option to have on high traffic sites.

CMS is a very large field, even just for websites. I think what you're after is a CMS that doesn't suck for *your* needs. You haven't really defined your needs though, so it's hard to tell if you're on the right track.

Replies are listed 'Best First'.
Re^2: A CMS That Doesn't Suck
by goober99 (Scribe) on Jun 20, 2005 at 17:04 UTC
    Mutant, in my attempt to be witty, I did neglect to clarify I'm writing a CMS that doesn't suck for my needs. Thanks for pointing that out. I hope that when I'm finished it will meet the needs of others also.

    I agree that databases are useful if not a necessity for extremely large sites or high traffic sites. My CMS will be targeted more at small sites like personal sites and church sites. It will be designed to be extremely easy to install and use. I want it to be easily intallable on an existing site without having to rework the entire site to fit into some database.

    I would like the entire CMS to exist of a single Perl script and installation would only consist of uploading and chmodding the file.

    jZed, my first planning stage is just to write and collect as many frustrations about CMS that I can. Then I will boil them down to a few I really want to address. At that point, I will decide how to better implement a CMS without that.

    As for a replacement for meta-data and storing content in a database, the system should be able to glean that information from the HTML files themself. I understand this would probably not work efficiently for an extremely large site, but it would be great for smaller sites and save on storage space. I don't want to use templates because that would make it difficult to use the system with an existing site. I still need to think of a better way to implement a consistent look with little effort.
      One thing that would be helpful for you as you work through design issues, for users of your software trying to decide if it supports their needs, and for others wishing to help is a definition of what constitutes "content" within your CMS. Is content only HTML files or can it include other text files? What about binary files, like pictures that may be attached to articles? Knowing what content needs to be supported will help to define requirements.

      I am not sure what the "website as-is" in the requirements means. Is the intent to manage all files related to the website, scripts and all, or just the data that is displayed?