Uploading Large Files to WordPress under IIS 7

There are several small but frustrating hurdles to overcome if you want to upload large files to WordPress if it happens to be running under Windows 2008 and IIS 7.

(In this case, “large files” are any file specifically over 30MB. We’ll see why later.)

Step 1: PHP.ini

First, you need to edit your server’s PHP.ini file. This is found in your PHP installation directory, e.g. c:\program files\php\php.ini and set the following values:

upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
max_input_time = 300

This allows PHP to handle files up to 64MB and allows PHP scripts to run up to 5 minutes before timing out.

Step 2: WordPress options

Next, we need to tell WordPress to allow files of a certain size to be uploaded. I’m running WordPress 3 in multi-site mode. The max file upload size setting can be found under:

Super Admin | Options

Step 3: Microsoft IIS 7

Lastly, IIS 7 has a default file upload limit of 30MB. Anything larger than that will cause IIS to return a very unhelpful 404 status. You can read more about it at http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering/requestLimits

To override this, you need to change the web.config settings for (each) site. (The only catch here is that the limits are expected to be in bytes instead of kilobytes.) The following is some copypasta from the MSDN docs:

Don’t forget to recycle your application pool so IIS picks up your PHP.ini changes.

And that’s it!

Running Multiple Ruby Versions

Ruby 1.9.2 was just released last week (and the RubyInstaller for Windows was updated a couple days later.)

Similarly, IronRuby recently released version 1.1 last month.

If, like me, you currently have an older version of Ruby installed like 1.8.7, how can you upgrade while ensuring there are no compatibility issues with code you’ve written or 3rd party gems/plugins you’ve used?

You could spin up a new VM instance, sure, but that seems like a lot of overheard for testing a new language.

A pile of Rubies

Enter RVM, the Ruby Version Manager. (If you don’t happen to use a linux distro or OSX, there’s a similar project called Pik available for Windows.)

Intro to RVM

1.0 was just released; rejoice! From the RVM homepage:

RVM is a command line tool which allows us to easily install, manage and work with multiple ruby environments from interpreters to sets of gems.

Installation is a breeze using the RVM shell script:

$ curl http://rvm.beginrescueend.com/releases/rvm-install-head | sh

This uses curl to download the script source and pipes it to the shell to be run. There is one additional step, and that’s to edit your shell configuration (~/.bash_profile on my OSX machine):

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm" # This loads RVM into a shell session.

Then just open a new shell session and start using RVM. Some helpful commands are:

$ rvm install 1.8.7
$ rvm install 1.9.2
$ rvm list
$ rvm --default 1.9.2
$ rvm 1.8.7

(The RVM documentation has more information on commands and their usage.)

Pik for Windows

Pik is similar to RVM, but works on Windows. It’s “just a gem”, so installation is also a breeze. First, create a c:\pik\ directory and add it to your PATH environment variable. Then just:

c:\> gem install pik && pik_install c:\pik\

I already had 1.8.7, 1.9.2 and IronRuby installed, so to make pik aware of them I only had to run:

c:\> pik add c:\Ruby187\bin
c:\> pik add c:\Ruby192\bin
c:\> pik add c:\ironruby-1.1\bin
c:\> pik list
c:\> pik switch 1.9.2

(Refer to the Pik documentation for more commands.)

Cross-platform, side-by-side language installations. So good.

"JavaScript doesn’t suck, you’re just doing it wrong."

Douglas Crockford

Getting Started with Rails 3: Part 3: Application Templates

Somehow I missed this awesome feature introduced in Rails 2.3 — application templates.

If you find yourself making the same customizations to the stock rails application over and over again, you can roll them up into an application template.

If we run rails new -? from the command line, one of the options is:

-m, [--template=TEMPLATE] # Path to an application template (can be a filesystem path or URL)

I’ve taken my testing preferences from Part 1 and my javascript preferences from Part 2 and created the following template:

Putting it all together, I can easily start a new Rails app with the same settings by running:

rails new NewAppName -JTm http://gist.github.com/raw/524546/Rails-3-App-Template.rb
  1. Read Part 1 where we configure Rails 3 to use RSpec and Cucumber as the testing framework instead of Test::Unit
  2. Read Part 2 where we configure Rails 3 to use jQuery as the client-side JavaScript library
  3. Read Part 3 where we put it all together as an Application Template

Getting Started with Rails 3: Part 2: jQuery

This was a difficult choice to make; I was introduced to Prototype & Scriptaculous through the rails-spinoff project 5 years ago. I credit them with reigniting my interest in the JavaScript language, and front-end web development in general. They advanced the state of the art while simultaneously making development fun again!

They’re mature, stable libraries, and that’s great! But without a major release from them in almost 3 years, alternatives like jQuery (and jQuery UI) have surpassed them in (no particular order): performance, community, training, corporate adoption, ease of use and mobile vision.

So what does this have to do with Rails 3?

Of square pegs & round holes, or, Enter Unobtrusive JavaScript

