At OpenEd09 I was part of a very necessary conversation. We were talking about different ways in which our respective universities use WordPress MU. The consensus was that in order for us to be truly successful we need to be sharing much more. Sharing our frameworks, sharing our plugins and sharing our hacks. Boone Gorges frames the conversation nicely here and talks about what is needed from developers. Enej and others responded by reviving the OLT Dev blog. However, Matthew Gold rightly said this:
But we need to build more lasting channels of communication soon, lest we miss some important connections
So here is my attempt to provide those connections:
WPMU For Education blog
The basic idea is an aggregation blog for “WPMU for education” developers. Jim Groom provided a blog from his WPMUEd domain so that a new channel, dev.wpmued could be created. I used the Add Link Widget with FeedWordPress to turn this blog into an aggregation of content from developers who are working on developing WPMU in education using the method that Jim and I came up with. I seeded it with a few of my often read WordPress MU in education blogs (myself, Jim, D’Arcy, Boone, OLT and CUNY Dev). Continue reading “dev.wpmued is live! Calling all WordPress in education developers to contribute.”
photo credit: bionicteaching
At OLT we have decided to make our steps to develop the WordPress Multi-user platform into a university content publishing platform more prominent, so as to encourage sharing and collaboration. Before this we were all writing about our development on different blogs dispursed around the internet, but now we will all be putting our thoughts, ideas and code in one place. OLT WordPress Development now lives on the UBC Blogs site at blogs.ubc.ca/development. It is sparse at the moment, but once all of the developers are contributing their work it should fill out quite quickly.
Now if only WordPress.com would get back to us on allowing us to put our plugins in the WordPress repository so they will all be on the main WordPress plugins page…
photo credit: drustar
One of the things that is starting to happen at OLT is that we are creating an increasing number of WordPress based websites. Using WordPress as a content management system is not a new idea at all, there are a ton of examples out there of WordPress blogs out there that have been turned into sites. There is however, a dearth of information out there on how to do it (there are some out there… including some in amazing detail from Alan Levine).
One of the things that I couldn’t find was a stable way to create a second level navigation that stays constant for every top level section. The problem with most of the solutions on the forums and sites around is that as soon as you drill down to the third level of navigation the second level disappears. As you can see at aboriginal.ubc.ca I was able to come up with a way to keep the navigation constant. Here is the loop that I had to create:
$secondAncestor = count($post->ancestors) -1; //figure out what level of navigation we are on, subtract one because we don't want to consider the top-level
if($post->post_parent!=0) //if the page is not a top-level category
echo '<h2 class="widgettitle">In this section:</h2><li class="sidebarlist">';
//the following lists children of second level ancestor of the current page.
else //if the page is a top-level category
//listing only the child pages of the current section
$children= wp_list_pages("title_li=&child_of=".$post->ID."& sort_column=menu_order&echo=0");
if($children) //this will stop it from displaying a section heading if there are no elements in the section (for example on the home page)
echo '<h2 class="widgettitle">In this section:</h2><li>';
This is the first time I’ve blogged code, I’m not even sure if it is readable… but here’s hoping. Basically I figure out what level of navigation the user is on and then list the pages of the current page’s ancestor… that many levels up (subtracting one for the top level navigation.
I am currently doing a lot of work on using WordPress as a content management system including coming up with plugins and modifications for using WordPress MU as a multi-site manager used purely for websites and not for blogs. Will blog it all once everything is stable and working.
so here is a mapping of my plan for a UBC content management strategy. It is designed to overcome two obstacles:
1) Content changes, therefore the content stored in repositories has to change and be updated when the source is updated. This is overcome by using a wiki (this has been Novak’s vision of content management for a while) that produces RSS feeds along with an aggregator like Feed WordPress that updates the repository when a feed gets updated (that feature is still buggy at the moment, but I will get to fixing that ASAP).
So here is what it looks like (click on it for larger view):
So it’s 4:30 in the morning and I am nowhere near ready to go to bed. So instead I did the final quality testing for my “add user widget” WordPress Mu plugin.
This plugin eliminates the question that I’ve been asked plenty of times “what if a student who is not in the class adds themselves to a course blog?”. I think the answer is simple (and I think Jim and Brian would agree with me)… just delete and/or ban the user. However, in order to eliminate this barrier on implementing course blogs I modified the plugin to allow professors to enter a list of student emails. If the student’s email is in the list they can then add themselves to the list. This means that in conjunction with my Add to BDP RSS widget that Professors or institutions can decide whether anyone can add themselves, subscribers to the WordPress Mu system or only users that are in a specific list. This will now work for all three of the course blog types that I created.
This plugin is a modification of sidebar add user widget by DSader. It adds a whole bunch of control functionality that allows admin to change who is allowed to add themselves to a blog and also what type of permission is allowed. It also changes the way that the widget appears depending on the user’s status. It was developed primarily for course blogs.
Final, final update:
WordPress. org has started to show OLT some love and we are now rapidly publishing all of our plugins there. The new direct link to download sidebar add user widget is here and the plugin page is here.
Now that OLT has a place to house its plugins I will no longer be maintaining add user widget on this site. Instead it will live on blogs.ubc.ca. The direct link is here.
Fixed the problem with the plugin not reloading user’s status when they first add themselves.
Changed the way restricting users works. Now the admin can simply set a password in the widget control menu and users who know the password can add themselves to the blog.
Just drop into the mu-plugins folder.
Any problems/suggestions just leave a comment
So here they are, examples of the three kinds of blogs that I outlined in this post, as well as explanations for how to create them within WordPress MU. Jon has kindly let me use his Spanish 312 class as and example, so some of my examples are actually fully populated and active courses. (click on the headings to see the actual blogs)
This blog uses BDPRSS to output the content of an aggregated feed of the class. I created a widget to add to the list in BDPRSS so students can auto-populate themselves into the course. The other feature that I developed for this blog is an auto-populating class list (with the heading our class). The class list is the reason that I took so long to get these examples up and running. I spent a good chunk of this week working on an “add to blogroll” widget so that students could add links to their blogs in the sidebar. I tried many methods, but just couldn’t get the plugin to work. Gardner Campbell was paying a visit to UBC and while he was showing me some of the successes and issues that he has been having with his course blog Rock soul Progressive I saw that he was using the BDP RSS widget to display comments. A light bulb went on and I realized that I could simply tweak the widget to show a list of blogs in the course. Here is what you have to do:
- Create and output format in BDP RSS that contains the same blogs as the one that is being used to display entries in the course.
- In the “output format types” section select the radio button that says “list by sites alphabetically”
- In “about the items” set “maximum items per site” to 1, check “print site names” and “only display item’s title”. Uncheck “print the item’s age”
in the “XHTML formatting” section, add list tags around “title for each site” and comment tags around “each item’s title”. (see picture )
If you add the BDP RSS widget for the output to the sidebar then you create a class list.
This blog uses a spamblogger (I’m using feedWordPress because it actually updates posts if they are changed in the original feed) combined with BDP RSS to quickly create the course. Basically what happens is a feed aggregated by BDP RSS is fed into the spamblogger and feedWordPress republishes it. I have three reasons why I run the feeds through BDP RSS before I feed them to the feedWordPress:
- I’ve already created my Add to BDPRSS widget to add feeds to BDPRSS. If I wanted students to add their own feeds to the spamblogger I would have to create another widget (and the widget would have to be specific to the spamblogger).
- BDP works really well with a large range of feeds as well as with a large number of feeds. It acts as a kind of normalizing process, ensuring that each entry is parsed in the same way.
- It allows for the auto-generation of a class list as described for the ghost course blog.
This Blog is the simplest to set up and is probably closer to what most faculty members will imagine when they think of a course blog. I simply use the sidebar add user widget to add authors and the Wp-Authors widget to display the class list. Quick and simple. My example isn’t as good as the others simply because all of the content had to be written from scratch (or copy pasted from Wikipedia). K1, one of the work study students at OLT was kind enough to post a few items under different authors to show how this kind of course blog would look.
A fourth option is of course mashing the Spam Course Blog and the Communal Course blog together, thus giving students the option over whether or not they want to have their own course.
If there is anything that I am missing in my thinking here, please let me know.
Some notes on policy and where I’m going from here: As I have been making these ways for students to self-populate a course, the question keeps on coming up “what if people who don’t belong to the course add themselves”? At the moment the sidebar add to BDP widget gives three levels of permission, global (anyone), system (on the same MU system) and blog (subscribers to the blog). I will be working on changing the “add user” plugin to accept a list of people (I’m thinking student numbers or emails?) and check those against people who are trying to add themselves to a blog. This would mean that a professor could just paste a list in the control of the widget and not have to worry about people who are not in the class adding themselves. Then to close off the spam and ghost course blogs one would set the sidebar add to bdp widget permissions to “blog” and display the add user widget forcing students to add themselves as subscribers to the blog first so that they can be checked off against the class list before adding their feed.
Here is my first WordPress plugin. It is meant to extend the excellent BDP-RSS plugin by Bryan Palmer. This plugin allows users who are logged in to a WordPress MU system to add feeds to the BDP-RSS feed aggregator from the sidebar. It is primarily designed to allow students to add the feed of their own blog to a class aggregate blog.
Please let me know what you think.
Just download, unzip, then drop the plugin into your plugins->BDPRSS folder and activate in the plugins menu.
Update: For some reason the control is not saving the options properly. I’ll fix it on Saturday morning.
Update: Version 1.2 released.
Changed the way that permissions work.
- Simplified things by only allowing registers users of the community to add their feeds.
- Gave admin the option of password protecting a blog so that only users who know the password can add feeds
As always, let me know what you think of the changed.
Update: Version 1.1 released.
- Fixed subtitle bug
- Added control over what type of user can add feeds.
- Global: Anyone can add a feed
- System: Anyone on the Mu System can add a feed.
- Blog: Only a subscriber to the specific blog that the widget is on can add a feed.
- Made it so that if a user cannot add a feed, they don’t even see the text box.
In a comment on my post “who owns a class blog“ Jim Groom said:
That is the rub, when you open up a system like this, there are a number of ways of going at it, and having the ability to meet as many of them easily makes your life simpler.
I agree whole-heartedly with Jim. My judgment has been clouded lately by the Wp-o-matic’s ability lack of to update posts on the fly and the lack of a “delete all” button on any of WordPress’ pages. Today though, I saw the light. I now have a clear vision of three simple, definable, student driven course blog structures.
The ghost blog:
This blog is for the professor who doesn’t want to be confused by hundreds of student posts knocking around his/her blog. The blog simply uses BDPRSS and my add-to-BDPRSS widget (source code coming soon I promise) to populate a WordPress page with aggregated student entries. When another year of students comes, the old posts will still be there (or not, or in another blog that that the new blog links to), but as newer posts come in, the old posts will fall off of the bottom of the feed and the blog will have just new fresh content. No having to delete anything!
The Communal blog:
This blog is for the professor who wants to get stuck into the blogging experience with the students. This also probably the easiest (although I used to think it was the hardest) to implement. Jim reminded me of the “Add Sidebar Users” widget, which I will tweak slightly to make setting up this kind of blog super easy. Our new blogging service will allow students to sign up as just subscribers if they want to and with Campus Wide Login they won’t even have to remember their username. Zero work for the professor!
The spam blog:
Jim did great things with WP-o-matic. I found a tool that works even better for what we want to do (in fact, it is the one thing that I can now do better than the current incarnation of eduglu). FeedWordPress by Charles Johnson is another spamblogger that updates entries if they change in the feed. The biggest problem that I had with other versions of spam blogging tools was that they took dynamic content, republished it and then made it static. This might work for blog posts (which don’t generally change very much after they have been written)… but for something like a course syllabus or wiki feed (I’ll save that discussion for a later day) the content in the repository has to be continually updated. Otherwise we just have old junk entries lying around. FeedWordPress fixes that. FeedWordPress also has a nice “delete all” button that will get rid of feed entries that are marked for deletion. Best of all, the author has provided an excellent API and a bunch of hooks so that I can massage this plugin into doing my complete bidding.
I will be finalizing and testing these methods tomorrow and over the weekend and will hopefully have some concrete examples by early next week.
One last thing. These structures do not have to be independent. the communal blog can be combined with the spam blog (giving students the option). A ghost page can then be created in a different tab, feeding in content from other sources as examples and even points of discussion for future posts by the students. A ghost blog can be archived by simply feeding it into a spam blog and so on.
So after a lengthy discussion with Vince today I have decided to change my mind on a few of the things that I seemed so certain about just a day ago.
So here is the deal:
I wrote that we would allow professors who so wished to republish all of the student’s blogs into a class blog using wp-o-matic. I’m not sure if we should do that anymore. My reservations come from that fact that if it is republished in the Professor’s blog then I feel that the students loose ownership and that rings strange to my sense of morality.
Let’s consider a few hypothetical situations where a student writes for a class and his blog entries are republished in a class blog :
- A year down the road the student realized that what he wrote does not represent him and he wants to get rid of it. He can delete the entries in his blog, but they will still be saved in the class blog. He could of course ask the professor to take his posts off, but what if it is 10 years down the line? What if there were a lot of other students who feel the same way?
- The student decides to delete his blog. If the professor decides to publish the class posts (without attribution), the student has no way of claiming authorship over the post.
There are also hangups for the professor:
- If the professor accidentally resets wp-o-matic It will recreate all of the entries. WordPress doesn’t have automatic mass deleting of entries (I mean we could write a plugin for it… but plugins take time).
- If the student updates their blog then those updates are not automatically reflected on the class blog.
- If a student adds a strange feed (one with say 150 items regarding unsavoury topics) then if those are republished, it is a nightmare to get rid of them. If we just use BDP RSS, all it takes to undo the damage is delete the feed in the BDP RSS options menu
There are probably many more reasons why actually republishing would not be a good idea.
So it comes down to figuring out why we wanted to republish the posts and finding alternatives.
- Creating a repository: I don’t think at this point we are wanting to create a repository, this isn’t eduglu (as I may have wrongly alluded to in my previous post), it is a blog based course platform where student input is used. A repository of teacher resources should be done in an entirely a slightly different way.
- Keeping examples of what students did previously: Why not just leave the blog active and create a new blog for every year that links back to previous years. Not only would this give the students an opportunity of pulling out if they don’t want their work published anymore, but it would also allow them to continually update what they have and allows the course to have a history. Using templates and import/export It would be much easier to create a new blog than to get rid of everything from the old blog.
I’m wondering does this make sense? Or are we missing something? We will probably change our minds a hundred times between now and October, but for now I think this model is the most sustainable and easy to implement approach, for us and for the professors.