Ohhh, me head hurts...

http://www.gossamer-threads.com/scripts/dbman-sql/

As the backend management system. The front end, is up to you I'm afraid! Nothing will ever be as customized or suited as you want it to be unless you start from scratch~ish.

Now Wil, that wasn't very nice of you to go and pop my bubble. I've had this pleasant little fantasy that there is a program out there -- for free of course -- that will do everything I need to do and will only require me to slap on a template or two.

Well, I've been getting the sinking feeling that I will need to do more work on the front end. I'll check out the script you've recommended (and i've seen you recommend it before), and i suppose I'll take a closer look at the cofax program also.

Anybody else? Got a miracle cure for me headache perchance?

Anybody else? Got a miracle cure for me headache perchance?

you could look around for someone trying to break into the programming field that will code this for you in exchange for something, people do weird things when trying to build up their portfolios

good luck

Are you running ColdFusion?

If so I might just be able to lend you some aspirin!

The only other thing I would say is go for .JHTML. It's the buzz these days in term of templates and content management across a large site. You'll probably need to 'upgrade' your web server, though.

http://hotwired.lycos.com/webmonkey/01/27/index4a.html

flipper,

No, I'm not running cold fusion, but thanks for the offer.

I'm a perl programmer myself, and php looks simple enough that I could write it in that also (although i would worry that some of the security nuances of php would sneak by me). I'll probably use mySQL as the database (cheapskate factor again).

However, depending on the backend I can be pretty flexible in what I use to code the frontend. Heck, I could even dust off my meager and rusy Java skills if needed.

Wil,

Hmmm... the jhtml looks interesting, I'll have to read more about it. And I think I'll delve into your dbman-sql suggestion.

I'm being pretty tongue in cheek in this thread -- I did have a notion there mgiht be something out there to handle what I want, but that notion died a slow and agonizing death over the last couple of weeks of looking for a miracle cure. I've pretty much come around to the notion I'll need to construct more of frontend and logic myself (well, I do have one other relatively novice programmer who may or may not stick through the project).

The only other content management system I know of is slashcode that powers http://www.slashdot.org/ - I believe there are some PHP versions too, something like PHP Nuke <?>?

Wil,

Thanks, yea I had looked at slashdot. I dunno, maybe the gruesome design of their site put me off. One canned program that I liked the best was one called mambo, but it seemed like it was popping all its links up in poups (which is pretty tacky) and they didn't have any sort of a demo package.

I spent some time looking at your dbman recommendation last night, and that is a slick looking little package. I'm slowly coming around to the notion of writing much of it myself to get it to behave the way I want it to. Still waffling though...

Let me know if you need a hand!

Wil,

Well, since ya offered...

I've given up on the CMS systems I've seen out there and have decided to write the front end myself. The more I thought about, the more I started to think what I wanted to do wasn't all that complex. At the moment I am working on the workflow.

There are some database questions rattling around in my head. I'm familiar with connecting with dbs, writing SQL queries, etc., however by no stretch of the imagination am I a DBA type. As I begin to design my tables I sure would appreciate a little insight in pitfalls to avoid and what-not.

At present my site has about 60 meg of content. This was generated over a year and a half and I anticipate a growth rate at least the same. The majority of the space is taken up by picture files which I intend, and perhaps I'm mistaken in this plan, to store as files in a directory structure outside of a database.

What's bothering me is each article generally has 6-12 pictures and a like number of thumbnails. This means my picture directories quickly become unwieldly (in my main article photo's folder I must have near 800 files, that has got to be impacting the site's performance). The solution thus far has to keep dividing the areas into sub-areas as the archive grows. This means my pathing keeps changing as files migrate to subdirectories. I need to automate the repathing.

The article files would be stored in a database and have the following fields: headline, body, author, date, category, sub-category1, sub-category2, status (publish live or not).

Would be wise to index that from the get go (bear in mind I have only a foggy notion what indexing a database table means)?

Would it be easier to store the picture in the db along with the article, rather than pathing information to the picture?

I wouldn't store your pictures in the database. You could either store the link to the pictures in a database. Each author could have his own picture directory.

Getting back to database design, two major things to consider.
One is to try to avoid duplication of data. In other words, instead of having the author listed every time in one table, have an author's table with author data. The other major thing to consider is to only get the data that you need. Many people use Select * from table1, table2, table3, etc. Instead use Select table1.fieldname1, table2.fieldname3, etc. This cuts down on the amount of data output so it makes your queries faster.