Contents
Upgrading from CiviCRM 1.9 to 2.0
CiviCRM is a major new release. It makes important changes to the database.
Be very careful if upgrading from CiviCRM < 1.9. See: http://wiki.civicrm.org/confluence/display/CRMDOC/Upgrade+Drupal+Sites+to+2.0
- we ran into a "consistency error" with MUHCF.
Activate debugging and backtracing before upgrading. If it crashes during the upgrade, at least you will know where. It makes it easier to resume the installation if necessary. (CiviCRM > Admin > Global conf > Debugging)
- In the CiviCRM dump, make sure that all tables specify their collation upon creation:
Database Error Code: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=', 1267 Array ( [callback] => Array ( [0] => CRM_Core_Error [1] => handle ) [code] => -1 [message] => DB Error: unknown error [mode] => 16 [debug_info] => UPDATE civicrm_activity ca LEFT JOIN civicrm_option_value ov ON (ov.option_group_id = @og_id_as AND ov.label = ca.status) SET ca.status_id = ov.value [nativecode=1267 ** Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='] [type] => DB_Error [user_info] => UPDATE civicrm_activity ca LEFT JOIN civicrm_option_value ov ON (ov.option_group_id = @og_id_as AND ov.label = ca.status) SET ca.status_id = ov.value [nativecode=1267 ** Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '='] [to_string] => [db_error: message="DB Error: unknown error" code=-1 mode=callback callback=CRM_Core_Error::handle prefix="" info="UPDATE civicrm_activity ca LEFT JOIN civicrm_option_value ov ON (ov.option_group_id = @og_id_as AND ov.label = ca.status) SET ca.status_id = ov.value [nativecode=1267 ** Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=']"] )
- Check that there are no: "SELECT * FROM civicrm_custom_field WHERE name IS NULL;" otherwise step5 causes fatal error.
Check that no civicrm_custom_field has a name that is a special SQL keyword: "name, database, etc.": "SELECT id,name FROM civicrm_custom_field;" Bug submitted: http://issues.civicrm.org/jira/browse/CRM-2912
- If you are using Drupal modules that insert custom activity types in CiviCRM, read the warning in the CiviCRM upgrade notes.
See also API thread on the forum: http://forum.civicrm.org/index.php/topic,3008.0.html
http://svn.civicrm.org/civicrm/branches/v2.0/test-new/SimpleTest/api-v2/
Upgrading from CiviCRM 2.0 to 2.1
run db integrity tools: http://wiki.civicrm.org/confluence/display/CRMDOC/Database+Troubleshooting+Tools (also can repair)
Upgrading from CiviCRM 3.0 to 3.3
- run this before starting the upgrade:
ALTER TABLE civicrm_domain ADD `locale_custom_strings` text COLLATE utf8_unicode_ci COMMENT 'String Overrides';
- remove that statement from CRM/Upgrade/Incremental/sql/3.2.alpha3.mysql.tpl
- run the upgrade ("drush civicrm-upgrade-db")
Bout de code perdu (à replacer?) :
INSERT INTO civicrm_option_value (option_group_id, label_en_US, label_fr_FR, description_en_US, description_fr_FR, value, name, weight, filter, is_reserved) VALUES ( @option_group_id_activity_type, 'Inbound Email', 'Inbound Email', 'Inbound Email.', 'Inbound Email.', (SELECT @max_val := @max_val+1), 'Inbound Email', (SELECT @max_wt := @max_wt+1), 1, 1)
Mise à jour de 3.x à 4.1.x
Avec Aegir et provision-civicrm, éventuellement, tout devrait être automatique. Pour l'instant voici une procédure manuelle en cas de problème :
- S'assurer que civicrm.settings.php est correct :
- define( 'CIVICRM_UF' , 'Drupal6' );
- les urls sont bons (inclus le path vers la nouvelle plateforme et non l'ancienne)
les données de connexion à la db sont corrects (faire drush sql-connect pour être certain.
- faire un backup de la base de données
faire drush civicrm-upgrade-db - si ça ne fonctionne pas, voir ci-dessous "Problème..."
supprimer template_c et ConfigAndLog
rm -rf files/civicrm/templates_c rm -rf files/civicrm/ConfigAndLog
faire drush civicrm-update-cfg en fait ne fonctionne pas : http://issues.civicrm.org/jira/browse/CRM-10319 d'où l'étape suivante ou bien la pertinence de vérifier manuellement les URLs suivants :
civicrm/admin/setting/updateConfigBackend&reset=1 (configuration des chemins)
civicrm/menu/rebuild&reset=1 (reconstruction du menu)
aller dans la db et faire select * from civicrm_setting where value like '%ANCIEN_PATH%' notamment s'assurer que uploadDir, imageUploadDir et customFileUploadDir sont corrects (sinon, c'est préfèrable de vider les valeurs parce qu'il s'agit de variables sérialisés ce qui leur modification rends un peu pénible)
charger la page monsite.com/civicrm - si ne marche pas, faire
drush cc all rm -rf files/civicrm/templates_c rm -rf files/civicrm/ConfigAndLog
et recharger la page (voir dans admin/reports/dblog pour identifier les problèmes s'il y en a)- quand tout fonctionne, faire un verify et s'assurer que tout continue de fonctionner normallement
- penser à configurer le cron : crontab à changer et page de configuration dans civicrm (activer envoi de courriel et mise à jour du statut de membres au moins)
- certains widgets du dashboard peuvent cesser de fonctionner
Problème lors de la mise à jour de la base de données
Le script plante en cours de mise à jour et vous obtenez un message d'erreur du genre :
Drush command terminated abnormally due to an unrecoverable error. [error] <p>backTrace</p><p><pre>/srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/CRM/Core/Error.php, backtrace, 146 , handle, /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/packages/PEAR.php, call_user_func, 931 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/packages/DB.php, PEAR_Error, 968 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/packages/PEAR.php, DB_Error, 564 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/packages/DB/common.php, raiseError, 1903 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/packages/DB/mysql.php, raiseError, 898 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/packages/DB/mysql.php, mysqlRaiseError, 327 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/packages/DB/common.php, simpleQuery, 1216 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/CRM/Utils/File.php, query, 274 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/CRM/Upgrade/Form.php, sourceSQLFile, 155 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/CRM/Upgrade/Form.php, source, 297 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/CRM/Upgrade/Form.php, processLocales, 323 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/CRM/Upgrade/Incremental/php/FourOne.php, processSQL, 76 /srv/aegir/platforms/civicrm-d6-4.1.3-build-2012.07.05-production/sites/all/modules/civicrm/CRM/Upgrade/Page/Upgrade.php, upgrade_4_1_alpha1, 290
Une façon de trouver le problème :
- aller voir le fichier CiviCRM/CRM/Upgrade/Incremental/sql/4.1.alpha1.mysql.tpl (le fichier qui a planté)
- vérifier la base de données par rapport au mise à jour du fichier pour trouver la cause exact du problème (plus rapide par dichotomie - d'abord au milieu du fichier puis milieu de la 1ère moitié ou de la 2ème moitié, ...)
- lorsque la ligne est identifié, essayer de trouver la cause (probablement une ancienne mise à jour qui s'est mal passé ou une corruption de la base de données)
supprimer toutes les tables de civicrm (commençant par civicrm_), reprendre le backup initial, corriger le problème (vous pouvez relancer la mise à jour sur une ancienne version en changeant la version dans la table civicrm_domain). Ensuite, relancer drush civicrm-update-db
Tester la mise à jour manuelle dans le contexte Aegir
- Faire un clone du site dans la même plateforme que le site original ex: monsiteclone.site.koumbit.net
- Faire un backup de la base de données
- Supprimer le site cloné avec Aegir
- Créer un nouveau site avec le même nom que le site cloné dans la plateforme destination (avec la nouvelle version de CiviCRM) : monsiteclone.site.koumbit.net
Charger le backup mysql dedans manuellement (drush sqlc < db.sql)
- Copier les fichiers (themes, modules, files, libraries) à partir du site original
- Vider les cache : drush cc all
- Lancer un verify
- Tester la migration : drush cvupdb