Tag Archives: wordpress

WordPress as a Data Collection Tool

A few weeks ago (actually, I think it’s more like months at this point), I blogged about publishing my first plugin on the WordPress Repository. I thought I’d take a moment to write about what that plugin is — and the projects I’ve been working on that inspired it.

Making data collection as easy as cheese

Continue reading WordPress as a Data Collection Tool

Hacking a WordPress Hacking Workshop

The inimitable Boone B Gorges wrote a great post yesterday about the WPedu community, and how we need to do a better job of inserting ourselves in the larger WP community — and sharing the work we’re doing. I’m trying to take his words to heart. As I mentioned in my comment on the post, I’m a reluctant sharer of my WP work–mostly because I tend to think it has little value to anyone but me. But there are other reasons, that are probably (sadly) tied up in the whole “imposter syndrome” that infiltrates most of academia. Even a lowly staffer/mid-tier administrator (like me) at a University can fall prey to this disease. I aim to overcome it.

To that end, I’m going to try and blog more in this space about the work I’ve been doing with WordPress over the last 6-12 months, particularly working on aggregation methods for learning communities. I got into Web design/development years ago because I loved how it allowed me to architect experiences. I got into higher education at the same time because I really do believe that education is one of our society’s highest callings. Blending my passion for education with my passion to craft experiences is basically what drives me. Over the last seven years or so WordPress has become the platform upon which I can enact these passions. To be able to make code do things that affects people’s behaviors and feelings seems almost magical to me. And, as I’ve said before, I believe strongly that the fundamental nature of the code we work with speaks to the values we’re trying to embrace in the practices that our code enables. I love WordPress because it affords me possibilities. It affords me possibilities because it is open.

All of this is on my mind as I prepare to fly tomorrow morning to San Juan, Puerto Rico and conduct a couple of workshops with students at the Universidad del Sagrado Corazón on hacking WordPress. Given that this is the challenge that’s been looming ahead of me for the past few weeks, Boone’s post couldn’t have come at a better time. I kind of needed a kick in the pants to just get over myself and start imagining that I might have something valuable to offer these students. I’ve spent most of the past 2 months (since another inimitable, Antonio Vantagiatto, extened this invitation) wondering how the heck I was qualified to conduct these workshops.

I think I more or less know how I’m going to approach the program. I want to start by stepping back and talking a bit about the philosophical foundations that underpin the work that I do in WordPress — this includes my own biography as a English degree undergrad who moved into the world of ed tech and finally found herself working more and more as a programmer hacker. People are always amazed when they find out I studied English as an undergrad. I never quite understand why. Don’t they know that code is poetry? Seriously, I’m going to talk a bit about the relationship between code and poetry — a relationship that I’ve always found fascinating. I’m also going to talk about code as a tool for building experience. Finally, I’m going to talk about the way our values and politics (small “p”) inhabit the code we work with.

From there, I’d like to talk about my own organic growth in the world of WordPress. I think that the experience I’ve gone through learning how to work with this system (and attempting to bend it to my will) has taught me more about learning than any other experience in my life. When I started working with WP in 2004, I was just a blogger. The files that comprised my blog installation were thoroughly opaque to me. As I’ve developed deeper skills with WP, I’ve learned to essentially speak a new language —   the language of the application. I understand how themes are built, how templates are arranged in a hierarchy. I understand how functions provide a fundamental syntax around which I can craft a space. I understand how plugins extend the language in both predictable and unexpected ways. When you hear a foreign language for the first time, it’s almost impossible to imagine that you will ever be able to decipher it. That’s how I feel about my first experiences of WordPress. While I know I’m still not fluent, I’ve learned enough now to believe that I can figure out what the things I don’t know mean.

Finally, I’ll be spending time with the students asking them to actually DO something in WordPress. This has been the hardest part of preparing for the workshop. I’m not entirely sure how comfortable they are with the system. For all I know, they can code circles around me in WordPress! In the end, I’m going to approach this on two fronts: I’m assembling a resource for them that points in useful directions based on the kinds of thing they want to do in WordPress. I’m not providing answer; I’m just providing pathways. Then I’ll go in with a list of challenges/activities that we can tackle. Everything from basic tweaking of a theme to writing a plugin. Based on what they’re interested in, we’ll pick a few to work on in groups and see where it gets us.

