resources for designing a good content publishing system

Question

The cms I'm currently working with only supports live editing of data (news, events, blogs, files, etc), and I've been asked to build a system that supports drafting (with moderation) + revision history system. The cms i'm using was developed in house so I'll probably have to code it from scratch.

At every save of a item it would create a snapshot of the data into a "timeline". The same would go for drafts. Automated functionality would pull the timeline draft into the originating record when required.

The timeline table would store the data type & primary key, seralised version of the data + created/modified dates + a drafting date (if in the future)

I've had a quick look around at other systems, but I've yet to improve from my current idea.

I'm sure someone has already built a system like this and I would like to improve on my design before I start building. Any good articles/resources would help as well.

Thanks

Answer 1

DotNetNuke is a good open source CMS, you could read the soure for that system to get ideas. Or you could simply use DotNetNuke.

http://www.dotnetnuke.com/

Answer 2

This sounds very wiki-like to me. You may want to look at MediaWiki, the system used by Wikipedia, which also uses PHP and MySQL.

Answer 3

I think using serialize() to encode each row into a single string, then saving that to a central database may be a solution.

You'd have your 'live' database with relevant tables etc., but when you edit or create something (without clicking publish) it would instead of being saved in your main table go into a table like:

id - PRI INT
date - DATETIME
table - VARCHAR
table_id - INT
type - ENUM('UNPUBLISHED','ARCHIVED','DELETED');
data - TEXT/BLOB

...with the type set to 'unpublished' and the table and table_id stored so it knows where it is from. Clicking publish would then serialize the current tables contents, store it in the above table set to 'archive', then read out the latest change (marked as unpublished) and place this in the database. The same could also apply to deleting rows - place them in and mark as 'deleted' for potential undelete/rollback functionality.

It'll require quite a lot of legwork to get it all working, but should provide full publish/unpublish and rollback facilities. Integrated correctly into custom database functions it may also be possible to do all this transparently (from a SQL point of view).

I have been planning on implementing this as a solution to the same problem you appear to be have, but it's still theoretical from my point of view but I reckon the idea is sound.