Archiving ds106 docs

Part of moving ds106 to a new server is making sure you don’t leave a trail of dead links in your wake. With great classes come great responsibility 🙂 I think I have the caching issues and some of the kinks worked out after the move, but one think I did want to make sure wasn’t lost in the move was the ds106 wiki, also known as ds106 docs. It was used through 2014, and while it wasn’t a huge part of the class design, for quite a while we used it to for  tech tutorials, syllabi, and other assorted resources. For example, I forgot about the detailed tutorial I created for an animated series of Dead Zone trading cards:

Or the equally detailed Creating Animated GIFs with MPEG Streamclip and GIMP tutorial.

I understand these resources are not all that useful anymore, but the internet preservationist in me wants them to live on. There are other resources such as various syllabi for classes over the years, such for Alan Levine‘s and Martha Burtis‘s Camp Magic MacGuffin syllabus from Summer 2012, or the syllabus for the ds106 Zone in the Summer of 2013. What I noticed going through my early syllabi for ds106 is they were all the same, they just started riffing on a different theme as the years went by, but the core remained. And while that seems logical, I really didn’t remember simply copying and pasting the basics and then building the theme and the prompts of the class on the blog and through the assignments. So, all this to say keeping the wiki was part of the deal of moving the site off shared hosting.

One thing you realize when moving sites is the value of using subdomains versus subdirectories, let me explain. The MediaWiki instance was installed at ds106.us/wiki rather than wiki.ds106.us. That might have had more to do with the WordPress Multisite being subdomains and my not knowing how to resolve redirects, but if the wiki was installed in a subdomain it would still be live right now (which is probably a bad idea regardless). But given I moved everything in ds106.us and the wildcard subdomains to the Reclaim Cloud, I would not be able to run MediaWiki within a subdirectory of ds106. Whereas subdomain can always be pointed elsewhere, subdirectories lock you into the server you are pointing the root domain to.

So, realizing this I need to a) get the wiki up and running temporarily so that I could then use Site Sucker to get a full HTML-based file backup of the site. This is great for archiving and also ensures that the wiki will not go down as application versions change, modules break, or spammers find a way in.* As you can se from the Site Sucker screenshot above, there are files both in ds106.us/docs and ds106.us/wiki because we used the article path function in MediaWiki to have all articles resolves as ds106.us/docs as opposed to ds106.us/wiki, which explains why the root ds106.us folder has both /docs and /wiki and both have part of the HTML archived files.

Another thing I did before archiving the MediaWiki instance (which I also have a full backup of) was update it from 1.19.xx to 1.33.xx. I had to replace the MonoBook theme, turn off the locked-out module, and adjust some other errors as a result of the update, but I was happy and relieved that it worked after a couple of hours and MediaWiki was now running a supported version on PHP 7.3 no less. Part of me still loves the promise and possibility of MediaWiki, but after wrangling with the documentation and the code it was a good reminder why it was never sustainable-the interface and editing was never made any easier and versioning issues made long-term maintenance onerous.

And with that, I think the future-proofing of the ds106 infrastructure and trying to ensure there remains some link integrity is in pretty good shape. I’ll do another pass this weekend, and then terminate the shared hosting instance, and commit to the cloud!

________________________________________________

*While I was at it I took a flat-file back-up of all of ds106.us and got a database and file dump (as well as a full cPanel backup file) that currently live in DropBox. So, this is a note-to-self that I do have a full snapshot of the site from June 2020 when I go searching for it in the future.

Building with Howard: Creating an Open Source Learning Environment Pt 3

This is part 3 of a series Howard Rheingold and I have been working on to demonstrate out the open how to create a learning environment using open source tools like WordPress, MediaWiki, and more. go here for all the videos so far. The idea behind this series is to get faculty and students interested in how they might fashion their own learning environments in a web hosting environment using their own domains. The first fifteen minutes of this video focuses on Howard’s approach to assessment in his Social Media Issues course, which will be experimenting with contract grading. From there we explored a few things in regards to the open source framework we are building.

  • Finding and installing WordPress themes
  • Integrating signins between WordPress and MediaWiki
  • Just how clunky MediaWiki still is after all these years
  • Customizing menus in WordPress
  • Uploading header images and changing the background color in WordPress Themes

