Thread

Hi Dan,

Thank you, I really needed that acknowledgement.  I did hit on the idea of examining the update.php file, but it was tough slogging trying to figure it out, so I pretty much gave up on the manual process, hoping for a response here that might give me an idea of how many hours it might take me to essentially run manually the steps that the Update Wizard should be doing. I don’t have a blank check for this from my low-budget client. In fact all we’re really trying to do is install CartThrob, as our current manual process for credit-card processing is apparently non-compliant with new laws.  CartThrob requires at least EE v1.6x. When I got the client to agree on this, I figured the Update Wizard would do the body of the work, the whole thing taking no more than an hour. And if that went well, I’d be more prepared to tackle an Upgrade to v2.x But it’s already taken at least twelve hours of my time - well more than half of it Wrestling For Answers on this Forum - to get the Update to the current unfinished step.  In real time, our development site has been offline for two weeks. I feel terrible charging the client for more than an hour.  That’s all it should have taken. But it’s my time, my work, how I pay my bills.  Hey here’s an idea - how about I charge EE for the rest?  That makes more sense.

PS. I find it hard to believe that “Unknown Column” in the error messages is standard SQLSpeak for “Missing Column.”  Please tell me that idiot level confusion of terminology is just another instance of the sloppy design of the Update Wizard and not something germane to EE.

Hi johnnyb, let’s see if we can get this working for you.  From reading, I THINK things went wrong this go around about here.  You dropped all of your tables, imported the backup of your database- but did you roll back your system/config.php file to the same version you had BEFORE the failed upgrade? 

If not?  That file probably says you’re already on version 1.6 or something- instead of 1.4.1.  And it’s going to start running the updates based on that- skipping any between the actual version (1.4.1) and whatever is now in your config.php file.

That would explain the error you’re getting- that ‘can_send_bulletins’ field was created in the 1.5.0 updater- which I suspect was skipped.  And thus the field doesn’t currently exist.

I know it’s daunting, but the best option really is to:
1.  Roll back the database again- delete all the tables, import a whole fresh copy.
2.  Replace the current system/config.php file with the version from before the update.  If you don’t have a copy from then?  Go in and edit it so the version number is correct- it looks like the correct version would look like:

$conf['app_version'] = "141";

If you’re sure you want to update the client to 2.x, then you can go ahead and update using the latest 2.x release.  If you want to wait to decide- update using the latest 1.x code release.

And if you have any questions at all?  Let me know.

Hi Robin.  Thanks for this idea.  Weird though that if this is really the problem, nothing is said about it in “Troubleshooting Upgrade Problems,” and that no one has mentioned it previously in this thread.  I finally inspected the update.php code, and I can see that it has sections that seem to be modifying a config file.  But I didn’t know what to make of that, as up till now, all I’ve heard is “roll back the database.”

Oddly, the datestamp of config.php still shows in FTP as Jan 28, which is before any updates at all. Nonetheless, the contents show “160” as you predicted - and it’s way, way shorter than my 1.4.1 version. So thank you again.

However, rolling back the config file isn’t working. When I cleared the database, created a new one, and imported from the last update, and tried running the Wizard again, this new error message appeared:

Database Error: Unable to connect to your database. Your database appears to be turned off or the database connection settings in your config file are not correct. Please contact your hosting provider if the problem persists.

And come to think of it, your advice seems essentially to go back to square one and start the Wizard all over again from scratch. What’s the point of that? It’s just going to give me the same errors as before. At least before we were up to 1.6.  We should move on from there. I was getting new error messages once I fixed the tables. That should continue.

Unfortunately, I’ve now replaced the updated, shorter config file that had “160.” And the new one has a lot of stuff that the update apparently removed.

Grrr.

I know this update has been a real bear, but we just need to step through it and stop if we hit an error.  The last error you were getting (Unknown column ‘can_send_bulletins’ in ‘exp_member_groups’) was due to a skipped update due to the database being rolled back without the config file changing- you skipped several updates doing that, hence the error.  We don’t want anything odd in the database causing future problems.  Stick with it a little longer and we’ll get it up and running.

