Thread

This question may be related to a resolved thread.

First, got the error about show_sidebar so I followed the tips at the thread above to comment out the troubled lines. Now getting an error that the field can_edit_html_buttons doesn’t exist.

Is there an upgrade/install script that simply works? Since the EE 2.10 schema is a known entity, and 2.2’s schema is a known target, I don’t understand how/why there are any issues like this.

Update - restored everything (files and DB) and tried again (after commenting out the “ALTER TABLE exp_members ADD show_sidebar ” line) and now it’s stuck on a continuous cycle on step 2.1.2.

hi openmotive,

We have an article on Troubleshooting Upgrade Errors

Regarding restoring your DB and fields can you refer to this portion of that article

Is this exactly what you done in your retry?

I came across that article (it should really be linked from the main upgrading docs…I only found it because you had posted the link for someone else) and made sure I was starting completely clean (deleted database entirely, create new DB, migrate copy of the current live DB, restored all original files, followed the upgrade instructions to prepare system, themes, etc.) Ran the installer, and again got the following error:

Error Number: 1060
Duplicate column name ‘show_sidebar’
ALTER TABLE exp_members ADD show_sidebar char(1) NOT NULL default ‘y’ AFTER quick_tabs
Filename: updates/ud_212.php

Next Steps
- I deleted the database. Restored.
- Deleted all files, restored and prepared for 2.2 per the upgrade instructions.
- Made certain that config.php and database.php were perfectly formatted EE config files (no customization)
- Commented out the line in 212 that creates show_sidebar, and got a new error.

Error Number: 1060

Duplicate column name 'can_edit_html_buttons'

ALTER TABLE exp_member_groups ADD can_edit_html_buttons char(1) NOT NULL DEFAULT 'n' AFTER can_view_profiles

Filename: updates/ud_212.php

Line Number: 52

Next Steps:
- Again, I deleted the database. Restored it.
- Deleted all files, restored and prepared for 2.2 per the instructions
- Commented out the ‘show_sidebar’ line as well as the line that creates ‘can_edit_html_buttons’ and got a new error.

Error Number: 1060

Duplicate column name 'm_field_cp_reg'

ALTER TABLE exp_member_fields ADD m_field_cp_reg char(1) NOT NULL default 'n' AFTER m_field_reg

Filename: updates/ud_212.php

Line Number: 53

Next Steps:
- I deleted the database. Restored it.
- Deleted all files, restored and prepared for 2.2 per the instructions
- Commented out the ‘show_sidebar’ line, the line that creates ‘can_edit_html_buttons’, and the line that creates “m_field_cp_reg” and got a new, raw error without any formatting:

{"error":"

Error Number: 1054<Vp>/n/n

Unknown column 'can_edit_html_buttons' in 'field list'<Vp>\n\n

UPDATE exp_member_groups SET can_edit_html_buttons='y' WHERE can_access_cp = 'y'<Vp>\n\n

Filename: updatesVud_212.php<Vp>\n\n

So even though leaving the line to add the can_edit_html_buttons yields an error that field already exists, commenting out that line yields an error that the field doesn’t exist.

I’m at a loss. Our new project for this client will rely on Safecracker and not being able to upgrade is not only a showstopper for the new project, but is making them question my push for them to build their site using ExpressionEngine in general. If you’ve got any ideas on how to get past this hump, I’m all ears and really appreciate it.

Hi openmotive,

Believe me, I COMPLETELY understand you’re frustration here. The upgrade shouldn’t be this troublesome.

Here’s the core issue with your upgrade. Even though you’re wiping the database properly now, it appears that your backup of the 2.1.0 installation also includes tables, columns, etc. that shouldn’t be added to the database until 2.1.2. I can tell because that’s the upgrade file where your upgrade keeps failing (updates/ud_212.php).

Do you recall running the Upgrade Wizard and seeing it fail sometime before you made the backup you’re using now?

This will be an arduous process, but rather than comment out the lines that give errors and repeating the process, instead make a note of the offending database table, column, etc. and remove it from the database after restoring the backup and before running the Upgrade Wizard again. Does that make sense?

Thanks Keven!

It does make sense, and I thought of that the other day.

This site was originally built on 2.0 and upgraded to 2.1 during development, prior to launch. So it has gone through a successful upgrade process before. I do not recall any issues during that upgrade.

However, the fields that are being mentioned in the errors definitely don’t exist in the 2.1 database. After we attempt an upgrade and receive an error, they are there, but not before.  So it seems as if they may be getting added earlier in the upgrade process (prior to the 212 file)?

Hmm… then perhaps the 2.1.2 part of the upgrade is getting looped. What browser are you using to perform the upgrades? I’m thinking the browser might be restarting a connection when it appears to be about to time-out, causing that part of the script to restart. We’ve heard reports that Firefox does this. If you’re using FF, could you try using Safari or Chrome?

We’ve been using Safari 5.1 running on Lion.

During one attempt (when I was commenting out those lines in 212.php) it did get stuck in an endless loop on 212.

Hmm… with Safari 5.1 as new as it is, and having seen more than a few bugs in it, let’s try a few things to work around that.

1) Try upgrading with Chrome instead. If that doesn’t work,

2) Upgrade using Chrome again, but disable JavaScript before you load up the Upgrade Wizard.

If the Upgrade Wizard still loops on updates/ud_212.php after that, we’ll get in there first-hand to see what’s happening.

Still getting stuck on ud_212.php with chrome and chrome without javascript.

In the end, the client has opted for this project running on a separate installation in order to keep things moving. So we started moving forward on a fresh 2.2 install and will put this (internal corporate) project on a separate subdomain.

So, while not solved, we have a workaround in that and will most likely not be attempting to upgrade their main site.

I’m sorry we weren’t able to help fully troubleshoot this with you. Be on the lookout for an email from me, I need to ask you something in private.

Other than that, is there anything else I can help you with? Would you like us to continue helping troubleshoot this issue?

Looks like this could’ve been the result of a previous botched upgrade where the database wasn’t cleaned before trying again. openmotive and their client have found a solution by going with a fresh install, so I’m closing this one out!