After some great experiences developing on our local server we were looking forward to publishing the website on the remote server for initial testing and debugging but all we got was a major headache. A critical bug that shouldn't have existed in a paid for product made our lives hell trying to get the website just to load.
Despite working perfectly on our MAMP development server (Apache2, PHP 5.4.4 & MySQL v5.5.25) as soon as we FTP'ed the site to a remote server with a similar spec the website just hanged when called from the browser eventually resulting in a 504 Gateway error warning.
Put simply the website wouldn't load and it was maddening as hell.
Now we don't want to sound as if we're slagging off the guys at PyroCMS as we think they've done a pretty damn good job with developing and delivering one hell of a CMS. Having developed our own in-house content management solutions we're well acquainted with some of the challenges involved in making a system that's robust, user-friendly and extensible. Not an easy undertaking, particularly with third party integration requirements and implementing across different server platforms.
Add to that the inevitable ability for clients to find bugs that weren't uncovered during UAT and break functionality that was previously seen as robust and the world of CMS development is far from simple. To put it bluntly, it can be a major pain in the arse. We have the greatest admiration for what Phil and his team have done with PyroCMS and plan on rolling that CMS out for future client projects as we think it's one of the best platforms we have ever worked with.
That said, we are super frustrated with what appears to be a bug in the 2.2.1 professional version of PyroCMS when deployed to a remote server.
So where do we go from here?
Now the first step in trying to find a solution is simple: are we doing something wrong/is there something we've missed?
After going over the PyroCMS documentation and trawling the forums the answer appears to be no. Other users are experiencing similar problems and despite recommendations suggested there the problem just wouldn't disappear and made us wonder if we were going to have to abandon altogether PyroCMS for our client project (which had to be delivered within the next week).
After trying everything that we thought might work, exhausting our options in the process and rapidly coming to the point of wanting to throw the computer out of the window we hit upon the idea of hunting down the issue by focussing on the codeIgniter installation for PyroCMS.
Thanks to a few echo statements and print_r declarations it turns out that's where the issue was originating from.
Turning the tide
Given our backs were up against the wall with a looming client deadline and we didn't have the luxury of devoting time to digging through the code to isolate the exact line (or lines) that were causing the server to hang and quit we did the next best thing.
We made an archive of (always a wise idea if things should go slightly wrong) and then replaced the entire PyroCMS 2.2.1 system/codeigniter directory with the version 2.1.5 system/codeigniter directory contents instead (one forum poster had suggested downgrading to a previous version of PyroCMS to solve the problem - we wanted to avoid that if we could and just replace parts of the installation instead).
At last we could load the website!
There were, as we expected there to be, a few errors though (given we were bastardising the installation it would have been surprising were no errors to be found). Here's what we experienced and how we solved them:
- Added the system/cms/errors folder from PyroCMS version 2.1.5 to the system/cms/ directory in version 2.2.1 to solve one error warning that was being written to the browser screen
- Replaced the default PyroCMS 2.2.1 codeigniter system/cms/config/mimes.php file with the same file from PyroCMS 2.1.5 and added the following on line 142: return $mimes
- Commented out line 412 in system/cms/modules/users/libraries/Ion_auth.php as we were getting a fatal error when attempting to log out of the CMS
Granted this is not an ideal solution but it solves the issue of the website not loading at all and, so far, it seems to work without generating any further errors - fingers crossed!
It sucks that we had to jump through so many hoops to get the installation working on the remote server but until the guys at PyroCMS sort this issue out it's a hack we're going to have to live with.