That’s Friday’s plan. On Saturday I meet with a smaller group of WordPress developers at the University who are working on a grant project. I’m hoping to show them the work I’ve been doing with aggregation of posts and latest content both within Multisite and from external RSS Feeds. Hopefully, we can carve out a plan for them to use some of this in their own work and maybe even start building it.

I can’t remember ever being this excited — or this terrified — about leading a workshop.

What Lies Within: Of Calendars, Hidden Data, and Hacked Templates

I’ve blogged in the past about my endless DTLT Web Site Redesign project. And I’ve committed myself to regularly blogging about what I’m doing as part of that project. And then, of course, I’ve promptly broken that commitment. Oops.

I guess it’s time for an update, and, to start, I want to describe how I’m handling event presentation on the new site. (We actually launched it a few weeks ago, but there’s still a lot more work to do.)
Continue reading What Lies Within: Of Calendars, Hidden Data, and Hacked Templates

DTLT Revamp: Custom Fields Are Your Friends

This post is the second in a series that I’m writing about my experiments with redesigning the DTLT Web site. You can read the introduction here. You can see all of the posts in this series here

There are a lot of places I could start my next post about the DTLT site, but given the critical role that I’m imagining for custom fields (and, hopefully, the Flutter plugin), I thought that might make the most sense.

 A Very Basic Introduction to Custom Fields

For those of you who don’t know, custom fields are a built-in feature of WordPress. They’re a part of the write panel for posts and pages, but you may have never noticed them. Here’s the default custom field panel:

Basically, they allow you to associate additional information with your posts or pages. If you read the official description of custom fields on WordPress’ site, you’ll see that the developers refer to this feature as a way to add meta-data to a post or page.  Basically, you choose a “key” for your field — that’s the name of the element — and a value. Once you create a new field/key, you can associate it with other posts/pages, by choosing it from the “Select” drop-down menu. You can also  also add a key to a post more than once.

But creating the custom field is only the first step. Once you’ve done that, the information is stored in the WP database, but it’s not going to show up on your post and page magically. You’ve got to edit the template to display the values. To do this, you use a built-in template tag (more on these in a later post) that you add to The Loop (which is the core part of WP template code for displaying posts and pages). The tag is just a simple snippet of php:

<?php the_meta(); ?>

With that bit of code added, your field values appear in your post/page (the location depends on where you place the code in The Loop). The technique is pretty simple, but it’s not terribly nuanced. All you’re going to get is a unordered list of  whatever custom fields are associated with the post, and a pre-existing style in the WP CSS will be used to style it (of course you can modify that style, but you’re still dealing with a list of content).

For more advanced approaches, there are some built-in functions in WP that allow you to do more than just display the custom fields in a list. You can find more information about them on the WP page about custom fields.

On that same page, I’m particularly intrigued by this text: “We expect that independent developers will come up with many interesting uses for post meta-data in the form of plugins. The the_meta() template function is just an extremely basic example.” What’s interesting to me is how few plugins I’ve found that do make use of custom fields. When I first started using WordPress a few years ago, I started looking around for more powerful/elegant ways of utilizing this feature, but I’ve never found very much. I think that’s kind of odd — to my mind, custom fields provide some really intriguing ways of extending WordPress.

If you’re interested in learning more about custom fields, I encourage you to take a look at some of these resources:

So, Why Do I Care About Custom Fields, Anyway?

My interest, quite frankly, is less in the possibility of adding meta-data to WP content. What I’m interested in really is being able to structure posts and pages, based on the kind of content that’s being created. So, for example, if I was creating a post about a project that we’re working on in DTLT, I could set up several custom fields for the various pieces that would make up a project content piece: Description, URL, Collaborator(s), Screenshot. There are three main reasons why I’m interested in this approach to content creation:

  1. I imagine it would let me do more interesting things in terms of presenting the content. If each piece of information is held in a different custom field “container,” I can arrange them on the page (in custom templates) and style them more granularly.
  2. If I pre-define fields for a type of content, then there’s a better chance of creating more consistent pieces of content, in general (particularly when multiple authors are working in a blog). If it’s important to me that a project post have particular types of information, then the custom fields serve as a kind of prompt to make sure each new post is complete.
  3. For certain fields, I can imagine wanting to “pivot” information presentation on them. For example, if I’ve got a “collaborator(s)” field for projects, I might want to be able to slice my project content up so that I can see all of those projects that a particular faculty member collaborated on DTLT with.

