Learning the World

“You are in a maze of tiny, twisty passages, all a like”.

That line shows up in Zork and its variants when you get lost in a labyrinth, and it’s how I feel right now trying to puzzle through the best way (or hell, ANY way of securing WordPress Mu in directory mode).

What I’m trying to do is this:

• I want to enable secure logins and admin pages (so that these pages are protected via SSL and have https addresses).

I’ve got a WordPress Mu install setup in directory mode, e.g.:

• The main blog is at wordpress.foo.edu.
• The daughter blogs will appear in subdirectory format, e.g. wordpress.foo.edu/bar

In normal WordPress, this goal can be accomplished by setting two constants in the config file:

• define('FORCE_SSL_LOGIN', true);

• define('FORCE_SSL_ADMIN', true);

Another option is to make use of the Admin-SSL plugin:

• Admin-SSL: http://www.kerrins.co.uk/blog/admin-ssl/

With WordPress Mu, it seems things are a bit trickier. Ok, a lot trickier.

Both methods will protect the main blog at wordpress.foo.edu, I get nothing but 404s when I try and access any of the daughter blog admin pages at wordpress.foo.edu/bar/wp-admin. Traffic is successfully redirected to https, but the server simply spits out a 404 page, saying there’s nothing there to load.

This is the same thing that happens when you, ahem, forget to include the htaccess file with the various mod_rewrite commands that allow for clean urls in WordPress, so my assumption was I’d just need some more mod_rewrite magic to get WordPress to properly serve these pages.

This led me on a mad chase to try and figure out the best way to do that. Instructions in the following post seem like they should work:

• SSL/LDAP/password security questions

And yet not. More 404s. More headaches. It could just be that I’ve been working on this too long, and need to let it simmer overnight. It seems to me that there must be a way to use mod_rewrite to force Wordpress Mu to resolve these https addressses the same as it does http, but I’m just not seeing it.

My guess is that this all would work just fine using the subdomain method, but we really want to use the directory one.

So yes. There’s a maze. With tiny twisty passages. And they are all alike. Time to hit the reset button, and tackle it with new eyes tomorrow. In the mean time, if anyone has any bright ideas, please let me know.

Update: 2/2/2009

You knew it was going to be something small and obscure right? And you new it was going to be something that prevent the .htaccess file from firing, right?

When last I wrote on Friday, sub-blogs failed to load whenever you tried to access an https-enabled page. I couldn’t help having this gut feeling that my issue had NOTHING to do with .htaccess/mod_rewrite and everything to do with a server configuration issue.

On Sunday, I did some experiments, and I discovered that when I tried to load an SSL-enabled daughter blog, the htaccess file was never even executed.  I tested this by purposefully breaking the htaccess file so it would cause a server error; when I loaded https://wordpress.foo.edu”, I got a “page not found” not a “you idiot, you broke the server” error.

So I switched gears and started looking at issues with httpd.conf and ssl.conf. That’s when I came across the very nifty “Installing WordPress Mu” ebook [pdf], where I saw this bit of advice: 

Permalinks do not work or Can’t find subblogs in subfolder install
If everything looks like it installed okay, but when you start clicking on links and you get 404’s or server errors, you need to do a little Apache configuration. Even if you have mod_rewrite enabled, and the htaccess file is there, on some setups the web account is set to not let these settings through. You’ll need to go to terminal mode and edit the httpd.conf file. See back on page 5, and while you’re in there, look for the directive of your virtual host, find this line “AllowOverride None” and change it to “AllowOverride FileInfo Options”. With no quotes.

Sounds familiar … doesn’t it?

So I look at the wordpress entry in httpd.conf and see that yeah, AllowOverride is configured as “AllowOverride FileInfo Option”. But ssl.conf? THAT was set to “AllowOverride None” As a result, WordPress MU worked just fine on regular pages, but failed on secure ones.

Changing ssl.conf so that AllowOverride was set to “AllowOverride FileInfo Options” fixed the problem. Apache, htaccess and Wordpress are on speaking terms again, login/admin traffic is automagically routed to https, and the freaking page LOADS.

[sigh]. It’s only obvious in hindsight.

After talking with a faculty member and brainstorming how classes might use WordPress MU, one of the must-have tools we’ve decided we need is an author list. While we anticipate that we’ll have a number of one-person blogs if/when WordPress Mu is in production, there will also be goodly amount of multi-author blogs for classes, student organizations, etc.

We identified two needs:

• Hyperlink an author’s name to a page with all of their posts on the site.
• Include a widget listing all of the authors (with links to their individual posts)

After doing some research this morning, I’ve come up with a few solutions.

1. Linking to author names & listing authors through WP functions: The “Author Templates” page of the WordPress Codex lists a number of useful functions that can be used as part of the Loop to link to individual author pages as well as displaying post counts and author lists. 
   • The specific function is “the_author_posts_link()”, and it inserts the author’s name with a hyperlink to his/her “author” page, which lists everything they’ve written.
   • You can also use “wp_list_authors()” to list all the authors associated with the blog.
   • These options require you to modify the theme’s template file(s). 
