Authors

TommydeJesus and ReneKiesler

What is the future of phpWebsite?

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.

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.

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.

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.

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.

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.

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 not do that, But Article Manager Does)

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

The developement team is proud of its code. And it should be. Since the initial release 0.6, every major phpWebSite release involved a big rewrite of the core. Modules of 0.8 for example are not compatible to 0.9.

Still there is enough room for improvement. One might think that there is not enough developement capacity for the core. Different to most known open source projects, open patches can be found for as long as 2 years ago. The status of patches is unclear, some seem to be included in the core already but one cannot tell for sure.

Developing new modules

Developing new modules is a tendious task. For the most basic functions, like showing tabular data in lists, there are a lot of different APIs that are incompatible to each other. You want to do a html-form? Choose one of three different approaches. The not-yet-scheduled 1.0 release of phpWebSite will be incompatible to the current apis but have a compatibility layer.

The APIs is not final, so technically speaking phpWebSite is still Alpha (not even Beta) -- far away from a productive release. Am I impatient? Maybe.

Fact is, no API means a discouraging of module developement. And applications are -- in a similar manner like ease of use -- what most people want to use software for.

Top Down approach

Right now, it seems that phpWebSite is developed from a bottom-up approach. There are experiments regarding the core, APIs are rewritten all the time and there is no current documentation. Writing new documentation is also pointless, so is serious module developement.

A different approach would be top-down. There would be one API, roughly implemented and ready to use for all developers. Modules would be written in parallel to the core developement. The core would be improved all the time under the hood and at the same time, wonderful new modules would be created.

This approach would require a stable, easy to use but yet flexible API (not a stable core). The easier the API is to use (and I am not writing about performance here) the more it would encourage people to write modules. A good API with a good documentation would allow good modules.

Not hacked ones like seen all over phpWebSite which implement centralized features all over again.

Module developement guidelines

It would be great, if modules would APIs themselves. With callbacks. One could then extend modules very easily and recycle their methods. Take for example "Add one entry to calendar", "Store one photo into the photoalbum" or "Resize one photo to a certain size".

Right now, it is impossible to reuse these methods. The code is very confusing, again, there is no way of accessing these methods outside the module itself.

It would be great to have some kind of developer forum. One that is not only open to geeks like Sourceforge. But more a classic web forum that would also encourage hobby-developers to write modules. Again: The more modules, the more flexible, the more people will find useful modules.

How about for example webmail, webmin for phpWebSite, phpmyadmin for phpWebSite, phpldapadmin for phpWebSite, and so on.

Central Method repository

Such APIs could be maintained from a central instance dedicated to doing so. One would enter "photo" and get all the APIs providing photo-methods in return.

Including photo-uploads to a forum, for example, would be as easy as a single method call. As soon as the photo-upload in photoalbums would be improved, the forum-photo-upload would be improved as well.

No need to reinvent the wheel all over again.

Development and the End User

Remembering first that this should be designed with the technically challenged at best. The staff assistant. The department head. The person that needs content displayed on the web, but has no web design or html skills. So it needs to be intuitive. Users assigned to groups. Categories assigned to groups. Groups restricted to the categories assigned to them. Menus associated with categories. etc. etc.

Development should always keep the end user in mind. Sometimes it is better to take a few steps back to see the larger picture. Since 9.2, there has not been a major change in the way content has been handled. (It could be even longer, but I started with 9.2.) Many of the management questions seen in forums about phpWebsite deal with the lack of intuitiveness concerning menus, categories, blocks etc. This results not in new modules being developed, but rather hacking existing modules to make them more intuitive not only to the content editor/manager, but to the viewer of the site.

Menus should be category driven. Link manager sould be as well, but in a way that interacts with the content in a way other than just whats related. A menu should be links within the site driven by category. Linkmanager could be associated with a specific category, or even a specific page only. Every group would have access to link manager because it is a repository of links. You should be able to add categories to a link, without removing an existing category. In other words, no dropdown menu with multiple select. More like dropdown, select, submit. It could work that way when you delete a category for any piece of content as well.

Webpages

We have already seen the success of Article Manager. PhpWebsite? should either adopt it into the core, or add the features of announcements to web pages. Do not continue to run a module out there that is inferior in every way to a module designed by a third party.

Link Manager

I still need this one explained. How do I associate Linkmanager with the rest of my content? How is it displayed? Why are categories assigned to it, when there doesn't seem to be a reason why? Really rather confusing.

Last modified 2008-07-16 12:19 by genrih99