All of these reasons really require that I structure my content into different containers, and custom fields definitely seems like a way to do this.

Where Flutter Comes In

2008-11-26_1111I mentioned above that my search for WP plugins that build on the custom field feature has been pretty fruitless. Well, a few weeks ago, I finally turned up one that that looks like it has a lot of promise. Flutter (previously called Fresh Post), puts a more elegant front-end on custom fields, allowing you to define new “Write Panels” (essentially new versions of “Write Page” or “Write Post” in the administrative back-end of WP) with custom data fields.  You can define as many different write panels as you want, theoretically with each one designed to deal with a different flavor of content for your site.

2008-11-26_1116The first step in setting up a custom Write Panel is defining some options for it. You can see those in the image on the right. Being able to automatically define a category and set which default edit blocks appear is very cool.

Once I’ve created the custom panel, you can add custom fields to it. And, you have more options than just designating a key and a value for custom fields. Flutter actually has several field types that you can choose from:

  • Textbox
  • Multiline Textbox
  • Checkbox
  • Checkbox List
  • Radiobutton List
  • Dropdown List
  • Listbox
  • File
  • Image
  • Date
  • Audio

Basically, you define the fields you want to make up custom type of content and you build a custom panel for that type. When you’re done, you’re “Write” tab will reflect the new panel names (and you can hide the default Page/Post sub-tabs to minimize confusion).

Another very cool feature is that you can create groups of fields that can then be duplicated. So, for example, if I want to be able to add RSS feeds to a new piece of content,  I can define a group called “RSS Feed” with two custom fields, “FeedTitle” and “FeedURL.” That group can then be duplicated, allowing me to have more than one RSS feed associated with a post. I can then use something like SimplePie to display the feed(s) on the page. (I’m using SimplePie this way now with the “Person” content type on the new DTLT site. There’s no styling yet, so it looks crappy but you get the point.)

There’s a whole other level to Flutter that I haven’t gotten into yet — once you’ve created your custom write panels, you can then use a GUI editor to edit your theme with custom widgets (or so it seems). However, my initial research into this feature suggests it’s built on the Canvas WP template engine, and I believe that project is now defunct.

There are a few pitfalls that I’ve run in to with Flutter.

  1.  By default, the “File” field type uses a Flash-based file uploader that I can’t get to work in my version of Firefox (3.0.4) with my version of Flash (10). It took me a while to find out that I could opt for the standard file upload feature in the Flutter settings. (The Flash version did work for me on Safari. Sorry, can’t tell you what the IE situation is.)
  2. While you can disable the “Write > Post” and “Write > Page” subtabs, you can’t disable the “Manage > Post” and “Manage > Page” subtabs. It’s a small thing, but it could lead to confusion, particularly if there are multiple authors on a blog.
  3. When you create a custom write panel of the “Page” variety, you’re given the option to show or not show the category block. Well, pages in WP don’t use categories (unfortunately!). I thought that it was possible Flutter had found a way to assign categories to pages, but, alas, this is not the case. Looks like they just offer the same customization options whether the custom panel is a post or a page. For this reason, I’m using posts exclusively as the building blocks for my content. I need me some categories.
  4. The default WYSIWYG editor for custom fields of the type “text area” doesn’t seem to be as fully featured as the default WP editor. I’ve got the very cool cets_EmbedRSS plugin installed (kudos to Jim for pointing this one out), and while it adds the RSS button to the editor in the text area, it doesn’t seem to work. I’m not sure what’s going on here, but be forewarned.
  5. In a post that D’Arcy recently wrote about Flutter, he mentioned that it did some odd things to the main write panel, causing his posts to wrap strangely. I haven’t seen this behavior, but that doesn’t mean there isn’t something wrong.
  6. D’Arcy also mentions that what’s going on behind the scenes with Flutter is a bit klugey. This probably has as much to do with how custom fields are handled in the WP database as it does to anything that Flutter is doing, in particular. Basically, custom fields are stored in a table called wp_postmeta. Each new value is a new record, with post_id (presumably to associate the custom field with the proper post or page), meta_key, and meta_value fields. That seems a bit topsy-turvy — the fact that there is no relational structure where a new custom field becomes a new record, and then the values are associated with those records, but what the heck do I know? Flutter builds a bunch of new tables to store information about the different Flutter options that are then associated with the custom field records (don’t know how, yet; I haven’t really looked into it). Bottom line: I have no idea if the back-end database structure is going to affect any of the cool things that I’m wondering if I could do with Flutter. Guess I’ll find out.

