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.

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.

On Apache, the normal way to handle this is to add lines like this to your .htaccess:

redirect 301 /old.htm http://www.example.com/new

Unfortunately, in this case we aren’t using Apache–we’re using IIS 6. I could set up redirects from within IIS itself, but as far as I can tell that would require creating dummy files for each of our old URLs, and telling IIS to redirect each to their new URL, and I’m not interested in having a bunch of dummy files lying around waiting for someone to accidentally delete them. Instead, the smart way to approach the problem is via ISAPI_Rewrite, an IIS module which mimics some parts of Apache’s configuration, which we happen to already have installed.

Long story short, add this to your httpd.conf:

RewriteCond ^old\.htm$ new [R=301,L]

Why is such a trivial solution worthy of a blog post? Because it took me more than an hour trying different combinations of options to find one that would work. Why? Because ISAPI_Rewrite 2′s documentation has better Google juice than ISAPI_Rewrite 3′s, and I wasted my hour scouring the wrong one and following the advice of others running that version.

In this case, my VPS was running IIS 6 and the updates weren’t working. First, the update screen would merely say it was downloading the new version, and it would never make any progress. Then, when I extended PHP’s max_execution_time, I encountered a FastCGI internal error saying the process exceeded the configured activity timeout. When I corrected that, WordPress reported permissions errors while trying to move the new files into place. My full solution was as follows:

Backup Everything

Any time I’m updating anything; download a full & current copy of the site, and export all tables from the database.

Fix the FastCGI Timeout

Open \WINDOWS\system32\inetsrv\fcgiext.ini, and, in the section labelled PHP, add ActivityTimeout = X, where X is the desired number of seconds after which to terminate an unresponsive script. Restart IIS.

Fix Permissions

Much like how apache is often configured to run as “nobody” in order to prevent malicious scripts from modifying files, IIS (by default) runs as a user named IUSR_[hostname], where [hostname] will be a string you set up when initially configuring your site. Unlike apache, however, on IIS, 777 permissions don’t necessarily mean any user is permitted to write to a given file or directory.

To fix the problem I had to open up my web root in IIS, and give my IUSR_[hostname] full permissions. I was then able to run the update, after which for security purposes I reduced that users permissions to the original level.

For a recent project hosted on one of our VPSes, I was planning to use Kohana, which requires PHP5. Despite the fact that PHP5 was released in 2004, it wasn’t installed on the VPS in question. As the VPS was running Plesk, any changes to the PHP installation would have to be made carefully so as not to demolish our hosted sites, but research revealed the Atomic Rocket Turtle Repository, designed exactly for upgrading machines such as mine. Except that yum wasn’t even installed.

The procedure was as follows:

Install yum

Note: If you’re following along at home, instead of just copy pasting my terminal commands, you should probably make sure your rpm -Uvh calls are requesting contemporary versions

First, install a key from the CentOS mirrors so rpm will work:
rpm –import http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-4

Then, try and fail to install yum in order to get a full list of missing dependencies:
rpm -Uvh http://mirror.centos.org/centos/4/os/i386/CentOS/RPMS/yum-2.4.3-3.el4.centos.noarch.rpm

Next, install each listed dependency with a call to rpm -Uvh

Finally, install yum by re-running the rpm command above

(based on instructions here)

Set up the Atomic Rocket Turtle repository

wget -q -O – http://www.atomicorp.com/installers/atomic.sh | sh

Upgrade PHP

yum upgrade php

Reinstall Ioncube Loader

(Note: As we weren’t using the Ioncube Loader, everything worked without this step. Except that we were getting notices in our logs saying it was missing.)

yum install php-ioncube-loader

Set up new (default) php.ini

mv /etc/php.ini /etc/php.ini.php4
mv /etc/php.ini.rpmnew /etc/php.ini

Restart Plesk

/etc/init.d/psa stopall
/etc/init.d/psa startall
/etc/init.d/psa restart

Miraculously, Plesk restarted successfully and all my applications were fully functional under the new install of PHP5.

I could’ve stopped here, but because the VPS had been running for a few years, and yum hadn’t been installed, I knew that basically everything (if not literally everything) on the server was out of date. Research and testing aside, the above took less than 10 minutes. The below (upgrading everything) took several hours of troubleshooting.

Upgrade everything server-wide

yum upgrade

(Note: This might take a while. I made sure to archive the output, because when anything goes wrong, the clues will show up here.)

Set up new MySQL configuration

(Note: At this point, Plesk wouldn’t restart because MySQL (just upgraded from 4 to 5) was totally broken.)

mv /etc/my.cnf /etc/my.cnf.old
mv /etc/my.cnf.rpmnew /etc/my.cnf

Install new Plesk package to support openssl upgrade

(Note: Now MySQL worked, but Plesk was still broken.)

If you update from an old vesion of openssl, you’re probably going to run into a bug, the quick solution to which you can find here.

Update MySQL databases

(Note: Plesk would restart, but I couldn’t log in.)

mysqlcheck –check-upgrade –all-databases –auto-repair -uadmin -pyouradminpassword

After reading all the documentation I could stand and going through the process a number of times, this is the protocol I’ve developed for myself:

1. Make sure all your modules are compatible with the new version

If they aren’t, you should deal with this before the update, not after.

2. Back up all the files, and the database

If anything goes wrong, I need to be able to revert to a known-working state. This also serves as a useful archive, in case anything goes wrong with the site between updates.

3. Put the system in maintenance mode

This will prevent any visitors from potentially encountering a scarily-broken web site before you’re done upgrading.

4. Create a temporary folder, and move all the existing files in there

Don’t want to run the risk of overwriting anything important (especially .htaccess or /sites). Alternately, you could delete your whole site and then re-upload, but this is faster.

5. Upload the new version of Drupal

6. Replace the freshly installed /sites/all folder with the old one from your temporary directory or your backup

This should restore all modules and themes. You’ll notice that I haven’t disabled any modules or themes prior to the update: I only work with custom themes, and so far none have broken in an update. I try to use as few modules as possible on any given site, and always check to ensure essential modules are compatible prior to an update.

7. Move /sites/default/files from your temporary directory or backup to /sites/default/files.

You might need to change the permissions on the old /sites/default/files to do so.

8. Reconcile /sites/default/settings.php

Compare the old /sites/default/default.settings.php to new one. If they match, you can just move the old /sites/default/settings.php to the new /sites/default directory. If they don’t, you need to open the old /sites/default/settings.php, copy /sites/default/default.settings.php to /sites/default/default.settings.php,
and migrate all settings to the new /sites/default/settings.php we just
created.

9. Reconcile .htaccess

If I’m getting Internal Server Errors after the update, it’s nearly always because I missed something in this step. Compare your old .htaccess to your new .htaccess, and make sure to migrate any changes over. For me, this nearly always means enabling RewriteBase (to support pretty urls), and ensuring Drupal runs under PHP5 (required by many modules).

10. Run update.php

This will upgrade all your database tables to the new version.

11. Take the system out of maintenance mode

12. Visit /admin/reports/updates to make sure everything is ok there

13. Verify functionality