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!

I wrote previously about trying to hack Habari so that I could restrict certain users' actions. Soon, that will be unnecessary. I've been playing around with the yet-to-be-released Habari 0.6, and it's pretty good. I used Subversion to grab the "trunk" dev version from the code repository. Of course, that is subject to change, so some of the issues I'll be describing in this post might have been solved. Administrators can assign users to groups and then grant those groups privileges to do different things. There are a few holes though. For example, to allow any user to change his or her details, one has to give that user access to the "Users" part of the admin. That gives access to create, edit or delete operations. I want my students to only be able to access their own details. Fortunately, there are "hooks" into the administration menu and other APIs to restrict such actions. So I haven't had to "hack" the core code at all. I've created a plugin instead. Similarly, using the plugin API, I can allow student users to create blog entries and save them as drafts but not publish them. And I'm hoping I can find a way to "lock" them after publishing so that non-administrator authors cannot change them. I think I can do it by adding a proxy method to the Post class and using that in the HTML template to add or not add an "edit" link. Of course, I shall also have to deny access to the actual edit URL. All in all, it's looking pretty good.

Much has been said about the bushfires. Reading the stories in the paper is heart-breaking. Those of us in the cities are—with the exception of a bit of smoke—largely shielded from this although many would know some who are affected. So it's sobering to see sights like these from one's own home (about 30 km away)...

I've been playing around with Habari (version 0.5.2) a bit more of late—in support of my podcasting project for my students. The idea is that I could give my students a user account in Habari so they could compose short blog entries and link to the MP3 files of the lectures and other classes they have recorded. I've confirmed that Feedburner will nicely handle feed generation with the necessary <enclosure> and nice-to-have iTunes-namespaced elements. I'd like students to be able to log in and change their user details, but not do anything else to users. I'd also like them to be able to compose entries but not publish them. Habari's database schema includes entities called groups. It also has a permissions table. Users are assigned to groups and groups are granted permissions. This should be enough for what I wish to do. Currently, it seems that it's not used, though, as I can't find any instantiation of the Usergroup or Usergroups classes (and I've looked long and hard at quite a lot of the code). Users can log in and change their details. If a user clicks on any other user's name in the user list, his own details are presented for editing instead of the other's users. I think there ought to be a warning about that, perhaps via the notice() method of the Session class, but at least it's secure. What is weird is that any user can create users and delete any user. There's apparently no top-level administrator, even though the Habari installer asked for an administrative username and password. I checked each user in turn: they all have the same "status" as it were. I can prevent certain actions by assuming that the first user added to Habari is the administrator. The installer certainly leads one to suppose that the first user would be granted that role. By checking whether the user's id is 1, I can allow or disallow certain actions using a Plugin action_* or filter_* method. Still, it would be nice to change the "view" presented to the user. At the moment, my students would see the "Publish" button and click it. While I can intercept that action and change it to a "save draft", it would be better if the button could be removed altogether. I could change the template, but at the moment I'd rather use the Plugin API than hack the core. (The former is less likely to break wen I upgrade to a newer version.) Perhaps some of this will be rolled out in version 0.6. It sounds as if there's a bit happening for that release. But I need something working in two weeks' time.

I've been looking for a podacsting platform for work. The plan is to have my students record and edit lectures and tutorials, convert them to mp3s and publish them. I quite like Habari. If I were writing blogging software from scratch, I'd do things differently, but when I look through the code I can see why they've done the things they've done. It's so much better than the God-awful mess that is Wordpress. After reading this post, I've installed the plug-in and got myself a Feedburner account. I want to investigate using Feedburner to generate a podcast-aware feed. One problem I've encountered is that if you use a media player (e.g. Flash) in the markup of a page, Feedburner detects the player but not the file it's playing. So I think I'll have to go the way of Paul Boag, and place a direct link to the MP3 file in the markup for the blog entry. Another link might open a window, or take the user to another page which is not tracked by either Habari's Atom feed or Feedburner. Habari has different content types. By default, there are "pages" and "entries". Pages are meant to be like static HTML pages, as far as I can tell. So these would be a good candidate for presenting the media player to any users who might like to use it.