For now, I’ve created five different custom write panels for the new DTLT site: Person, (News) Post, Opportunity, Project, and Resource. They each have a different set of fields, depending on what I imagine they should consist of. (I’ll blog later about what fields I’m using for what content, since that gets at a whole other, non-technology, set of decisions.) One of the cool things about this approach is that since at their core they are all just posts, you can use categories and tags as a way to slice across the different content types. So, for example, if I tag a (News) Post and a Project with “SteveGreenlaw,” then my tag page for “SteveGreenlaw” will show me all of the content (of any type) that is tagged that way. With a little template massaging, I think the display could be finessed to make that a pretty cool view of content.

What’s Next

  1. I’m really excited about diving into creating the custom templates to display these different types of content. I’ve finally wrapped my heard around The Loop (I think) and features of WP like template tags. I’m basically an ignoramous when it comes to php, so I’ve got a lot of learning to do (there’s another post here about a breakthrough I had about learning php — I’ve got to blog about that, too!).
  2. I’m also interested in figuring out if there is a way to filter WP content based on custom fields. So, for example, as I mentioned in my example above, if I’ve got a field called “Contributor(s),” can I create a display of content that just shows those posts that share the same value in that field? I’m sure there’s a way to do it. Question is if I can figure out how.
  3. Perhaps the biggest challenge I’d like to try and solve that I haven’t even touched on here is how custom fields can interact with RSS feeds. I’ve found at least one plugin that seems to allow for including custom fields in RSS feeds. The reason I’m interested in this is that I think it might allow for distributed authorship on a blog like ours. Truth is, we all blog in different places, primarily, and very often the contributions we make to our own blogs could be meaningful on the DTLT site. I don’t want to ask people to duplicate effort. So, I’m wondering if it would be possible to get a feed from our disparate blog sources that spits out the same custom fields as I’ve defined for the DTLT site. One of the cool features of Flutter which I didnt’ get into above (because I really haven’t tried it) is that Write Panels can be exported and imported. So, theoretically, I could share those custom panels with others running WP, and if they have Flutter installed and if I can figure out how to add custom fields to the RSS feeds and if I can figure out how to get the DTLT site to reconsume those fields, we could do something kind of slick. That’s a lot of if’s, and, truth be told, this part of my project is as much proof-of-concept as anything else. Mostly, I’m interested in experimeting with distrubuted authorship, and this seems like one interesting approach.

So, that’s it for now. Thanks to Jim for the shout-out about this project. Now that he’s “outed” me, I’ve got more incentive to keep on blogging about it. 🙂


One of my goals in my new role is to blog more regularly about the projects I’ll be working on. To that end, I’m going to use this post to kick off what will (hopefully) become a series about a project to revamp the DTLT Web site. I’ve wanted to tackle this initiative for several years, but I never seemed to be able to carve out the time.

Because I’ve been thinking about this site for so long, I have a pretty good idea of how I’d like it to shape up. That said, another reason why it’s taken so long to get around to doing it is that everytime the project came up around the table it seemed like we’d talk it to death — and I’ll be the first to admit to leading the charge on over-talking the issue.

This time around, I’m planning on just putting something out there that seems to make sense to me and that reflects (as much as possible) the conversations that we have had in DTLT over the years about a new Web presence for the division. I figure we’ll take our usual iterative approach and something good will emerge. Er, at least I hope so.

I have another reason for wanting to tackle this project — and wanting to blog it. For quite sometime, we’ve been speculating about the feasibility of using WordPress as an actual content  management system. We’re surely not the only folks doing this — there are quite a few more experienced WordPress users out there who have tackled this issue. And, undoubtedly, the work that my colleague Jim Groom does in WordPress pushes these boundaries (and inspires me) regularly.

It often seemed, however, that when push came to shove, there was always something that prevented WP from being the right CMS solution. Although I think I’ve always suspected that with the right mix of plugins and the right theme, the problems could be surmounted.

So the other thing I’m going to be trying to do in some detail is narrate the process of piecing together various WP plugins in order to strike the right CMS note, so to speak. I’ve already found a few gems that I think are answers to several of our Web site prayers.

