Here is what I use:
The "articles" (non-technical user supplied content is stored in a database
e.g. mySQL with a table named something like article_content). The table
has columns such as
CREATE TABLE article_content (
id int(11) NOT NULL auto_increment,
page_name varchar(35) NOT NULL default '',
side char(1) NOT NULL default '',
position int(2) NOT NULL default '0',
title varchar(35) NOT NULL default '',
leader_length int(11) NOT NULL default '0',
creation_time datetime NOT NULL default '0000-00-00 00:00:00',
last_edit datetime NOT NULL default '0000-00-00 00:00:00',
editor int(11) NOT NULL default '0',
content longtext NOT NULL,
PRIMARY KEY (id)
) TYPE=MyISAM;
Each user is assigned a security level in a user database that grants them
access (table name something like 'editors')
Each article has an "hidden" (no decoration) editor's link at the end of the
article. It could be the last word, the final punctuation, or a graphic.
When you click the editor's link the user is challenged against the user
name and password in the database and appropriate data stuffed into
sessions.
Once authentication is complete the article content is delivered for editing
via a JavaScript CMS such as xinha or tinymce.
Upon completion of editing, the content is stuffed back into the database.
The "template" for all the website is as follows:
require('/home/pathtofile/phplib/class.articles.php');
require('/home/pathtofile/pieces/header.txt');
require('/home/pathtofile/pieces/column1.txt');
require('/home/pathtofile/pieces/column2.txt');
get_article("L");
require('/home/pathtofile/pieces/column3.txt');
get_article("R");
require('/home/pathtofile/pieces/footer.txt');
The function get_article() pulls the content from the database for the
referring page (e.g index.html) where the page_name matches the referrer and
the side matches L or R. I use position to rank the articles on the page.
A page with lower position (e.g. 1) gets displayed first and then any "2"
articles, then "3", etc. I use the "0" as a 'non published' indicator which
allows an editor to work on an article and then hide it until the right time
or to repost a recurring article at certain times..
Works wonderfully well and elevates my perceived status to that of near
genius!
Here is a link to see it in action or at least to see the finished content.
The entire web site is maintained by non-technical volunteers and they have
populated hundreds of articles on dozen of pages.
:
http://www.southshorechurch.com/index.htl?php_gen
If you need more info or functions to make this work, let me know.
Hope this helps,
Mark Cain
.
----- Original Message -----
From: "asinning" <[EMAIL PROTECTED]>
To: <php-general@lists.php.net>
Sent: Thursday, June 02, 2005 9:56 PM
Subject: [PHP] Site Design Strategy
> This is my first post to this group. I've been trying to figure this
> out on my own, but I keep running into complications, so I've decided
> to get some help. Much thanks for any help!
>
> I've been writing php server application for a couple of years, but now
> I'm turning my attention to re-building our company's aging website.
> This is a big project and is going to require a solid foundation.
>
> At the crux of this post is the following question: How do you develop
> a very robust, dynamic web-site, but also allow non-technical people to
> contribute? There must be an easier way.
>
> Here are my working assumptions and my strategy. Please help me if I'm
> thinking down the wrong path.
>
> Assumptions:
>
> 1) Non-technical people in the company need to be able to build pages,
> and they should be able to post their pages without bothering me. We
> have a tech-support person who will be able to help them, but she has
> zero programming knowledge and only a superficial understanding of
> HTML.
>
> 2) Every page needs to reside within he "shell" of the web site. This
> includes
>
> header(the top-level menu)
> left-side menu (a dynamic, context-specific menu)
> content (this is what the non-technical people will produce)
> footer (your standard fare text-based links)
>
> 3) I don't want to use frames, and I don't want to use Dreamweaver
> templates.
>
> Strategy: Currently, I am working on the following model:
>
> There is a top-level index.php page. This is the target of EVERY
> page on the site.
>
> The page that gets loaded in depends on the parameters of
> query-string. It's very simple, if the query string reads
> "?target=products/gsp", then my php will look for a site-relative
> document such as "products/gsp.htm" OR "products/gsp/index.hml". Then,
> this document will get "included" as the content in my "shell".
>
> Well, this works to a degree, but it requires that people use
> "site-relative" paths for all of their graphics and links, which is
> way, way to much to ask. After all, people are using WYSIWIG editors
> such as Dreamweaver and even Word to build their pages. Typically,
> site-relative paths don't work in these environments. They shouldn't
> need to upload their document to preview it.
>
> It also requires that they put their page within a 550 pixel wide
> -td- tag. I'd love to drop that requirement.
>
> So, now I considering the following: A parser that will convert any
> content into "includable" form. Relative paths will be translated to
> the site-root, etc. I'm a bit stuck here.
>
> There's got to be a better way.
>
> Thanks.
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
