Updating the panels module from version 3.3 directly to version 3.6 results in a problem during the database updating process. Error "Unknown column 'storage_type' in field list" is thrown during panels_update_7302, probably because the panel display methods used there already work with the storage_type while it is not existent until panels_update_7305.
Possible solutions for the user at the moment:
Either install update by update instead of skipping 3.4 and 3.5 (version 3.5 is sufficient) or manually set the schema_version of panels to 7302 in the system-table, run update.php, switch back to 7301 (or 0) and run update.php again.
PS: panels_update_7305 is missing a db_field_exists check, I had to add it to avoid an error when running the update multiple times.
Comment | File | Size | Author |
---|---|---|---|
#11 | panels-update-fix-2786073-11.patch | 977 bytes | dsnopek |
Comments
Comment #2
Martin Schauer CreditAttribution: Martin Schauer commentedComment #3
dsnopekComment #4
ericjenkins CreditAttribution: ericjenkins at Exel Digital for Promet Source commentedI encountered the same error when upgrading from 3.3 to 3.6.
Uploaded patch #4 for addressing the db_field_exists check that was pointed out by @Martin Schauer . Please let me know if this looks appropriate.
After updating code to version 3.6, apply the patch and then run the following drush commands in order:
Comment #5
bcobin CreditAttribution: bcobin commentedThanks - you're a lifesaver!
Comment #6
pmkanse CreditAttribution: pmkanse commented+1
Comment #7
lstoetzel CreditAttribution: lstoetzel commented+1 to #4, fixed it for me
Comment #8
malcomio CreditAttribution: malcomio at Capgemini commentedHere's a patch that seems to work without needing the extra drush commands, although it needs more testing.
Comment #9
malcomio CreditAttribution: malcomio at Capgemini commentedThinking about it, here's a cleaner, DRY-er version.
Comment #10
malcomio CreditAttribution: malcomio at Capgemini commentedComment #11
dsnopek@malcomio: Thanks for the patch! I agree with the DRY-ness of it, but here's a different form that keeps the code looking similar to it's current state and solutions to the same problem in the past.
Comment #13
japerryThis is fixed.. for now. However, we may need to address the core issue that is causing this problem, see #2787123: Re-write panels_update_7302() to not call panels_save_display() for more info.
Comment #15
webatelier CreditAttribution: webatelier commentedhow do i apply this patch when allready updated to 3.7 ?
can i patch 3.7 or do i reverse to 3.6, patch and then update (since 3.7 has solved critical vulnerabilities ...
Comment #16
alek123 CreditAttribution: alek123 commentedIf you have access to MySQL and you have Panels 3.6 (patched) or 3.7... you can run:
UPDATE `databasename`.`system` SET `schema_version` = '7304' WHERE `system`.`filename` = 'sites/all/modules/panels/panels.module';
Then go to update.php
Alek