The point about how clunky MediaWiki remaisn was the source of a broader mini-rant about how long we have been using these tools, but how difficult some absic things remains. Integrating signups between MediaWiki and WordPress is still a major pain in the ass six years on—the WPAUTH extension for MediaWiki that I’ve been using since 2007 remains the gold standard. Also, to change the logo in my MediaWiki install I need to FTP in and change code in localsettings.php file—WTF?!

I truly would like to see a robust platform like MediaWiki become a lot more ubiquitous in the teaching and learning space, but an application that makes simple administrative necessities that difficult will not be an options for your average user. Also, why haven’t we made some of this stuff easier? And this goes for syndication as well. My thoery is because we’ve wasted too much time chasing the next platform that will sovle our problems and finally truly disrupt education—in other words,  most technologists are fools and zombies.

Building with Howard: Creating an Open Source Learning Environment Pt 2

This is part two of a series Howard Rheingold and I are working on wherein we’re openly building the framework for his Social Media Issues course using a variety of open source tools, plugins, themes, extensions, etc. This is really a blast for me because I haven’t gotten into the nitty gritty of a one-off open source learning environment like this since 2007 or 2008 (although ds106 was exactly this in 2011, but I gotta a lot of help). I’m really loving the work with Howard to build out his course site, and once again explore for myself what’s possible with tools like WordPress and MediaWiki. In fact, the whole idea around ds106, Domain of One’s Own, Reclaim Hosting, etc., is that you dig into stuff like this and have a community of support to help you. A huge reason why folks wouldn’t even consider this option is that it’s way too onerous to do alone, but we may just solve that by working on this stuff as a community. Open and distributed edtech—you have a problem, we can help you fix it! We’re DEDtech! Anyway, that’s the dream.

As for this episode, Howard and I spent some time in the beginning on the WHYs. Why have your students blog openly? Why have them take control of their digital domain? Why build these aggregated spaces? What has been the biggest treat about pairing up with Howard is that he makes me explain some of the assumptions I’ve been carrying around for years. I’ve been pushing syndication of student blogs into course hubs at UMW for six or seven years now. We’ve been using the FeedWordPress plugin for five or six of them. This stuff is like water to us, and while others might be waking up to it recently—it’s been part of our edtech DNA at UMW for a while. So having Howard have me try and actually explain why a faculty member might want to do this is awesome. What’s more, as we go through these sessions it’s a real conversation between two people who are negotiating what the course framework might look like. The coolest part is we’re sharing it in hopes that others get some ideas, frame their own questions, and potentially work through a similar model. I feel like I am doing the best kind of instructional technology again: exploratory, customized frameworks that scale to the size of a single professor—a hub that reflects the personality of a course, but refuses to subsume the students within it. This is the kind of instructional technology that truly rocks—LMSs still suck!

After the WHYs, we covered a few customizations to his WordPress hub such as adding a widget for the Twitter conversation around his #comm182 course hashtag. Thanks to Tim Owens, I recommended the native widget from Twitter that actually works well. Just go to Your Twitter settings–>widgets and you have all sorts of options.

Twitter Widget

After that we discussed how to create custom menus in WordPress to organize pages on the course hub. What’s more, the links option in custom menus is a very useful feature that I think a ton of faculty will find appealing for loosely integrating a range of external sites into one central hub. We flirted with the idea of themes, but we’ll be spending more time in the next episode—which is Tuesday, August 20th btw—talking about the myriad possibilities in that department. About half way through we installed a MediaWiki and went over the affordances of that technology. I particularly liked our discussion about wikis because we actually went back-and-forth about what he may or may not need. I don’t recommend MediaWiki lightly because it can be a real pain in the ass, at the same time it is powerful and every time I set one up for a class I see the immense possibilities all over again. That said, when I soon realize I have to edit a localsettings.php file to get a attractive icon for branding a new wiki some of that luster is lost. Truly a love hate relationship.

I’ve demonstrated some basic editing for MediaWiki that we have document for the course here, and I am working on a broader HowTo wiki page for this class that I’m expecting other folks who want to do a course like this might use, copy, or customize for their own course. I’ll be talking about integrating WordPress and MediaWiki more tightly in the next episode, as well as the possibilities with plugins like Wiki Embed—which I think is awesome. I also found this cool MediaWiki extension I hadn’t seen before that enables seamless Poem formatting, which is a complete nightmare in WordPress. Who knew? I’ll highlight all these MediaWiki extensions, integration, and WordPress themes and more in the next episode. Until then, stay syndicated baby!