skip to main content

kiesler.at
TommydeJesus
Back to Page | Back to History

Difference between revisions

Version 8, 2005-04-06 15:49 Version 9, 2005-04-06 18:59
Lines 1 - 17 Lines 1 - 15
++ What is the future of phpWebsite? ++ Tommy de Jesus
   
What should that future be? The answer is harder than it probably should be. Development takes time, and the development team has done a great job on the core product, but advances in Approval, Categories, Menus, Users, and Groups do not seem to be a priority. And yet these are the areas which need the most attention. Let us start with Categories. ( picture of me )
   
One of the better ideas and yet not exploited nearly enough by the core. Why no association between groups and categories? Why no restrictions on Users as to which groups they can access to edit/create/view? I read where phpWS is concerned more with management than it is with content, but it seems the opposite is true. getting the content in the database is the priority, how it is accessed, and by who, not as much. So much power in one module used almost not at all. ( a few words about me )
   
Currently categorizing data seems more important to the whats related feature than anything else. And while I think that feature is useful, it is more window dressing than anything else. Categorizing both the content as well as groups should be a priority. ++ Projects
   
Groups as they stand right now serve little purpose. Without tying Approval to specific modules and specific groups, the group feature has little to no power. Here is an example of what it should do. FutureOfPhpWebSite
   
A group is created with 3 members. Lets call the group Financial Aid. This group gets categorized as well. We will call the category financialaid. The group can then only edit content in the financialaid category, and all new content is assigned to that category, unless another category is added to the group. The you could choose from 2,3,4 categories, depending on how many are assigned to a particular group.  
   
One user in the group has approval. The other two can create/edit content. The user with approval is sent an e-mail that that content needs to be approved. This content goes into a holding area. The old content stays available to the general public until the new content is approved. This would apply to all content modules, including 3rd party modules. ++ Places I visit
   
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. ( my favourite links )
   
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.