So I was browsing the internet today and checking for latest versions of software (PHP, Apache, etc) and I thought I might as well check on an update for Gallery. I was looking through the page and found that WordPress can be integrated with Gallery through a plugin; how I did not come across this plugin before is beyond me. So of course, the installation of said plugin turned out to be a necessity.

Everything went smoothly, as with any other plugin – it got put into the plugin directory and activated through the WordPress Admin section. Then to editing the options – walking into the first tab under WPG2 presented me with a nice entry about “your Gallery rewrite module has been disabled. Go to the next tab to re-enable.” Alright, I thought to myself, shouldn’t be too hard to get fixed up. The next tab presented me with a mostly white (no CSS) style page that told me that the URL rewrite couldn’t be enabled and to go and re-enable it within Gallery. Odd.

So, I navigated back to the main tab of WPG2 only to find myself staring at an Internal 500 Server error. Great, the plugin broke something on my machine. All of my site (including my Gallery) was filled with Internal 500 Server errors. I couldn’t disable the plugin through the WordPress interface because of this, so I went and tried manually deleting the files from the plugin directory – only to find that something was still locked onto the folder, not letting me delete it. I then proceeded straight to the .htaccess files (since I knew that the error had something to do with rewriting one of these) located in the root directories of my site and found that they hadn’t been touched since the upgrade that I did a few weeks back. Odd, yet again.

Replacing all my files in my site directory with backups didn’t help either; my site was still filled with the 500 error. This plugin couldn’t have messed something up with Apache itself, could it? After all, this wasn’t a malicious plugin of any sort. I went back to my Apache directory and checked folder modification dates to find that the only folders that had been affected recently were those of the logs. Ah, why hadn’t I thought of that yet – check the error log and see what Apache is really complaining about. Sorting through the various data and 404 errors, I came across to the last entries – something about URL rewriting not being able to accept a parameter (edit: specifically “C:\.htaccess: RewriteBase takes one argument, the base URL of the per-directory context”). Interesting. Even more interesting was that Apache was now referring to an .htaccess file that was under C:\. Why in the world would an .htaccess file be written there? Apparently, this was a problem with Gallery itself as the functions that were invoked were from the Gallery coding referenced by the WPG2 plugin (though the plugin could have passed in some bad parameters as well, not really sure here at this point – URL rewriting works perfectly with Gallery, so I assume it’s something with the plugin).

So I deleted the .htaccess file from the “ultimate” root directory and found my site to be back up and running. Well, that’s good, but I still want the plugin to work…so how? Well, if something (either the WPG2 plugin or Gallery) likes writing to C:\.htaccess, let’s make it so it doesn’t. Making a blank .htaccess file and setting the permissions to read-only, I moved it to the C:\ directory and then went back to the WPG2 rewrite tab in the Admin section of WordPress. Needless to say, everything else went quite smoothly from then on. I’m still going to check in on exactly which function call made that .htaccess file in the first place and hopefully fix this need for the blank .htaccess hack.

Edit: (12/12/07) The .htaccess file is only needed the first time you enter into the rewrite tab in the WPG2 options. After initializing the rewrite options through there, I could remove the .htaccess file and have no further problems. So it must be something in the first “set-up” of this plugin that’s causing this problem.