Error Siteground Staging Push
Had an odd occurrence while moving a fairly complex WordPress project from staging to live on SiteGround hosting. One of the reasons I recommend SiteGround is their behind-the-scenes development tools. Their staging tools for simplicity and usefulness being chief amongst them.
What staging lets us do is to build out a WordPress site (or update the existing site) in a separate instance. Once satisfied we can push those changes from the staging environment to replace the contents of the live site. This comes with all the niceties of automatic backups and rollbacks on failure. Especially things like automatically updating (some of) the URLs used in the WordPress site, very nice.
I don't understand specifically what the tool used to push the staging sites to live does, but I have surmised it is something along the line of:
- backup existing site
- backup existing database
- remove files from existing site
- clear database from existing site
- copy files from staging site
- copy database from staging site
- update urls in database from staging* to www*
Perhaps some shell scripting or Python or something making all of this work, really shouldn't matter. Just that it works and thus far has always been a smooth process. Till this week.
Error Pushing from Staging to Live
For the first time I had an error bringing a site over from staging. The process failed and left me with an error:
Failed to push this staging environment to the live site. Failed to correct the url addresses!
Ugh. What is this about? Failed to correct the URL addresses? Was I doing something weird with URL's somewhere in my site that caused the whole thing to fail? So strange. After some noodling around without much success in trying to fix the problem myself I headed over to support.
To The Techs!
I have not had to use SiteGround support much, and when I have it has been very fast and responsive. So I started the online chat. Most of the conversation revolved around DNS, like how was I accessing the site, was there a public DNS entry, that sort of stuff. (There was not, I was using a local hosts file.) The support person was convinced that pushing from staging would not work because the dns entry for the live host was not public. I could see that perhaps having something to do with a message like "Failed to correct the url addresses." At the same time it did not seem right, I have successfully pushed from staging for private domains before. Also that just did not make a lot of sense, why would a copy/publish tool be requiring things from an external DNS? I told her as much, that I could not believe that was the issue, at which point I was encouraged to open a ticket.
The level II tech was also stuck on the DNS thing, but did understand what I was talking about with host files. He quickly moved me along to level III. This was the good stuff, the level III tech was able to cut to the quick, and found that the staging tool was choking on a syntax error in one of my custom theme's file.
This was weird for a few reasons:
Why was the migration tool executing my code at all?
I had been surmising it was more of a copy and munging process, not executing any of my PHP.
Why are there syntax errors when the site execute without trouble?
This bothered me more. The themes executed without trouble in staging and in live. Why would I get syntax errors during what amounts to a transfer?
php 5.4 introduced the array literal syntax
$foo = ;
before it was the more longwinded array():
$foo = array();
Locally I am on php 5.5.9, over at SiteGround we are at 5.5.17, fairly close, and not going to cause too much trouble. But here is the rub: the version available in the shell (and used in the tools is (not 5.5.17 but 5.3.29. So even though what I did worked in staging as a website, and works on live as a website, it fails on the transfer because the tool managing the transfers php-cli is running on a current but lower minor version.
Changing those array literals to the older array syntax fixed everything and the push works fine.
Error messages are misleading
I was tied up for two levels of support around the concept of 'urls' which ended up having nothing to do with the problem. Perhaps that was the final error message which was carried through? Either way faulty error messages are the worst of the worst when it comes to trying to debug a problem.
Assuming makes an...
All my suppositions of how the tool worked were totally wrong. Somewhere in that was execution/syntax evaluation. Your maximum execution environment is the lowest in the chain. In the case of SiteGround they were running a lower version of PHP causing code I assumed was not to be interpreted to have a syntax failure while migrating between two perfectly acceptable versions of PHP.