2. Listing Authors with the Authors Widget: “Authors Widget” allows you to add a sidebar widget that lists all of the authors associated with the blog with links to their individual author pages (there’s also an optional link for their RSS feeds).

One of the big concerns I have going into this spring’s Wordpress Mu pilot is data portability. If we decide not to go ahead with Wordpress, what will happen to the piloter’s blogs? That led me to experiment with WordPress’ import/export options. I knew that you could pull in data from a variety of sources (RSS, Blogger, other Wordpress installs) but I wasn’t sure how well it would deal with exporting.

Last week I decided to put that option to the test, dumping this “Learning the World” blog as a WordPress XML archive and then importing it into a WordPress Mu test install. It came over perfectly, with only two possible hiccups: matching user accounts (e.g. author accounts, commenter accounts, etc.) and files.

With accounts, WordPress wants to map existing accounts in the archive to accounts on the new blog; if you don’t have matching accounts on the new blog, you’re going to either need to map them to one of the accounts you do have, or you are going to have to stop the import, create the necessary accounts, and then do the import.

With files, WordPress gives you the option to suck down files from the original blog, but only as part of the import process. It doesn’t include that data in its initial export, which means if your original blog goes away (and takes the files with it) then you are out of luck. I’d love to see an inclusive export option that grabs everything. 

That said, the export does work pretty well as is; it was fantastic to see Learning the World instantly resurrected in a new install (Cylons anyone?), and it bodes well for moving the trial-run blogs into production at the end of the pilot.

By default, WordPress Mu wants to serve sites in one of two ways: using a “folder” methodology (e.g. wordpress.foo.edu/[site name]) or subdomains (e.g.  [site name].blogs.foo.edu). The problem is that out of the box, the subdomain approach wants you to rely on wildcard DNS entries to send traffic to WordPress.

This works fine if you’re serving up something like blogs.foo.edu, in which you expect each blog to be part of a larger subdomain, but it’s problematic when you want to serve sites one step up the food chain (e.g. [site name].foo.edu). (if for no other reason than all the extra MySQL work that gets created as WordPress tries to resolve traffic to non-existent subdomains).

Ideally, I want an admin blog account installed at something like wordpress.foo.edu, but then subdomains for every thing else.

Out of the box, WordPress doesn’t want to work like this (since it wants all of its subdomains to appear off of wordpress.foo.edu, rather than foo.edu). Fortunately, you can tweak the Mu database to get around the limitation.

1. Install WordPress Mu with subdomain support to wordpress.foo.edu
2. Configure the admin blog.
3. In MySQL, change the “wp_site” table, changing the route domain (in the “domain” column” to “foo.edu” from “wordpress.foo.edu”
4. Create a C name in DNS for the subdomain you want to serve (e.g. bar. foo.edu) that points to wordpress.foo.edu)

We’re gearing up for a WordPress Mu pilot at the college, and I’m feverishly researching plugins to use with it. Here are the big three I found:

• PodPress: The godfather of podcast plugins. It hasn’t been updated in a while, and there have been mixed reports about how well version 8.8 works with WordPress 2.7. A new version 9 is apparently in the works, but no one knows if/when it will appear. The file upload interface is a bit clunky, but there are a huge number of backend-options, plus stat tracking.
• Podcasting: A simple plugin that requires you know the URL of the file you want to podcast. That’s fine for tech-savvy people, but I think it’s going to fail the “quick and easy” test for everyone else.
• Blubrry: The lead contender. It works with the regular file upload interface for WordPress; if you insert a file into a post using the regular interface, it adds an MP3 player to the post. It also has a nice selection of backend feed options.

I still need to experiment with how these different plugins handle video files (so far, Blubrry worked like a charm), and I’m continuing to look at other options. I’d love to get some feedback on how well these different plugins work, as well as recommends for plugins not on the list

If you unzip a folder containing files with special characters, those files become uneditable and unmoveable via the web browser; the only way to get rid of them is through the command line. This is because Moodle is not escaping the file names when they are created (as it does with single file uploads); instead of replacing the special characters with placeholders, the files get created with the bad characters.

A full rundown and a patch is available in Google tracker; hat tip to Charles Fulton for taking the time to debug this.

http://tracker.moodle.org/browse/MDL-2307

The LSU variant gradebook introduces a bunch of usability improvements that greatly enhance gradebook. Enhancements include 1) a fixed student name column 2) better extra credit 3) highlighting rows/columns 4) the ability to edit all of an assignment’s student grades in one go.

Complete details here: http://docs.moodle.org/en/grade/report/simple_grader/index

Moodle core is currently looking at integrating this gradebook into core, which is very cool. Vote for it in tracker to stay current with the project and offer comments on what you think:

http://tracker.moodle.org/browse/MDL-1780