| Lines 19 - 24 |
Lines 19 - 90 |
| Approval would also be filtered. If a user has approval, but then only has rights to Article Manager, but not Blockmaker or Calendar, then that user only sees Articles in his her group to approve. It would act more like a filter than a restriction, show the user with approval only the content they need to see. In essence managing the content better. |
Approval would also be filtered. If a user has approval, but then only has rights to Article Manager, but not Blockmaker or Calendar, then that user only sees Articles in his her group to approve. It would act more like a filter than a restriction, show the user with approval only the content they need to see. In essence managing the content better. |
| |
|
| Currently Calendar items get posted accross groups? René has re-written the Calendar module to allow it to filter by category. In this regard, the Calendar should behave in the exact same manner as Articles, Blocks, Announcements or Webpages. Why Groups are brought into this seems a mystery. Categories should be the driving force behind ALL content. |
Currently Calendar items get posted accross groups? René has re-written the Calendar module to allow it to filter by category. In this regard, the Calendar should behave in the exact same manner as Articles, Blocks, Announcements or Webpages. Why Groups are brought into this seems a mystery. Categories should be the driving force behind ALL content. |
| |
|
| |
++ Workflow |
| |
|
| |
A very important concept for general content management systems is workflow. In fact, as soon as you want to generate content in an enterprise manner, you need some kind of advanced process that controls who can do what and when. |
| |
|
| |
Workflow in phpWebSite right now is almost non-existant. You have approval, where you can either accept or delete something. And you have a timestamp, a edited-by and a created-by attribute. A couple of concepts are entirely missing: |
| |
|
| |
+++ messaging system |
| |
|
| |
similar to a task-list. you could give content a certain state. like: |
| |
|
| |
- draft |
| |
- request for comment |
| |
- soon to be released |
| |
- public |
| |
|
| |
and write a message with every status-change. you could put it in a moderation-queue. every editor would subscribe automatically to that queue and could work on entries. |
| |
|
| |
+++ support for departments |
| |
|
| |
(categories, groups, call it what you will) |
| |
|
| |
Every department should have some form of editors / moderators which superwise the whole department. But not the whole site. Companies are usually department-driven: |
| |
|
| |
- a newspaper has a sports, a politics, a social department |
| |
- a university has a technical and a linguistical department |
| |
- a church has a members and a preacher department (I am making that up, but you should get the point) |
| |
- a gamers portal has a software and a hardware department |
| |
|
| |
and so on. |
| |
|
| |
Right now, you are either god. Or nothing. Shades of gray would be great. |
| |
|
| |
(I think Typo3 does that) |
| |
|
| |
+++ embed different module content |
| |
|
| |
(asset manager) |
| |
|
| |
something like the swallow-hack, but on a larger scale. with a nicer interface. like a list of photos for example. on mouse over, it would show the thumbnail of that photo. On click, it would include the reference to that asset in the current document. |
| |
|
| |
(Typo3 does that) |
| |
|
| |
+++ version history |
| |
|
| |
similar to the Wiki-Module, but at a larger scale. I can envision for example |
| |
|
| |
- a drop-down box for earlier versions |
| |
- if an earlier version is selected, all new stuff would be embeded within ins-tags, all removed stuff within del-tags |
| |
- there would be meta-infos on some place of the screen (who changed what and when) |
| |
|
| |
(Typo3 does [http://www.carnet.hr/CUC/cuc2004/program/papers/list/b5_milovan_absbio.html not] do that) |
| |
|
| |
+++ distribute content to different branches |
| |
|
| |
certain people would have the right to distribute content to different branches. They wouldn't be copied but linked instead. That way, global companies could use phpWebSite for a corporate company as well. |
| |
|
| |
This would also be useful on a smaller scale. Like on a university, where you would like your branch to show certain important announcements of the university site. |
| |
|
| |
(Typo3 does that) |
| |
|
| |
+++ multilanguage content |
| |
|
| |
as soon as phpWebSite would support different versions of the same content, we would also gain multi-language content. Basically "for free", as there is almost no additional effort involved. |
| |
|
| |
(Typo3 has that) |
| |
|
| |
|
| ++ phpWebSite as an application frame work |
++ phpWebSite as an application frame work |
FutureOfPhpWebSite
