It’s been over a year since I wrote in this space. There are lots of reasons for that. Most significantly, the last 12 months have seen enormous change in the division that I’ve worked in here at UMW, Teaching and Learning Technologies. If you follow me on social media, you know all about the changes. Suffice it to say, I spent the first part of this period of change largely grieving the departure of many people who I consider friends in addition to treasured colleagues. Luckily, I’ve spent the second half of this transition welcoming a new group of wonderful people to the University. Change is hard and sucks; change is good and valuable.

Also luckily, there have been a few people who haven’t left; I’m so grateful for their support and friendship over the last year or so.

In addition to all the upheaval in DTLT, I actually don’t work in DTLT anymore. No, I didn’t leave; we just made some changes in the organization of our unit and I report directly to the Special Assistant to the Provost for Teaching, Technology, and Innovation (aka Jeff McClurken). This allows me to work more closely in parallel with DTLT, and it allows me to explore the Digital Knowledge Center’s mission of supporting student engagement with innovative technologies alongside DTLT’s mission to support faculty.

You could say that my entire year has been a year of refactoring.

But I’ve also been working on another kind of refactoring project, namely to take the code that Tim Owens and I wrote mostly back in spring of 2014 to manage the UMW Domain of One’s Own Web site. At the time, we were working fast and furiously to build out as many features as we could imagine for that site. We wanted to push ourselves and, in doing so, to push our colleagues’ imaginations as they thought about how the project could be managed, presented, and interpreted.

In order to work as quickly as possible (we seriously wrote most of the code in a few days), we built all of our custom functionality in a WordPress child theme.

But before I go any further, let me back up and explain a bit how the structure of UMW Domain of One’s Own site actually works.

When you visit http://umwdomains.com you are viewing a WordPress site. If you’re a UMW community member, you can sign-in to that site to first set up your domain and hosting and then manage the created account.

WordPress, however, acts mostly as a front-end for all of the other various integrations that we need to make happen. In brief:

1. Through the use of a WordPress plugin, we’re able to integrate this site with our University’s Central Authentication System (CAS), allowing for single-sign on into Domain of One’s Own.
2. Through API calls to our client management system (WHMCS) we are able to redirect new users after they login to a checkout system for choosing and registering their domain as well as setting up their Web hosting.
3. Through API calls to our hosting server’s software (WHM/cPanel) we are able to redirect returning users to the cPanel interface. With the integration of Installatron (a script installer and utility for open-source applications) users can then be “passed-through” to the admin interface for various applications they install (without having to authenticate beyond CAS).We are also able to build a migration tool that allows users to easily request an EPP code and backup when it’s time for them to leave Domain of One’s Own (generally within six months of graduating).
4. Through API calls to our domain registrar (Enom) we are able to  check the domain verification status of a user’s domain and prompt them to verify if they haven’t already done so.
5. Through custom code that we’ve written for Installatron, we can capture information about every installation that is completed on Domain of One’s Own and store that in a custom content type in WordPress, allowing us to build a directory of installed sites across the DoOO ecosystem that are “linked” to the user who created them.
6. Through the WordPress plugin, FeedWordPress, we’re also able to capture syndication information about any installed applications that are RSS-enabled and we can begin to syndicate new content onto the main DoOO site, thereby creating an archive and central hub of user-created content.
7. Through other WP plugins we can build on top of all the information about users, sites, and posts that we are capturing, allowing us to potentially build rich interfaces for discovering the work of our Domain of One’s Own users.

But all of that is really nothing new. The code to make all of that happen was more or less completed by summer of 2014. In the ensuing years, however, we’ve had to neglect some of that code. With people leaving and my being pulled in different directions, keeping that code up-to-date has been difficult. All of our core functionality continues to work, but some of the bells and whistles have had to get turned off, particularly in the last 9-12 months.

This summer, however, signifies DTLT becoming fully staffed again, with new people who are eager to dive into the project and to think about what the next version of the DoOO site might look like — and how it could function.

To that end, I’ve spent the better part of the last 2 weeks refactoring code, specifically taking what had been a lot of custom functionality in a child theme and turning it all into a DoOO plugin. The child theme approach allowed us to work quickly back in 2014, but it wasn’t really sustainable. We were essentially locked into the parent theme we’d chosen, and it turned out that parent theme wasn’t the easiest to customize.

Refactoring the code into a plugin has focussed on a few primary goals:

1. Creating Shortcodes: What had been a whole series of custom theme templates had to get turned into a library of shortcodes that can be dropped into pages as needed. My goal (before I leave for a month at the end of this week!) is to be able to turn the plugin and the shortcode library over to my colleagues in DTLT so that they can begin to work on building out a new DoOO site in a theme of their choosing.
2. Commenting & Documenting: When Tim and I wrote the original code back in 2014 we were working so quickly that we spent almost no time diligently commenting our code. As a result, I’ve had to spent quite a bit of time unraveling some PHP spaghetti. As I go, I’ve been trying to be much more mindful of documenting the code for future developers.
3. Generalizing what I can: We had lots of stuff hard-coded into our templates and functions file that I’ve pulled out into a config file, allowing us to more easily change these variables when it comes time to move off or our development server and into production. (In the back of my mind I’ve also been wondering if this plugin project needs to be turned into a repository where it’s possible for a group of DoOO adopters to collaborate on building a fully generalized plugin for creating DoOO project sites. )

There are some things I’m not going to get to. My WP plugin architecture is, frankly, pitiful. I’m not doing anything fancy to the structure of the code and files. And don’t even talk to be about object-oriented plugin development. It isn’t happening this go round. I’m just trying to make sure that the functions are grouped conceptually and can be easily worked with. There are likely to be a few features I won’t get to this summer, too, but hopefully we can pick those off over the course of the fall semester.

I may write one more post where I outline the various shortcodes that I’ve developed. It would serve as a useful document, I think, for my colleagues, and it might be interesting for developers at other schools who are undertaking Domain of One’s Own projects. In the meantime, it’s been pretty great to spend a few weeks with my head deep under the code hood of DoOO. My current job (which I still love) doesn’t afford me this opportunities as much, and this work reminds me of another aspect of what I love about developing environments for teaching and learning in an open source world.

Image Credit: refactoring by Daniel on Flickr (CC By 2.0)