So right now- you’ve completely rolled the database back to the 1.4.1 version.  And we need to get the config file correct.  Do you have the (long) config.php file from before the upgrade?  It should have $conf[‘app_version’] = “141”; in it.  If so- and that is the config throwing the ‘can’t connect to db’ error, it should be easy to fix by adjusting the database config settings.  Those settings are:

$conf['db_hostname'] = "****";
$conf['db_username'] = "****";
$conf['db_password'] = "****";
$conf['db_name'] = "****";
$conf['db_type'] = "mysql";
$conf['db_prefix'] = "exp";
$conf['db_conntype'] = "0";

It’s the first 4 you may need to change- though the others should be in the file.  Just make sure they have the right information in place of the *‘s. 

Once that’s right- it should allow you to connect to the database and start the update over. 

If you don’t have a copy of that config file- there’s one for 1.5.1 in the wiki: http://expressionengine.com/wiki/Config.php_for_v1.5.1.  Use that as the basis- change the version to 141 and the other settings as needed.  Take your time with it- if you’re not sure about a setting, just ask me.

Once you can connect to the database and start the update- if you run into any errors, just stop and post back what it is.  We’ll walk through getting it fixed up.

Robin: none of the 7 config settings you quoted above have ever changed in any updates, and the last three have always been mysql, exp, and 0. Only the $conf[app_version] line has changed.  And it really did seem that might be the problem.  The “view file” feature of my ISP’s Plesk interface showed “160” in the Jan 28-dated version of index.php as I reported. I replaced that with a pre-update version from Jan 28 that said “141” before running the last update, but as I said, that gave me the last “cannot connect” error.

Any way, once again I’ve started completely from scratch.
Reporting in real time:

- deleted old database
- created new one
- created same user and password info
- imported backup 1.4.1 database of Jan 27 - last backup before any running of Update Wizard
  (not the later versions of 1.4.1 with hand-modified table changes per error messages)
- double-checked admin/config.php file to be sure version is 141
- ran Wizard
  - 1.41 to 1.4.2 - Good!
  - 1.41 to 1.5 - Good!
  - 1.5 to 1.5.1 - Good!
  - 1.51 to 1.5.2 - Good!
  - 1.52 to 1.6 - Good!
  - 1.6 to 1.6.1 - Good!
  - 1.61 to 1.6.2 - Good!
  - 1.62 to 1.6.3 - Good!
  - 1.63 to 1.6.4 - Good!
  - 1.64 to 1.6.5 - Good!
  - 1.65 to 1.6.6 - Good!
  - 1.65 to 1.6.7 - Good!
  - 1.68 to 1.6.9 - Good!
  - 1.69 to 1.7 - Good!
  - 1.7 to 1.7.1 - Good!
  - Optimize Tables - Good! (only took a second or two too)
- Removed update.php and updates folder
- No Version Notes for 1.71.
- Opened EE Control Panel - Good! Version 1.7.1!

Wow. I humbly apologize for everything I said about the Wizard being sloppily designed or glitchy. The whole thing took maybe 15 minutes at most. That’s more like what I expected. 

The whole problem - and it’s a real problem - was that there was no mention in “Troubleshooting Upgrade Errors” of the need to roll back the config.php file as well as the database after an error message.  And that, apparently, no one else else in this thread was aware of that need either.  Probably not a major concern for EEE, considering the rumors of all support for v1.x disappearing as of April, but that may cause a flood of upgrades to 2.0, so I hope you do what you can to correct it anyway. I wouldn’t wish this experience on anyone else, except for the happy ending.

Thanks again. Wish I’d gotten you as a first respondent on this thread.

John

PS I noticed there are notes for v1.7.2, but the Wizard stopped at 1.7.1.  What’s up with that?

