Upgrading to Expression Engine 2

Upgrade

I’ve been using Expression Engine as my CMS of choice since 2008. December of 2009, Ellislab released Expression Engine into Beta allowing people to start testing it in various different environments. While people were singing songs of praises, a number of bugs were being uncovered which at the time was a good thing to happen. That’s what pre-releases are for: identifying and fixing unknown bugs.

Fast forward to today, almost two years later, I finally decided to upgrade my site to the latest version of EE2. Beforehand, I would like to applaud Ellislab for overhauling their forums and site design. It looks astonishing and much more pleasant to use.

Before I get into the downs of the upgrade, I need to contextually share my setup and how I deploy and maintain my sites. My sites are mostly managed (use some flavors of wordpress and jekyll) with Expression Engine v1.7.3 as my main CMS, versioned controlled and deployed with Git and Capistrano(experimentation), and developed on a Macbook Pro running MAMP. I own a virtual server and a server locally (Ubuntu) where I test my deployments. I also use github to store some code snippets.

The plan was to upgrade locally, create a new branch, upgrade, test, deploy to a dev environment and then once the site was finally redesigned and upgraded, push it to production.

I followed the user guide promptly, verifiied all permissions, exact how the user guide explains but I was getting a ”Your config file does not appear to be formatted correctly.” error when trying to launch the upgrade wizard. I redid this process over 3 times and no success. I searched Google and EE forums for a possible solution to my problem but nothing seemed to be leading me to a viable solution. I posted a new topic in EE forums to see if anyone had faced some odd issue but the people who have experienced this error were able to solve the problem by applying different fixes; fixes which I had already tried and verified against my installation.

As a last resort, I created a ticket with the support team to see if we could collaboratively find the root cause of the issue. It’s been almost two weeks since I’m trying to tackle this issue. To clarify, it’s only been two weeks because my work has been hectic this past two weeks (it doesn’t look like it’ll easen) but the support team has been responsive enough in helping me with this. (One a different note, I’m not quite sure I like the new structure Ellislab has imposed upon its users but that’s a topic for a different post.) Support team suggested me to push a copy of my site to a live server so they could login and verify all the files. At first, I was reluctant to do so due to the way I deploy my sites. I never upload my sites using FTP, aside from a very insecure method, FTPing files into my live server would disrupt my version control workflow making things completely out of sync. However, I, surprisingly, thought of deploying another instance of my branch into a subdomain on my production server. So I spun up a new instance of my branch into a subdomain on my production server quickly, with new FTP credentials for the support team to login and troubleshoot. The support team verified all the files and found a few permission issues which I assumed such issues were caused during the process of copying the files over. I had triple checked the permissions and they matched what the user guide says. So this time, I did the process myself. I deleted all the files on this newly created subdomain and reupload everything over again. It also worked for me. However, I needed it to work locally. It didn’t really matter if it worked on my live server because one, as mentioned, I never FTP files. It would be more work in the long-run.

The Solution

In order to create a lean, easy-to-understand URL segments that wouldn’t harm search engine rankings and disrupt analytics, I applied a method using apache’s directory level configuration file (.htaccess) to remove index.php from URLs. The catch is, I didn’t realize that the .htaccess file was causing the “Your config file does not appear to be formatted correctly” error to occur locally. I didn’t realize about it until a couple of nights ago, when I was glancing over the files for the 12th time. Also, the reason why the files worked remotely on a subdomain was because I had uploaded the files via FTP, and since .htaccess is a hidden file by most operating systems, the .htaccess file doesn’t get uploaded via FTP.

So if you run into this issue in the future and happen to be using an .htaccess file to reformat URLs, you want to check your root directory, locate the file .htaccess and rename it. I truly hope you (reader) this article can save a ton of time because, in the end, that’s what the web is all about: sharing.