Taking advantage of the AJAX-enabled view helpers included in Rails (or homegrown) meant tightly coupling our markup (structure) with our JavaScript (behavior). For example, calling link_to_remote() actually outputs <a href="#" onclick="new Ajax.Updater();"> which references the Ajax object from the Prototype library. (The amount and complexity of the JavaScript depends on the options passed to the view helper.)

Rails 3 forgoes emitting JavaScript in favor of data-* attributes from HTML5 and event listeners. Out of the box, those listeners are based on the Prototype API.

(In Part 1, we created a new Rails application and excluded Prototype & Scriptaculous from our project.)

To use jQuery instead, you just need to:

  1. Download the jQuery adapter from http://github.com/rails/jquery-ujs/raw/master/src/rails.js and save it to the public/javascripts directory.
  2. Edit config/application.rb and add:
config.action_view.javascript_expansions[:defaults] = %w(http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js rails)

(I’m cheating a little and loading jQuery from the Google CDN.) That was quick: we’ve now configured our application to load jQuery instead of the included JavaScript libraries.

Let’s save our progress again and commit our changes in Git:

$ git add public/javascripts/rails.js
$ git commit -a -m "use jQuery instead of Prototype/Scriptaculous"
$ git tag part2

(Feel free to fork my Github repository if you’d like to follow along athttp://github.com/defeated/wisdombiscuit)

  1. Read Part 1 where we configure Rails 3 to use RSpec and Cucumber as the testing framework instead of Test::Unit
  2. Read Part 2 where we configure Rails 3 to use jQuery as the client-side JavaScript library
  3. Read Part 3 where we put it all together as an Application Template

Git colorization tip!

Unfortunately the configuration options to enable colors in Git output messages isn’t enabled by default.

You can turn them all on by running:

$ git config --global color.ui true

or individually by running any of the following:

$ git config --global color.branch auto
$ git config --global color.diff auto
$ git config --global color.interactive auto
$ git config --global color.status auto

(the --global flag enables this across all Git repositories.)

That gives us nice looking messages like:

Getting Started with Rails 3: Part 1: Cucumber/RSpec

Wisdom Biscuit was my first Rails application. It’s hosted at Joyent (when they were still known as TextDrive) and runs on Rails 1.2.3.

I know, right?

With the imminent release of Rails 3, I decided to refresh the app and build it on the latest version, hosted over at Heroku. And since I recently finished reading The RSpec Book, I’ll attempt to drive it’s development from the outside-in (practicing BDD with Cucumber and RSpec.)

First, I’ll make sure my development environment is up-to-date, and run:

$ sudo gem update --system
$ sudo gem install rails --pre
$ sudo gem install bundler --pre

One of Rails’ many opinions is to use Test::Unit out of the box. Another provides you with the Prototype/Scriptaculous JavaScript library. I want to change those to use Cucumber & RSpec as my testing libraries, and jQuery as my JavaScript library.

Rails 3 makes that easy.

File | New, or, Creating a fresh application

From the command line, run:

$ rails new -?

Amongst other usage flags, we see:

-J, [--skip-prototype] # Skip Prototype files
-T, [--skip-test-unit] # Skip Test::Unit files

So I’ll create the new Rails application skeleton and exclude Test::Unit integration and Prototype/Scriptaculous JavaScript integration, by running:

$ rails new wisdombiscuit --skip-prototype --skip-test-unit

Dependency Management, or, Getting by with a little help from our friends

To use RSpec and Cucumber, first we explicitly define them as dependencies in the app’s .gemfile (used by Bundler, as we’ll see in the next step):

group :test do
  gem 'rspec',          '>= 2.0.0.beta.19'
  gem 'rspec-rails',    '>= 2.0.0.beta.19'
  gem 'cucumber',       '>= 0.8.5'
  gem 'cucumber-rails', '>= 0.3.2'
  gem 'webrat'

The group block ensures they are only required when the application is running within the specified environment, which in this case is the test environment. Then we install those gems locally by running:

$ bundle install

And with any luck, you’ll see a list of all the gems scroll past as they’re downloaded and installed (or updated, if we had older versions of those gems already installed.) Now we’ll install Cucumber and RSpec folders & configuration files into our application by running:

$ rails generate rspec:install
$ rails generate cucumber:install --rspec --webrat

Then modify config/application.rb to tell Rails to generate new RSpec specs instead of Test::Unit unit tests whenever those generators are invoked:

# Configure generators values. Many other options are available, be sure to check the documentation.
config.generators do |g|
  g.test_framework :rspec

And that’s it for now: we opted-out of the default Test::Unit integration for our new Rails 3 application, declared our dependencies on RSpec and Cucumber & installed them locally, then configured our application to know how to generate features and specs going forward.

Let’s save our progress thus far and commit our changes in Git:

$ git init
$ git add .
$ git commit -a -m "new rails 3 app using RSpec and Cucumber"
$ git tag part1

(Feel free to fork my Github repository if you’d like to follow along at http://github.com/defeated/wisdombiscuit)

  1. Read Part 1 where we configure Rails 3 to use RSpec and Cucumber as the testing framework instead of Test::Unit
  2. Read Part 2 where we configure Rails 3 to use jQuery as the client-side JavaScript library
  3. Read Part 3 where we put it all together as an Application Template