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 offers— 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

Posted in , Domain of One's Own, Faculty Initiaitve, Faculty Initiative, uwmdomains, Wordpress, wpmu, wpmu development, wpmued | Leave a comment

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 offers— 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

Posted in , Domain of One's Own, Faculty Initiaitve, Faculty Initiative, uwmdomains, Wordpress, wpmu, wpmu development, wpmued | Leave a comment

Testing Invention

This is just a test.

Posted in Uncategorized | Tagged | Leave a comment

flblogging

Blogging is better than flogging-

Posted in Uncategorized | Tagged , | 1 Comment

Go to UMW Blogs

Posted in Uncategorized | Leave a comment

This is a test to Jim’s Site

Did it work?

Posted in Uncategorized | Leave a comment

PostSecret in Chicago

I had this postsecret….

YouTube Preview Image
Posted in Uncategorized | Tagged , | Leave a comment

Cthulu

This is HP Lovecraft….

YouTube Preview Image

Posted in Journal 1 | Tagged , | Leave a comment

A Few Notes on Updating UMW Blogs to WordPress 3.5

eniac4

The upgrade process for WordPress has been so seamless the last three or four versions that I didn’t realize how spoiled I’ve been until I finally had an issue (and even that was quite simple to resolve).  Between automatic updates for plugins, themes, and core files, WordPress has nailed the convenience end of upgrades, and that’s no small thing—just ask anyone who has to upgrade a Mediawiki install :)

UMW Blogs did have one hangup going from 3.4.2 to 3.5 with the SharDB plugin. It was throing the following error:

Warning: array_search() expects parameter 2 to be array, null given in /home/umwblogs/public_html/wp-content/db.php on line 250

Luke Waltzer had the same issue on Blogs@Baruch, so I knew I was in good company :) And, as is always the case, Ron Rennick (the original author of the plugin) was on it. (Ron and Andrea deserve every bit of kudos they get from the WordPress community and more.) He fixed the issue in the db.php file for the plugin and noted he would update the trunk at some point. But in the interim if you have an issue getting it to work leave a comment and I’ll post the code I’m using.

What’s nice about moving to 3.5 is that we can once again use dsader’s now out-of-print 3-in-1 widget to display recent posts on the front page of UMW Blogs, which is pulling off the http://tags.umwblogs.org blog. We’ve had performance issues with this one before, so we have to watch it pretty close for load spikes.

Another issue that was just brought to my attention is that WordPress 3.5 begins the phase out of the Links Manger. I hadn’t heard about this yet—I need to read up on new releases better :) —so I installed and network activated Andrew Nacin’s Links Manager plugin in the interim until I figure out how this might effect folks on UWM Blogs. To be clear, if you were using Links Manger before the upgrade that functionality is still intact from what I understand, it is all new blogs that are created won’t have it as a visible option.

Other that that, UMW Blogs is once again running on the latest and greatest for the new semester. If anyone else knows of any issues we should be aware of I’d love to hear em.

Posted in , dtlt, SharDB, umw, UMW Blogs, umwblogs, upgrade, Wordpress, wpmu, wpmu development | Leave a comment

Why We Need to Integrate UMW Blogs with Active Directory

For years now we’ve prided ourselves on keeping UMW Blogs outside of the single-sign-on environment using the rationale that it provides just one more layer of separation from the fears surrounding  privacy, FERPA, and security. Admittedly part of this stance was born out of the technical challenge of integration, an issue that since then has been figured out pretty effectively for a variety of authentication systems. And given UMW has had Active Directory for the past three years, we could (and most likely will) take Luke Waltzer’s brilliant lead and integrate our UMW Blogs instance seamlessly thanks to Boone Gorgesplugin (how much do you love CUNY?).

Integrating with the UMW’s Active Directory is something I’ve been thinking more about recently given it would make certain things a hell of a lot easier. What’s more, we’re already doing this on the umw.edu installation of WordPress, and that works quite well thanks to Curtiss Grymala. So we even have the in-house expertise now, I guess I’ve just  been stuck on the idea of creating a bit of a firewall between UMW Blogs and the other enterprise systems around campus, even though UMW Blogs has been an enterprise system for a couple of years now, whether or not I want to admit it. I probably would have dragged this out a bit longer, but a recent meeting I was in about the future of online learning at UMW has been helping to make the decision easy.

We have a new set of forms and policies regarding online classes that were inspired by our preparation for our current SACS review. More specifically, we have an “Online Course Authorization” form (doesn’t it sound so Brazil-like) that caught my attention because according to this form, in order for UMW to remain in “compliance with federal distance education regulations” you have to login through a centralized, campus-wide authentication system. Here is the exact verbiage from the form:

The default expectation is that online UMW courses will be offered through Canvas, the University’s enterprise learning management system. Because Canvas requires a secure UMW login and password authenticated against the University’s active directory, it fulfills the federal requirements for verification and privacy and does so at no additional costs to students.

If this course will be managed through Canvas, check this box, provide the two signatures (below), and submit the form to the Office of the Registrar. Ignore page two of this form.

IF THE INSTRUCTOR WISHES TO USE A SYSTEM OTHER THAN CANVAS FOR MANAGING THIS ONLINE COURSE, THE ALTERNATIVE APPROACH MUST BE APPROVED FIRST. Complete page two of this form, and secure all required signatures.

What else can I say? This pretty much says it all. As of right now UMW Blogs is not authenticating against our university’s active directory and hence cannot be considered one of the default spaces where online learning can happen at UMW without a litany of five or six signatures all the way up to the Chief Information Officer. I don’t know the specific federal regulations this form is referring to and I’ll have to do more research there (anyone know anything about this?), but at the same time I’m not necessarily doubting it. Given how meticulously we’ve been going about our SACS re-accreditation review I’m sure the regulations are quite plain. What gets me in all this is the idea that as a result of these regulations our LMS has become the default mechanism for designing an online course experience at UMW. This seems problematic to me given all the work we’ve done over the last seven years, and one of the reasons I am kicking myself a bit for dragging my feet on active directory authentication.

At the same time we’re lucky we don’t do too many online courses at UMW just yet, and those we are doing are being shaped and developed through a robust community of faculty in the Online Learning Initiative that are interrogating the ideas behind online learning for a liberal arts campus. Nonetheless, the idea that there is a form somewhere that says “the default expectation is that online UMW courses will be offered through Canvas” kills me. The impulse amongst universities to dictate the virtual environment in which online classes can happen will increasingly become a contested and murky reality—folks will “authenticate” through the LMS but that’s not where they’ll teach and learn.

This form is very much a hoop we are having faculty jump though as a way to square ourselves with the SACS review, which I understand but at the same time it does little or nothing to push the vision and possibilities of online learning forward institutionally. On the contrary,  it makes it much more difficult for a faculty member to choose an alternative framework, a fact that could be potentially devastating to the culture of innovation in this area cultivated at UMW up and until now. For that reason alone I think it is crucial that we start seriously considering getting UMW Blogs to authenticate against active directory so that it can be yet another default option for online learning that we can offer UMW faculty with little or no hassle.

 

Posted in , active directory, OLI, online learning, UMW Blogs, umwblogs, Wordpress, wpms, wpmu, wpmu development | 1 Comment

A few solutions to comcast sucking

This is a test of the solutions frame for this.

Posted in Uncategorized | Tagged , , | Leave a comment

A few reasons why Comcast sucks.

This is test post that should feed into David Wiley’s edstartup Brainstorm section of his site.

Posted in Uncategorized | Tagged , | 2 Comments