Spell check all text fields in Firefox

Firefox has a built-in spell checker, but by default it only works on text fields of more than one line. However, you can make it spellcheck all fields with the following steps:

  1. Start up Firefox.
  2. Type “about:config” into the address bar in Firefox and hit enter.
  3. Click “I’ll be careful, I promise!” (if the warning appears).
  4. Type “layout.spellcheckDefault” into the Filter field.
  5. Change the value for the layout.spellcheckDefault field to “2″ instead of “1″ (default).
  6. Restart Firefox and you should be set.

If you are new to about:config in Firefox, checkout MozillaZine’s intro.

WordPress network on Dreamhost

WordPress, as of version 3.0, allows you to set up more than one site within the same installation. Each site uses the same core software and users can use the same credentials in all the sites they have access to across the network. Essentially, it allows you to set up a mini WordPress.com. Since I have a growing number of WordPress sites hosted at Dreamhost, I decided to set up a network of my own to reduce time upgrading and maintaining them and to simplify user management.

Also, I needed to move to secure (SSL encrypted) logins and admin areas. This is relatively easy to setup on a site-by-site basis, however, that would have meant a dedicated IP and SSL certificate for each site. With a WordPress network and domain mapping I can host websites at their own domain, but use one-centralized WP install, set of usernames and only one dedicated IP address and SSL certificate, securing all of the sites at the cost of one. Win-Win right?

I was a little wary of running the gauntlet and getting it all set up. Don’t be. It’s very easy, really. And you’ve got lots to gain by doing it. Here’s my instructions for getting a WP network set up on Dreamhost. The instructions would probably work on any other shared hosting with a couple changes. Let’s begin!

Things you’ll need

  1. A static, dedicated IP Address. (March 2011, costs $43.17 / year)
    This is required so that the mapped domains can default to your primary domain if the domain is not recognized. As a freebie it allows you to do secure logins and administration (highly recommended).
  2. Optionally, a yearly certificate. (March 2011, costs $15 / year)
    If you want to do secure login and administration and people other than you are accessing the system, having a legit certificate means that they don’t have to accept an ‘insecure’ certificate. The certificate from Dreamhost is cheap ($15) and means less fuss when people are using the admin area.

Step 1. Install WordPress

I’m assuming you’re familiar installing WordPress. If not, you can download the latest version and read installation instructions at WordPress.org.

Step 2. Setup the network

Follow the instructions on how to Create a Network. If, like me, you do not have a Dreamhost PS (Private Server), be sure to choose sub-directory type of network. This means that your primary site will be at example.com and the next sites would be at example.com/site2, example.com/site3 and so on. Without a Dreamhost PS you won’t be able to set up the sub-domain type network since it requires that Dreamhost manually add a wildcard apache directive, which they’re not wont to do for anyone, especially those without a PS account. A sub-directory network will actually work fine, you’ll just want to be installing a new site as your primary site, not converting a site that’s been round for more than a month as there could be collisions with the permalinks (there is a note about the reason for this in the link above). Since we’re planning on doing domain mapping anyway, sub-domains are not really necessary.

Step 3. Install the Domain Mapping Plugin

Installing WordPress MU Domain Mapping is relatively straightforward and there are lots of details about A and CNAME records on their site. You can go either way with A or CNAME records. I’m using A name records to get the mapping setup.

Step 4. Add the Static IP and (optionally) SSL Certificate

You need a dedicated IP address in order to get the network set up correctly. Without it, you can’t be guaranteed that your IP won’t change and you would also have issues with other domains on the same shared IP. The general idea is that WordPress will return the appropriate site if it recognizes the incoming domain name, if it doesn’t recognize it, then WP returns your primary site.

To add the static IP, login to the Dreamhost panel and go to your list of domains and click “Add IP” underneath the domain name. They’ll ask for some information and ask you to agree to the yearly or monthly charge. By default you’ll get a self-signed certificate which will make your site secure, but visitors will get an alert saying that the site is not trusted. To get a signed SSL certificate, you can purchase one from wherever you want, or from Dreamhost. Dreamhost’s is pretty cheap and no work at all to set up. As of March 2011, the signed certificate costs $15 / year.

