0

I'm trying to upgrade from CiviCRM 4.7.4 to 4.7.9 for its security update. I'm doing this using 'drush' on my dev site. It seems to be hitting a couple different problems. Here's the first step:

% drush --version
 Drush Version   :  8.1.2 

% drush -vv cvup --tarfile=~/Downloads/civicrm-4.7.9-drupal.tar.gz
Executing: mysql --defaults-extra-file=/private/var/tmp/drush_I5s0Cd --database=singersin_drupal --host=localhost --silent  < /private/var/tmp/drush_yqQTCt
Executing: mysql --defaults-extra-file=/private/var/tmp/drush_Sw9qa5 --database=singersin_drupal --host=localhost --silent  < /private/var/tmp/drush_X3IP5L

The upgrade process involves - 
1. Backing up current CiviCRM code as => /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm
2. Backing up database as => /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql
3. Unpacking tarfile to => /Users/ken/Documents/SIA/server275-site/sites/all/modules/
4. Executing civicrm/upgrade?reset=1 just as a browser would.

Do you really want to continue? (y/n): y
                                                                                                                                                 [ok]
1. Code backed up.
Executing: mysql --defaults-extra-file=/private/var/tmp/drush_wbODsK --database=singersin_drupal --host=localhost --silent  < /private/var/tmp/drush_oyC1qd
Calling system(mysqldump --defaults-extra-file=/private/var/tmp/drush_UDJ4q2  singersin_drupal --host=localhost --no-autocommit --single-transaction --opt -Q  > /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql);
Database dump saved to /Users/ken/Documents/SIA/server275-site/../backup/modules/20160712223432/civicrm.sql                                      [success]
2. Database backed up.                                                                                                                           [ok]
Undefined variable: tarfile civicrm.drush.inc:368                                                                                                   [notice]
Executing: gzip -d 
Executing: tar -xf /Users/ken/Downloads/civicrm-4.7.9-drupal.tar.gz -C "/Users/ken/Documents/SIA/server275-site/sites/all/modules/"
3. Tarfile unpacked.                                                                                                                             [ok]
4.                                                                                                                                                  [notice]
You are already upgraded to CiviCRM 4.7.4
                                                                                                                                                 [completed]
Process completed.
Command dispatch complete                                                                                                                           [notice]

First, notice the "Undefined variable: tarfile" in the output. I think that's because of this code in civicrm.drush.inc:

function _civicrm_extract_tarfile($destinationPath, $option = 'tarfile') {
  $tarpath = drush_get_option($option, FALSE);
  if (drush_shell_exec("gzip -d " . $tarfile)) {
    $tarpath = substr($tarfile, 0, strlen($tarfile) - 3);
  }
  drush_shell_exec("tar -xf $tarpath -C \"$destinationPath\"");
}

There are 3 instances of $tarfile that should be $tarpath, right?

The next problem is that it can't recognize the version it's trying to upgrade to - it says "You are already upgraded to CiviCRM 4.7.4", when trying to upgrade to 4.7.9. I'm guessing that's because the code was originally loaded when 4.7.4 was installed, so it would need to re-load itself somehow to detect that it's out of date.

Okay, no problem, I figured I could just run drush cvupdb separately. However, this fails with a database error:

% drush cvupdb
PEAR_Exception: "DB Error: unknown error"
 * ERROR TYPE: DB_Error
 * ERROR CODE: -1
 * ERROR MESSAGE: DB Error: unknown error
 * ERROR MODE: 16
 * ERROR USERINFO: ALTER TABLE `civicrm_contact` CHANGE `image_URL` `image_URL` VARCHAR(512) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL COMMENT
  'optional URL for preferred image (photo, logo, etc.) to display for this contact.'
  [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
 * ERROR DEBUGINFO: ALTER TABLE `civicrm_contact` CHANGE `image_URL` `image_URL` VARCHAR(512) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL DEFAULT NULL COMMENT
  'optional URL for preferred image (photo, logo, etc.) to display for this contact.'
  [nativecode=1071 ** Specified key was too long; max key length is 767 bytes]
 ...

My database is MySQL version 5.6.27, is that problematic? What's a next step?

Thanks.

3

I ran into a similar problem when manually updating. Depending on how your database is configured the update will fail when trying to change the image_URL from VARCHAR(256) to VARCHAR(512). I wasn't able to figure out how to get it to let me make the change (it would even fail when I tried to directly manipulate the table). I ended up commenting out this line of the SQL update and everything ran just fine.

If I were you I would just do a manual update of CiviCRM.

You can comment out the SQL line in this file: sites/all/modules/civicrm/CRM/Upgrade/Incremental/sql/4.7.8.mysql.tpl

Just be sure to backup your DB before doing this.

mysqldump -u user -p mycividb > mycividb-backup.sql

I hope this helps!

  • The issue here is character encoding. If your character encoding is latin1, each character is 1 byte - so you can do VARCHAR(767) and not go over InnoDB's "767 characters per column" limit. By comparison, UTF8 has a variable number of bytes per character - up to 3 bytes. So you can't go above VARCHAR(255). – Jon G - Megaphone Tech Jul 14 '16 at 15:52
  • That's really good to know. Is it recommended to set the character encoding to latin1? I have always done UTF8_unicode_ci... – Sleewok Jul 15 '16 at 19:05
  • This doesn't seem like a good idea, since it will leave the database with a schema different from what's expected and could very well fail in the next schema update. – Ken Williams Jul 19 '16 at 0:11
  • 1
    I looked at github.com/civicrm/civicrm-core/pull/8605 and they solve it by redefining the civicrm_contact.index_image_url index to be length 128. I'm assuming this is going to make it into version 4.7.10, so this is the solution I went with. – Ken Williams Jul 19 '16 at 1:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.