Spanspek

This post is not, as you might imagine, my opinions about what the developers of Habari ought to do next. Rather, it is about what I must do to make Habari suitable for podcasting of music and classes at my workplace. As I stated previously, I wish to have my students record some classes and music performances for podcasting. Habari has a podcasting plug-in which handles uploading of files and modifying the Atom feed accordingly. I have yet to play with that properly, but it seems to do what I need. I was going to use Feedburner, but the need for that is somewhat less now that the plug-in can insert the apparently necessary iTunes-namespaced elements. As iTunes is almost the only game for subscribing to podcasts, this is probably sufficient. The other requirements for this application are:

1. Students should be able to create entries and upload MP3 files.
2. Only staff should be able to publish entries.
3. Students should not be able to edit entries after they have been published
4. Students should not be able to add or configure themes, plug-ins, or other options, or import entries from other blogs.
5. Students should not be able to add, edit or delete other users.

Number 1 is achieved with the current users and groups permissions system. Number 4 is taken care of by the permissions system. Number 5 is not quite taken care of by permissions. Numbers 2 and 3 need to be done with custom actions in plug-ins. I have created a plug-in which I call Publisher. It intercepts various actions and modifies them. For example, if the user is a "student" rather than an "administrator", it modifies the administration menu beyond what the group permissions system does to allow a user only to edit his or her own details. However, removing other options is not sufficient as a user with a knowledge of Habari's URLs could type the URL for any of those options directly in the browser's address bar and access them directly. So my plug-in also restricts this access and redirects the user to his own details instead. The plug-in also prevents non-administrative users from editing posts which have been published and removes access and links to editing published posts. I have examined various of the plug-in hooks but the only I have been able to find to remove "edit" links is to filter the 'include_template_file' hook. This povides a means of including custom template files. It would be better to intercept elsewhere as this hook applies to any template file loaded by Habari, not just those forming the admin UI. I'll work on finding a better solution later. For now, let's just say that not all hooks are documented. The same page of the admin area that I'm trying to modify also includes a way to delete posts. Despite the groups permissions system allowing editing of one's own posts only, deleting any post is possible regardless of one's privileges. If the Undelete plug-in has been activated, the deleted post can then be edited and saved as a draft by a non-administrative user. (Keep in mind that a user in the "student" group—a group that I created— should not be able to edit any posts but his or her own.) This anomaly might have been fixed in subsequent builds. I must check it out. (It's currently revision 3286, whereas I'm using revision 3137.) I also have to work on a theme for the podcast and, as I'm not a designer, this could take some time!