CMS design

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

CMS design

Post by alex.barylski »

While considering design/concepts, etc for my second version of my CMS...

I ask myself, what type of system most people prefer to deal with?

In the backend, my CMS uses a front controller type approach where all requests to display a page are done through a single index.php and actions are carried out intrinsically via FORM actions, etc...using seperate modules.

In this regard it's not really modelled after the model 2 architecture, but it more closely resembles model 2 architecture than model 1, because it does use a form of front controller.

Thats the backend, where clean URL's are not an issue as no one cares if Google spiders their admin pages anyway (in fact that could be bad and likely wouldn't work without logging in first anyways)

So, model 2 makes sense for me here and it seems it's common amongst most CMS applications.

My client generated pages is where I take a slightly different approach to solving the problem, instead of using model 2 approach, my CMS actually generates the phsyical web page as a file, which is invoked by normal clicking.

In this regard, model 1 offers several advantages:
1) No mod_rewrite required for clean SEO URL's
2) Slightly more efficient as no front controller, mapping, etc is invoked...possibly important when having a massive article repository pidered by Google, etc...
3) Most flexible and extensible. There is no need to hack into the CMS itself when adding PHP functionality to any given web page, as each page is just a PHP script.

Of course there are many disadvantages as well:
1) No DB means inbuilt extensibility is difficult or at least more work
2) Searching, archiving, etc becomes a difficult task to implement
3) RDBMS seriously make life a lot easier :P

Some short falls can be circumvented using existing 3rd party libraries. For instance I could add search engine support by using a class like Lucene search in the Zend library or others.

Basically my backend is modelled after model 2 and my front end is more analogous to model 1.

My CMS works more closely to say a web enabled version of front page, then it does an CMS of the PHP variety...

So I'd like to hear opinions, design suggestions, etc...

I guess there is no point in starting a second version using the model 1 approach for the front end if everyone agrees dynamic URL's are acceptable or if need be...mod_rewrite is always available...

My next version will likely use Zend and at this time AFAIK mod_rewrite is mandatory, althought sounds like that is going to change as a requirement...

Edit: I should also note, that currently my CMS doesn't require a RDBMS as I wanted pages to be availble even under DB down conditions, but I'm re-considering that approach as well???

Cheers :)
Yossarian
Forum Contributor
Posts: 101
Joined: Fri Jun 30, 2006 4:43 am

Post by Yossarian »

I think you are right to stick with static files. :)

I work in a vertical market. Our CMS has grown to cope with the vagrancies of that market.

(Employees, or Users of the CMS)

Employees leave.
Employees sometimes are not replaced
Employees are sometimes not motivated, but their bosses are
Employees are sometimes motivated but their bosses are not
Employees sometimes come from places where Frontpage (or clones of) is used rampantly
Employees sometimes want to do very strange things on webpages

Our users have urls they can spell out on the phone to your granny.
Even the press can spell the urls correctly.
I can oversee the urls names.

I manage 2 cms's.

First is an old frontpage -> asp -> php conversion (Ive been there a long time).

The Second is total dbase driven - elements of this I keep moving back into the First.

The First is the most interesting.

I studied the behaviour of Users of the First for a long while and created 3 main types of content, defined by their need to be dynamic. Hence the CMS contains:

1 Static pages (as described below and they change once a year on average)
2 Dynamic pages (users want to publish/delete/amend all the time this inlcudes Stories, FAQS, News items, Polls)
3 The "supporting pages" or navigational pages if you will.

I keep all the navigation, css file, metadata, page owner, last updated comment, section it belongs to etc for each page in the database.

Each static page gets its own "smartness" and relationships with other metadata out of the database by telling the db its "number".

So static files look like this:

Code: Select all

/yoursection/basic.php
<?php
$page="1234";
include("head.php")
?>

....

<p>Start the main division of the page here:</p>
<p>Just valid markup here</p>

....

<?php
include("foot.php");
?>
Now there are other benefits to doing this.

I can get someone who does know basic xhtml to update pages.
I can ovewrite any page and add things like image maps, embed objects - or drop in a PHP app of my own.

I can allow a user to control all of the meta data - that metadata manager I have christened a "MMS" Metadata Managemnt System.

This MMS takes care of all of these kind of navigational pages:

Table of Contents
Navigation breadcrumbs
A to Z
Navigate by meta data (or Tags if you prefer)

Any static page can contain any of the dynamic elements by just writing a line like this:

<?php get_news(3); ?>

Which if section number 3 had any current news items would output their fancy table with news, and vanish when their sections news is empty.

Some pages are solely dynamically driven.

Code: Select all

/yoursection/news.php
<?php
$page="1234";
include("head.php")

get_news($this->section_ref);

include("foot.php");
?>
But they are still fixed, dependable URLS.

So, rambling on, heres my point.

I am rewriting the MMS now.

My next move is then to turn to the CMS and improve it, to create a 4th kind of page, for which there is an internal market (ok, a clamour for), a "more dynamic Static page".

In my head I see this being xml based and managed from a gui.

So:
Users login and see a webpage which allows them to edit an xml file.
On save the xml is transformed into html and cached - back into the correct address.

I want the gui that controls the xml to allow the end users to write the equivalent of :

<?php get_news($this->section_ref); ?> in the html stream.

And for basic paragraph text I want them to be able to use a wysiwg editor.

I see this 4th kind of page largely replacing the static pages over time.

I havent started on this part of the CMS.

I have been studying/using oop for over a year now, I am all PHP5, I UnitTest everything (probably not too correctly, I admit) I will use MVC for the admin area (currently using CodeIgniter), The MMS is about half-written using CI.

Users will be able to create pages - but they wont be published until I (or someone) allocates it a sensible URL. Users will not be allowed to delete pages - because that is silly thing to do on the internet. If it was going to be deleted then why was it created?

Occassionally pages MOVE (leave a redirect).

Ring any bells for you?
Post Reply