The Mysterious Case Of The Broken URL Rewrite

Act 2: Storm clouds gather

The first real problem, and where this blog post begins, was when I started noticing bizarre stuff going on with files produced by the excellent CE Image plugin for Expression Engine. Images were being created and cached in a specific folder where browsers would pull from when required. As I'd recently switched to a local – dev environment workflow, I was finding that when files were being uploaded via Beanstalk, the user:group permissions were causing deployments to fail.

Act 3: in the eye of the SSHit-storm

Some Googling later, and it turns out that servers that run DSO PHP don't handle permissions so well when a file is created without specific user:group settings. It was defaulting to a unspecified “nobody” 99:99 setting, which FTP wasn't able to overwrite due to lacking high enough permissions to overwrite these 99:99 files. Deleting them was also proving to be difficult requiring me to go delving into the server root via SSH – never a pleasant experience for a Terminal-phobe like myself.

The remedy, so the posts suggested was to switch the PHP type to suPHP. Quick word with my Memset and it turns out it is of course possible to do so on my server. So we switched it over, ran a script that cleaned up all the current permissions on the server and indeed my file permission problems were a thing of the past.

But the story can't end there... that would be far too easy, and there's still popcorn left in the bucket.

Act 4: The Twist (of the knife)

Whilst the permissions problem was over, the .htaccess rewrites of URL to remove the unsightly index.php from URLs was no longer working. Anyone familiar with the dark arts of .htaccess will no doubt understand the following:

As a quick fix while I was in the middle of trying to get 3 now broken sites out the door before the end of the month, I found that changing the penultimate line to:

RewriteRule (.*) /index.php/$1 [L,R]

meant I could at least access pages albeit with the index.php still in the URLs.

The sites at least now worked.

Act 5: To the library for some digging around and see what would come up

Buying myself a little time I did what all us not-so-technical folks do and hit the tech support forums.

The trouble was, server people wouldn't touch the problem as it was to their mind something to do with the the Expression Engine CMS; Expression Engine were reluctant to get too involved seeing index.php removal as something that is dependent on the server configuration; cPanel were pretty confident it wasn't anything to do with DNS, nor the vagaries of subdomains, and various EE devs couldn't pinpoint the cause either.

Act 6: The smoking gun

Eventually, through the highly advanced bug-testing method of “Trial and Error”, the URL problems were narrowed down to something to do with the NSM Bootstrap file, a pretty vital part of the multi-environment setup.

All sites that used it were breaking, all sites that were before it's time remained unscathed; take a site that was not working and remove the dependency on NSM Bootstrap and it worked again.

Act 7: The final showdown where the culprit is revealed

Back to EE's own support forums and with everything I'd gleaned from the whole sordid tale so far, I laid it all out to see what would come back. The final piece of puzzle came from the3mus1can, all to do with how the config files handle the uri_protocol. Full forum thread here.
And so the sites finally work again, file permissions are behaving, URLs are being re-written correctly and the server is that little bit more secure.

Act 7: Epilogue

We also got those 3 sites launched (the last one, fancie.co.uk, actually going live today), all within the month and my sanity is just about intact, just a few more grey hairs for the beard.

...or is it the NSM config.php file in the suPHP with the incorrect URI_PROTOCOL?

I get confused.