Fortunately, you can override this behavior by adding a hidden input field to the form to disable this filtering:

• <input type=”hidden” name=”filter” value=”0″>

http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html

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.

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).

To that end, the college’s Linux admin found this cool article which includes a short perl script to accomplish exactly that.

• Monitor number of active connections to MySQL using Nagios

There’s a report on this bug in Bugzilla; please vote for it. 

• Clipboard and drag-and-drop don’t interoperate with formatted text (e.g. HTML) on OS X

There’s also a good conversation about the issue, including possible workarounds, at MacRumors.com:

• Copy and Paste removes formatting – why?

Note that Safari on the Mac does not have this problem, but I’ve found Safari support in TinyMCE and CKEditor flaky at best (e.g. when cutting and pasting from Word into Safari using TinyMCE 2.x in Drupal, the resulting text will have random spaces removed from between words).

Update 11/7/2008

The patch that fixes this problem has been committed, so hopefully we’ll see this in production soon!

It comes with an audio player (I haven’t mucked about with the video options yet) that allows audio to be played on the page.  It supports built-in previews showing you how the podcast’s entry will look in the most popular podcasting directories (including iTunes and Yahoo).

The good news is that it appears to work out of the box with WordPress Mu, which is fantastic. One of our major goals for the WordPress pilot is to be able to support podcasting, and I think this would be a great tool for doing it. It also helps that almost every podcaster I know who uses WordPress also uses podPress … and I know a lot of podcasters.

The only downside to the app that I can see is that you can’t upload files as part of it; you need to upload the file using the “add media” buttons in WordPress, copy the path to said file, and then paste that path into the podPress portion of the page.

It’s clunkier than I expected; if nothing else I’d like for it to be able to browse the user’s media directory. I can see this cutting and pasting of urls being a little clunky for new users, but given the rest of podPress’s feature set, I think we can live with it.

In doing my research, I found a few WYSIWYG editor comparisons:

• IQ Content: WYSIWYG Text Editors Reviewed
• Drupal.org: Comparision of Drupal 5 WYSIWYG Editors
• WebTecker: FCKEditor vs. TinyMCE

I polled Twitter as well, and got four responses in favor of using CKEditor over TinyMCE, mostly because of ease of use.

Unfortunately, my comparisons didn’t yield any easy answers. WordPress defaults to TinyMCE, and if we go with WordPress Mu on campus, that could end up being our single biggest use of a WYSIWYG editor. Moodle is currently using HTMLArea, which is no longer in development. They’re replacing it with a modular system in Moodle 2 that lets you choose between whatever editor you want (including TinyMCE and CKEditor) so I’m not too concerned about that. The lack of support for TinyMCE in Mediawiki is troublesome; there is an extension for it, but it’s been abandoned by the developer. CKEditor support is much better.

We don’t need to rush into a decision here, so I think my next step will be to setup TinyMCE and CKEditor on test instances of Drupal and see how well they work and play with the CSS, how well their code validates, and how they deal with cutting and pasting text from various word processors.

If anyone has any suggestions regarding these editors, I’d love to hear them.

In the meantime though, I find myself having to work through questions I don’t really know the answers to. Specifically:

1. Preferred Grid Location: I know we want our island to be on the public grid, but where on the public grid? Is it better to be off by yourself? Should you be next to another college? Or the New Media Consortium? Or does it not really matter, because people will be ‘porting in, not wandering the wilds of SL looking for college islands to explore?
2. What island shape do we want? Is one type of island better to build on than another? For example, we’re thinking of either the “donut” shape, which is an oval island with a lake in the middle, or a mountainous shape, which sticks an mountain on one side of the island. Which is easier to build on?

I’m sure there are other questions, but these were the ones that leapt out at us when looking over the “so you decided to buy an island…” form on the SL web site.