Domain of One’s Own and WordPress Networks

I’ve had a pretty jam-packed semester, and now that it’s almost over I feel the need to capture at least some of it. We ran our third Domain of One’s Own Faculty Initiative with 23 participants across at least ten disciplines and two colleges. This brings the total number of faculty who’ve gone through this program at right about 80. That’s a third of our faculty. The intentional and consistent development of faculty, and by extension students, over time is the approach that makes this initiative more than just a numbers game to tout we have “full saturation.” We’re committed to scaling intelligently, while rolling out and developing a community around the immediate possibilities web hosting and a personal domain offer—and that gets more compelling every year.

Case in point, this year my cohort, made up of seven of UMW’s finest faculty (there were 3 other cohorts with 16 more faculty), got interested in setting up WordPress multisite installs so they could create a network of sites for their personal portfolios, course spaces, research sites, etc. The idea makes a lot of sense, but when we started this a few years ago I steered away from this option because getting your own domain and web hosting seemed enough overhead. This year that all changed.  Everyone in the cohort was comfortable with WordPress (a remarkable fact in and of itself), so we could take the time to explore the abstraction of what a managing a Network of WordPress sites entails. Dealing with questions like: How do you manage themes and plugins differently? What are subdomains versus subdirectories? How can you syndicate between sites? etc.

The process reinforces the longitudinal impact of so much of the work DTLT has done over the last decade from the Bluehost experiment to UMW Blogs to UMW Domains. It also points to a progression in what’s possible thanks to how much we have invested as a community and how much easier things have gotten since 2005. With the application installer Installatron we can have folks do a one-click install of multisite. After just minutes they can be up and running with dynamic, wildcard subdomains. That struck me hard yesterday while I was taking a faculty member through the process. I spent a couple of years of my life on this very blog struggling through that very thing back n 2006 and 2007, now it’s a checkbox on an installation form.

Screen Shot 2015-04-22 at 1.21.05 AM

Easy doesn’t suck in this instance because we can spend our time examining what it means to manage a network of sites. For example, the benefits of various sites pulling from the same fleet of plugins and themes but only needing to run updates in one place. I felt like the discussions around the application(s) helped us work through managing online presence, creating an online scholarly identity, and taking a hands on approach to controlling, owning, and archiving the work they do online. I’ve been at it so long with WordPress that I sometimes forget how crazy the arch of faculty development at UMW has been. Just about any faculty member with 20 minutes to spare can create an infrastructure that defined my career path just 8 short years ago. Nutty.

Anyway, enough of that. Below is a quick rundown of how you can create wildcard subdomains within CPanel. Even that seems easier than it was back in the day of editing vhost files. I’m stealing the majority of this tutorial from Namecheap because they do a better job on it than I could. I just add my own 2 cents here and there, as usual.

This assumes you have already setup WordPress as multisite, as easy as the click of a button on UMW Domains and Reclaim Hosting.You will need to copy a line of code to your wp-config.php and then access Tools–>Setup Network to choose subdomains. After that, you’ll be given  code to copy into both the wp-config and .htaccess files. You can see a good tutorial on that process here. In order to create a wildcard subdomains in CPanel, you do the following:

1) Log into your cPanel

2) Navigate to the menu ‘Subdomains’ under ‘Domains’ section

wildcard_subdomain_1.jpg

3) Create a subdomain‘*’ pointing it to the necessary folder ( you will need to specify the path in the field ‘Document Root’ ).

wildcard_subdomain_2.jpg

4) Go to the menu ‘Advanced DNS Zone Editor’

wildcard_subdomain_3.jpg

5) Make sure that there is an A record for *.yourdomain.com created and pointed to the server IP address ( it could coincide with the IP address of your main domain or ftp.yourdomain.com is pointed to).

wildcard_subdomain_4.jpg

6) Now you will need to wait until the propagation is over ( it should take N seconds, where N – isTTL for this A record; you can edit it manually and reduce the number to speed up the process ) and then the wildcard subdomain will work correctly.

The final step I needed to do for the folks on UWM Domains at the server level in WHM is to reset the DNS Zone for the particular account that is installing a WordPress multisite with wildcard subdomains. This was the bit I got hung up on, but my server admin skills are getting better and better with every passing day. Soon I may even be competent.

Screen Shot 2015-04-21 at 10.56.07 PM

This entry was posted in Domain of One's Own, Faculty Initiative, WordPress, wpmu, wpmued and tagged , , , . Bookmark the permalink.

3 Responses to Domain of One’s Own and WordPress Networks

  1. 1/3 of faculty is an amazing success story done from the ground up.

    I’ve gotten to be a big fan of multisite more in the last year. Sharing of themes, plugins across sites comes in handy (although remembering to install at Network admin, and understanding what to network activate and what to do per site), but also of users becomes very useful. I have done some client work where I convert their old site to multisite, do a dev version on a subdomain, flip when go live, and retire the original site to archive.zzzzzz.zzz

    It can free faculty from trying to cram everything in one blog.

    It was also useful at TRU to develop wordpress based apps/tools on multisite http://splot.ca many of them could share the same parent theme, and move to a production multisite when ready. The beauty here is we could have many sites in the production, and making updates was simply updating one theme.

    There is the secret glitch of anyone not being a superadmin not able to use iframes or JS (learned the hard way on ds106), did find a plugin that allows use of iframes.

    I’ve never had to do that WHM trick, maybe its because I start from scratch (which involves manual edits of wp-config.php). Wonder what it would take for an installatron to do subdomain multisite installs from the get go??

    1/3 of faculty? Amazing, and then again, not surprising….

  2. Brian says:

    Remarkable that successive cohorts are becoming more ambitious… ie, wanting to manage networks rather than just sites. That’s a powerful statement right there.

  3. Chris Lott says:

    “It can free faculty from trying to cram everything in one blog.” Absolutely, with the caveat that there’s a whole world of intellectual-stential philosophy buried in the definition of “cramming.” The sweet-spot between being too little centralized and overly centralized can be elusive.

    That said, this is the kind of victimization-by-success I wish I had to deal with more often. Or at all.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.