After setting up the IP, you’ll want to make sure your primary domain’s DNS A record points to this new IP address. If you have the DNS for your primary domain hosted at Dreamhost you don’t have to worry about that.

Step 5. Mapping domain names

After you created a new (non-primary) site in your network, you’ll want to map that domain to the new WordPress site. In each site’s admin area under Tools you’ll find an option called Domain Mapping. That’s where you can enter the domain name so that WordPress knows about it.

You also have to edit the DNS for domain that you want to map and add an A record that points to your new static IP. Once the DNS propagates, WordPress should start responding for your new domain.

Update Otto has a good walkthrough setting up the Domain Mapping Plugin.

Step 6. Secure Login and Aministration

There are instructions on WordPress.org for setting up Administration over SSL. The conclusion is that you need to add the following lines to your wp-config.php file. Note that if the DNS change on your primary domain from a shared IP to a static IP hasn’t propagated, then this will lock up the admin area, so proceed accordingly.

[code]
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);
[/code]

WP Plugin: Widget Context

Last night I ran across a WordPress plugin called Widget Context by Kaspars Dambis. The plugin gives you the ability to control on what context any widget will show up in, allowing you to narrow down widget content to certain types of posts / pages, to certain categories and URL’s. It’s really useful and allowed me to do some things within WordPress rather than making an ugly hack to a template — making things easier to maintain for non-developers in the future.

Currently, I’m using the plugin to show a custom menu on a certain set of sub-pages over on Mt Zion Church‘s website. Any WP developers out there, let me know if there’s a better way, but thanks Kaspars for the plugin — it’s certainly useful.

Single-sign-on with frames and javascript

Warning: this is about finding workable solutions and some of the methods are used because they are a solution not because they promote the cleanest HTML. You might run across <frame> in this article. Apologies to the HTML5 community.

Most web apps don’t give web developers many tools to integrate directly with their login system. So when it comes to creating single-sign-on scripts you’re often on your own for finding the credentials and back-engineering login systems. Often you have no direct access to the 3rd party system.

Imagine that you have access to the usernames and passwords programmatically. We then set about creating an intermediate page with a hidden form, which, when visited by the user, is populated with the correct credentials and submitted by Javascript. If everything goes to plan the user hardly notices the break in service as he is directed from (1) the single-sign-on hub to (2) the 3rd party service. (I will use these labels (1) and (2) from here on, so make sure they’re clear in your mind.)

We have a number of these type of redirects for single-sign-on at BSU and NTC. One problem that crops up is logging out of (2) doesn’t redirect the user to (1) and going back to (1) doesn’t necessarily log the user out of (2). Further, often the user may need to enter the stored password for (2) to confirm a choice but has forgotten it due to not using it to login anymore.

To solve this problem I created a frameset with two frames: the first being a bar along the top, the second being the main application window. In the top bar you have your links to a) retrieve your password for (2) after entering you password for (1), b) a link to go back to (1) and log the user out of (2) on the way and c) a link to logout of both (1) and (2). In the bottom frame you load the plain automatic redirect.

After a little work with AJAX, the first part a) was solved and I had the system returning the password to (2) when they enter the password for (1). The problem was the two links b) and c). Often you have trouble manipulating one frame with javascript from another frame. I found, however, that I could change the location.href of the bottom frame from top frame with the following statement.

top.frames['bottom'].location.href = "http://www.example.org/logout/";

Given the right URL to log out of (2), it’s possible now to force a logout in the bottom frame from the top frame. Now, by setting a timeout, we ensure that the logout from (2) is complete before commanding the entire window to go back to (1).

setTimeout('top.location.href = "https://www.originaldomain.com/";', 200);

With a little adjustment of the URL’s and setting up the event handlers, I now have two links in the top frame that will b) log the user out of (2) and redirect to (1), and c) log the user out of (2) and (1), redirecting back to the login page for (1).

Using frames is a bit 1997, but it does present a workable solution that makes the whole interface work much better for the user. An example of when one needs a solution not an ideal.