Hello Admins and Mods
this sounds really well, but there are some unsolved issues.
1) I keep wondering how the Pages could be integrated in the Navigation, without letting users change the Navi?
2) The Sidebars: Should a User be able to create a Sidebar for her / his own Article? Or would it be better if there are several standard sidebars, which could be inserted "context sensitiv"?
- Output should be static HTML/php pages for minimal CPU performance hit.
I like the semi-static PHP approach - if we have comments on the pages, it is nearly impossible to be 100% static - but 1 call to the Forums DB should be cheap.
BUT this approach makes it harder to offer full text search on the page, without having something like Apache Lucene running in the background. The Zend Framework offers a interface for Lucene, but Lucene is still needed in the backend, because Zend haven't done the indexer port to PHP now...
- Ideally it would integrate into the forum software to support searching.
this would solve my point above, but then it is not possible to do it "static"? Or do I miss the point?
- It must integrate into the forum to the extent that its easy for people to add comments on downloads and articles.
This is one method - anotherone would be to create something like a "summery" Post in the Forum for each "content" page. Then the comments can easily go to the forum (which means no spam, new members and authentication for free). Displaying on the "content" page would very easy - just pulling them out of the database.
- A generic template system that can build on demand create static HTML website hierarchy of pages from "templates" and a hierarchy of content pages.
Huh??? - Sorry, I don't get it...
- Such a system of being able to extract info from posts might also enable us to build a kind of "bookmarking" system where users can mark which posts threads they want to assemble on a page like a portal.
This would be a great feature - something like a personal portal
- A generic rebuilding-table might be kept track of so the system knows which static pages need to be rebuild when certain forum "posts" change or are added.
Such a table could be really painfull - and this is the BIG problem with the static approach *ImScared* - and I don't know how often we had to generate static pages - maybe we should drop the static approach and invest time on some caching strategies?
I had some (very "raw") ideas - I told mouser via PM - on how to do this CMS. In the last few hours I thought about some details. I think my approach can satisfy most of the requirements... Give me a little time (Saturday) to put it into words...