In my research into how to piece this system together, I was surprised at how hard it was to find a comprehensive approach to WP as a CMS. There are lots of people talking CMSing WP on various forums or at various plugin sites. But I couldn’t find anyone who was tackling the problem “cradle to grave,” so to speak. (I fully realize I may have just missed some amazing resources out there — please let me know if I have!). I’m not sure why this is. In a conversation the other day, Jim speculated that a lot of the work in this area is being done for commercial purposes, and the developers may not want to share all the details of how they trick out WP. Well, I don’t care about that for my purposes — UMW’s paying me regardless. 🙂 So, I’m going to narrate away (including the missteps I take), and maybe I’ll create something useful for someone else down the road.

I tend to think about Web sites in terms of content types. I’m not sure that’s the best thing, but it’s how my brain works. Right now, I’ve got five main types of content I’d like to see us include:

  • (News) Posts: I’m calling them NEWS Posts just to dilineate them from the WP “posts.” Ultimately, I think I’ll be using WP Posts as the main content unit for all of these, and I want to not get muddled by the nomenclature. These are pretty self-explanatory: posts about news or announcement for our division.
  • Projects: These would be brief descriptions of past or ongoing projects with screenshots, links, and a list of contributors.
  • Opportunities: Any event, workshop, grant, contest, etc. that a faculty member of student might be interested in.
  • Resources: These would be short write-ups of tools, technologies, software, hardware that could be used by faculty to augment the learning environment.
  • People: To start, these would be write-ups of each of us in DTLT. Eventually, maybe we’d have write-ups for faculty collaborators

There are a few other features I’m intersted in:

  • Subscriptions: A main goal of this site is to provide faculty with more and better news from DTLT. We can send out all-faculty emails, but I kind of hate that approach. My gut feeling is a lot of faculty just delete these unread. I’d like to create a system that allows a faculty member to opt-in to receiving our news, and, hopefully, with some granularity about what kind of news he/she gets.
  • Events: I’d like a calendar of events. This is a bit tricky as there are other calendar sources that we contribute to at UMW. I’ll need to figure out if this can interoperate with them. I also need to figure out how Events and Opportunities are related.
  • A Non-Bloggy Theme: I’m really aiming to push WP out of it’s blog boundaries for this project. I know it’s possible to build a perfectly good site that isn’t really a blog by using a blog theme, but I want to do something different. I’m investigating tricking out one of the more magazine-style themes.
  • Cross-tagging and categories: To whatever extent possible, I’m hoping to use WP tags and categories to cross-link among all of the content typtes (that’s why it’s important to use posts and not pages as the content unit since pages don’t use categories)

I’ve probably put the cart before the horse here. Any decent Web developer would probably say I should start by outlining my goals for the site. Don’t worry, I’ve thought about those issues. But, truth be told, I’m a concrete thinker. I need to start futzing in order to solidify my own understanding of my goals. So I will expand on that, but a little later.

