application/vnd.openxmlformats-officedocument.wordprocessingml.document;
name="filename.docx"
Content-Disposition: attachment;
filename="filename.docx"
Content-Transfer-Encoding: base64

This “header” is followed by a bunch of base64 gobbledygook. In short, my original attachment appeared to be getting itself wrapped in an attachment, prefixed with its headers minus the string “Content-Type: “.

Turns out the problem was line-wrapping. I was hardwrapping the entire message to ensure a maximum line length of 70 characters (as recommended by the docs), and this was causing the obscenely long (> 70 character) mime type used by .docx to wrap onto a separate line from the string “Content-Type:”. Subsequently, Outlook was seeing a blank content type, freaking out, and putting the rest of the message into an attachment.

Moral of the story: Don’t hardwrap your email headers. Or use a library which keeps you from worrying about absurd implementational details.

BookIt Web Application System Architecture

The core BookIt system allows OE clients to login and reserve conference rooms from any of the dozen OE business centers located across the Colorado.  OE staff can create new reservations as well as manage those created by the clients.

BookIt Admin Role View

We extended the system to fully integrate with OE’s CRM and billing system NetSuite.   BookIt validates users account from OE’s NetSuite client set, allowing clients to use their existing account credentials.

From the other perspective, BookIt reports conference room usage back to NetSuite for fully automated billing via their existing billing routines.

BookIt Create Reservation

The systems are fully synched and now manage, dozens of unique rooms, thousands of users and hundreds of weekly reservations.

BookIt Reservation History

We built BookIt on the Kohana platform using PHP/MySQL.

BookIt Public View of Availability

First, I began a fruitless investigation into forcing various compatibility modes with little or no effect on the broken display.  The various doctype declaration settings didn’t do much either.

Finally, I stumbled on the following fixes:

• Update Cufon-yui.js scripts – this fixed a good percentage of the problems
  http://cufon.shoqolate.com/generate/
• Re-order CSS font stacks containing Helvetica
  from Helvetica, Arial, sans-serif to Arial, Helvetica, sans-serif
  http://simunix.com/wordpress/index.php/2011/03/18/ie9-helvetica-bug/

That took care of most of the critical IE9 bugs, but I still needed to update the following scripts:

• Update to jQuery 1.6.1 – slightly older versions break in IE9
  http://jquery.com/
• Update typface.js – this will break just like Cufon
  http://typeface.neocracy.org/
• Update Lightbox – old version thows IE9 warnings
  http://www.huddletogether.com/projects/lightbox2/

Microsoft is really doing a great job holding back web design and the internet, as per usual.  I don’t know enough javascipt to explicitly fault Microsoft for the IE9 script errors, but the number of new errors points heavily in their direction.  Furthermore, I do know that the IE9 Helvetica bug is a major flaw which should never have made it past QA  testing.

I found my solution in rewrites. Users visit a url such as “example1.com/about” or “example2.com/about”, and I rewrite it so WordPress treats it as “example1.com/example1/about” or “example1.com/example2/about” without the user knowing the difference. I tried three different options before stumbling on one that worked well.

1) .htaccess

Didn’t work. Why? Because WordPress is expecting queries to be directed to index.php, and then it looks at REQUEST_URI to figure out how to dispatch the request. I couldn’t find a way to change REQUEST_URI with an apache rewrite without directing the request away from WordPress.

2) WordPress rewrite_rules

I got this working, but it was punishingly slow. On every page load, I had WordPress regenerate its rewrite_rules, depending on which HTTP_HOST is being accessed.

3) Change REQUEST_URI inside WordPress

Sounds scarier than it is. As soon as the request is inside WordPress—I chose wp-config.php, because it’s designed to be user editable—check which HTTP_HOST is being accessed, and then change the REQUEST_URI appropriately.

From there it’s just a matter of implementing a zillion WordPress hooks to change URLs whenever you output them, to remove the site prefixes. And to filter certain categories from blog listings, blog archives, et cetera. But I’ll save that for another post.

Those days appear to be over.

yum install php-mssql

That, my friends, is all we had to do, thanks to the atomic rocket turtle repository and our earlier efforts to modernize our server.