UBC WordPress development out in the open

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…

WordPress as a CMS… Advanced Navigation

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:

<?php
$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.
wp_list_pages("title_li=&child_of=".$post->ancestors[$secondAncestor]."&    sort_column=menu_order&echo=1");
echo '</li>';
}
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>';
echo $children;

echo '</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.

The last piece of course blog the puzzle… for now

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.

Three flavors of course blogs, very yummy…

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.

1. 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!

2. 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!

3. 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.