PPS. A very minor, no-way crucial, by-the-way puzzlement, if you have time for a quick answer:  What’s return <<<OTHELLO in line 893 and OTHELLO; in line 906 of update.php? Appears to be some kind of code bracket, but I can’t find anything related to php or sql code Googling it.

Whew- glad that last one worked!  Once an update goes bad, rolling back is usually the easiest way to fix it.

And you are very right- that troubleshooting article could be improved by discussing the importance of rolling back the config.php file.  I updated the wiki’s Retrying after a failed upgrade section to emphasize that.  Hopefully that will help someone else in the future!

And the 1.7.2 version notes exist because a new build was related on Feb, 8 (changelog).  We hadn’t had a 1.x bug fix in ages (because there are very few known bugs).  If you want to upgrade from 1.7.1->1.7.2, you’ll need to run the updater, but there aren’t any actual database changes, so nothing can really go wrong.  The update on this one will pretty much just change the version number in the config.  Replacing files is where the real changes happen on that one.

And that OTHELLO bit?  Heh- that format confused the heck out of me the first time I saw it too.  It’s just another way to delimit strings (a la single/double quotes)- heredoc syntax.  The OTHELLO bit could be about anything- in the docs I link to, they use EOT - it just has to match up at the start and end of the string.

And again- sorry this update was so problematic.  It can be hard to narrow in on the issue when you’ve been troubleshooting something for a while.  So a fresh set of eyes proved useful in this case.

If you do run into any more problems?  Just let us know.  Hopefully it’s smooth sailing from here on out!

All’s well that ends well, I guess.  The only remaining problem for me is asking my client to pay for 15 hours of work that could have been completed in 2 if I’d only had the information you just added to the Troubleshooting wiki.  I quoted a half-price rate, really would love to be able to bill EE for that time.  Thanks for updating the wiki. Could you please put the phrase “restore you backup copy of the config.php file” in bold to make it stand out as much as “back up your database”?

That “heredoc” syntax is cool. I get it - it’s not the OTHELLO, it’s the <<< and ; 

Thanks again.

PS Another important wiki fix, this time for Updating from an Earlier Version of Expression Engine (http://ellislab.com/expressionengine/user-guide/installation/update.html)

8. Put Your Site Back Online

• Rename your root folder index file (exp/index.php) back to offline.php.
• Do not restore the exp/index.php file from your previous version!
• Instead, upload the exp/index.php file from your unzipped download of the latest version of Expression Engine.

After I renamed the “offline.php” version of index.php back to offline.php, I made the mistake of restored my original index.php. It seemed perfectly sensible, I was just undoing what I did before.  But when I refreshed the home page of my site, the offline message disappeared and left me with a completely blank page. Which scared the pants off me.  Took a while to realize what I had to do.

This is an important step. The Wizard doesn’t update the exp/index.php file. If it did, the offline message would disappear when the Wizard was done. It file has to be uploaded manually.

Glad you’ve got it up- and I tweaked the wiki to make the importance of the config.php file stand out.

I’ll also tweak the docs a bit regarding taking the system back online.  Though the updating of the index.php file is already a part of the regular update.  Note Section #2- it has you replace both index.php and the system folder (which will take care of system/index.php).  If you use the the offline file- it’s renamed index.html- so it shouldn’t replace the index.php file.

But yes- I’ll add a note about turning the system back online and moving the offline file so nobody else runs into an issue.  (Though that won’t show until we update the online docs at the next release.)

And do post back if you run into any more questions!

Oops - I confused index.php with offline.html / index.html. I don’t even have an index.html file in my /exp/ folder any more, and my offline file is offline.php - I must have renamed it that way by accident.  Whatever I did, it kept the new version of the index.php file from taking the site online during the update. 
PS Don’t want to run this into the ground - it’s rapidly becoming ancient history for me as I move on to installing CartThrob for v1.x - but when I looked again at Section 2, admin.php stood out as strange in the list of files to update. I don’t remember any such file, can’t find it anywhere, and don’t see it in my working notes.