If you’ve been paying attention to my work for any period of time you’ll be aware that me working on student-generated/collaborative content in WordPress is nothing new. But when I started doing this years back, I was using a centrally-administered WP install over which I had no admin rights and no ability to customise. Which meant creating student accounts, teaching them how to use the back end of WP to post content, and a whole bunch of compromises. Ultimately it worked and many good things happened but it was a PITA and huge time sink and ultimately not particularly sustainable or scalable.
Fast forward several years after I’d gone more cowboy and learned how to be my own sysadmin, I can run pretty much whatever I need to now off my own rogue hosting. I once again was approached about making some kind of *thing* where students generate all the content. In this case, a collaborative database for maritime archaeology fieldwork. Moodle database tool was immediately voted off the island for being boring, inflexible and both temporally and physically locked. Plus it just looks a bit crap. Sorry Moodle. I naturally then turned to WP, but recalling the pain of managing student logins and training last time, and the knowledge this time that when you go cowboy, you’re the only support you’ve got, getting students to use WP in the standard way didn’t really seem viable.
Enter WP User Frontend Pro (standard version is free if you don’t need the extra features, I needed gmaps and pagination and things so actually spent some money for once). Not the only plugin around that allows people to post content from the front end of course, but this one works well and served my particular needs. This allows students to create posts via a standard (well, conceptually standard, fields are custom) web form served on the front end, no need to log in or learn the WP admin interface. Now admittedly I’m working behind password protection atm so I’m not sure how hard this gets hit by spambots in practice, but that’s a bridge crossed easily enough later. Ultimately I’d rather have to slay some bots than provide bespoke tech support to a whole cohort. At any rate the form works nicely and the pro version allows you to get quite complex in the number and type of fields you use.
Now that the ability for students to post from the front end with no special knowledge or logins is go, the further question is – how much control do we want to give students over metadata and taxonomies, given it’s supposed to be kind of proper database-y and will have potentially 300 entries? Folksonomies giveth, and yet folksonomies with 300 misspelled and typoed tags that are conceptual duplicates taketh away. Asking students to enter post tags manually seemed like a slightly bad idea. Enter custom taxonomies. Again, a number of plugins exist that can do this job, I’m using Custom Post Type UI. A couple of hours* with a cup of coffee and some data entry later, you can have a whole host of custom taxonomies to play with. And both plugins play very nicely together so you can then ask students to categorise their posts in multiple and flexible ways using finite dropdowns or checkboxes instead of free text input. The end result of which is a really robust structure that allows eventual public visitors to explore and filter the content in multiple ways, and also makes export of content to other systems (if necessary) more effective.
This particular project is still only at proof of concept stage and won’t run with actual students for another month or so, but I’m hoping this setup will really streamline the experience of student-generated bodies of work, not only in terms of student UX but my own workload and sustainability and scalability.
*Probably won’t take you that long if you don’t have 200 different kinds of boats to enter.