In the meantime, I have done some initial development and research. So if you want to play along from home:

  • I’m building the experimental site at http://www.marthaburtis.net/newdtlt. Be forewarned: this site is NOT ready for primetime. I fully expect to break it and blow it up regularly.
  • I’m going to post screenshots along the way in a Flickr collection. Link forthcoming.
  • I’m tagging stuff I find that might be useful at http://delicious.com/mburtis/dtltsite
  • Right now, the following plugins are looking very promising (particularly in concert with each other). If you know anything about them, feel free to share:
    • Flutter (formerly Fresh Post) allows you to create custom Write Panels that make use of WP custom fields (I’ve always thought custom fields must be part of the key to turning WP into a CMS
    • dTabs is a pretty slick plugin for creating custom tabbed navigation. It allows you to link a tab to a page, a post, a category, a URL, etc. The styling can be a bit tricky.
    • Idealian Category Enhancements allows you to designate a particular template to be used for a particular category, automatically.
    • AStickyPostOrderER lets you manually order posts within a category, bypassing the automatic reverse chronological ordering.

The theme I’m playing with right now is called WordPress Magazine. It’s a pretty clean, block-style, magazine theme. I’m not sure it’s the right one long-term, but it’ll do as I experiment.

So, I have no idea if this will be useful or even interesting to anyone else. But, that’s okay. In the end, I think this will be useful narration for me as I develop a better understanding of my project and my tools.

An Aggregation Fiesta

I’ve been in a bit of a blogging slump — call it a “pregnant pause” — and I’m deterimed to bootstrap myself out of it.

Part of my block has to do with the fact that there is so much going on, I’m not really sure where to start. I’ve got four or five posts brewing from ELI that I’m hoping to work through in the next few days, but for today, I thought I’d start by talking about a project I’ve been working on with Steve Greenlaw.

I don’t get as much time as I’d probably like to work on a lot of projects directly with faculty these days, so I’ve been really enjoying diving into his TLT Fellows project. Last fall, Steve and I started talking about how we could build an online learning environment for his advanced macroeconomics class that would really foster collaboration. He blogged a bit about it in December. In the past, he’s struggled with how to get the students to really synthesize all of the work they’re doing on a topic into a coherent, analytically rich final project.

In the end, we shied away from designing some more complex collaborative writing environment, opting instead for a rich course site that did everything possible to expose the work students were doing around the different topics at hand. Steve also altered his assignments slightly, so that collaboration was happening more in the earlier stages of the course, with a greater emphasis on individual work (building out of the collaboratively generated and aggregated content) for the final project.

For me, the challenge has been really pushing the boundaries of what we could do with RSS aggregation in a WordPress blog. None of it is earth-shatteringly innovative, but it does represent the most complex course aggregation site I’ve ever put together. It’s a completely unsustainable model for individual course site creation. But, as a proof of concept, I’m hoping it will point out to us whether or not this kind of rich aggregated environment is even useful. If it is, then I think that points us in interesting directions for future development. If it’s not, well, that’s another story.

I  wonder about that “other story” a lot. Deep down, I’m a geek at heart, and I love the challenge of figuring out how I can slice and dice feeds together to create interesting views of content. I often wonder if the compelling pull I feel towards building these environments has more to do with feeding my own needs and interests and less to do with what’s really useful resonant for students.

You can see the site in action at http://stevegreenlaw.org/econ488.  For those who are interested in the details, here are a few explanatory comments:

  • While the students are all blogging in UMW Blogs, we had to build the course site with an individual Bluehost install of WP. That’s because of the complexity of what I wanted to do with template editing and multiple sidebars. In theory, this is possible with UMW Blogs using Userthemes, but it requires someone to create, at the very least, the blank templates on the server and upload them. It’s not easy to do this with our current UMW Blogs workflow, so I opted for the Bluehost route.
  • Each course topic has a page on the blog that includes the following:
    • Resources (added by Steve)
    • Aggregation of feeds from each student’s blog. The students are using a common category for each topic, and the site uses BDP RSS to grab the category feed and create views of each set of topical feeds. Big kudos go out to DTLT aide, Shannon, for major BDP RSS wrangling on the site. This approach results in about 90 separate category feeds, organized into 9 different views. Like I said, not really a sustainable approach. . .
    • A link to a page in the course wiki about the topic. There’s not much going on here yet, but I’m hoping it will become a space for the students to work through their final projects.
    • A link to a collaborative Google Doc (made public) that two students are writing in each week during class to record notes. I haven’t seen many of these yet, but I think the approach is going well. For this kind of note taking, Google Docs is much better than Mediawiki since it allows for simultaneous editing. The problem is figuring out where to send invites (as some students have Google accounts that they prefer to use).
    • An RSS feed of delicous bookmarks for the topic. Steve is asking students to bookmark resources for topics by combining a course tag (e488) with a topic tag. That allows us to have a “mother” delicious feed (using just e488) that we display on the course home page.
    • Both the link to the wiki and the link to the Google Doc are just text widgets that get manually created/edited. I quickly ran out of enough of them (the max number you can get in a default WP install is 9), so I had to hack the functions.php file to increase the number I could create. I had to do the same with RSS widgets for the delicious feeds.

Overall, I see the course site as serving two main purposes. As the students are working through a topic, it becomes a single-source for reading and reviewing all the relevant resources. Later, as they are working on their final projects, it becomes a single-source for each author to work from — sort of a virtual research center, collaboratively written by the entire class.

The hardest part of all of this has been getting all of the templates and sidebars worked out so that the topic aggregation is working properly. At some point, I’ll try to document the steps since I had a hard time finding one place that outlined all of the customization I did.
In the meantime, over in UMW Blogs, we’ve got tagging enabled, and I hear that may change everything when it comes to flexible aggregation. If it works the way tag feeds at WordPress.com do, we may not need BDP RSS anymore. . .