 | Upgrade Instructions Only This page provides instructions for Upgrading CiviCRM installations on Drupal from version 1.9 to 2.0.x.
|
 | Version 2.0 Requirements Before beginning this upgrade, verify that your server meets the requirements for CiviCRM 2.0.
|
 | Upgrade a Copy of Your Site First and Make a Complete Backup
We strongly recommend that you create a copy of your existing site (directories and database) - and upgrade that copy first in order to make sure you can complete the upgrade successfully. In any case, you should create a full backup of the installed civicrm directory tree and civicrm database before beginning the upgrade process.
If you are upgrading a COPY of your production 1.9 site - make sure the site you are about to upgrade is a fully functioning 1.9 installation before you begin the upgrade process. (more info...) |
Step-by-step Upgrade Procedures
1. Download the v2.0 CiviCRM Package
2. Login to Drupal with administrator-level permissions
 | You must stay logged in to Drupal during the remaining steps in this process. Logging off and trying to log back in while CiviCRM is partially upgraded may result in fatal errors trying to access your Drupal site. |
3. Take the Site Offline (for production site upgrades)
When upgrading a production site, it is recommended that you take your site offline during the upgrade process.
Administer » Site Configuration » Site Maintenance
4. Rebuild your 1.9 Database to Ensure Schema Integrity
 | If your 1.9 database has been upgraded from a prior version - and you did not previously run these steps - you must complete the steps in this section in order to prevent errors during the upgrade to 2.0. |
- Create a new empty database. We'll call it civicrm19Fix for this example.
- Load the 1.9 table structure into this new database by sourcing civicrm/sql/civicrm_41.mysql (in your existing 1.9 codebase).
shell > mysql -u crm_db_username -pcrm_db_password civicrm19Fix < civicrm_41.mysql
- Dump the data ONLY from your existing 1.9 database to a file:
shell > mysqldump -u crm_db_username -pcrm_db_password -c -e -n -t civicrm19 > dumpFile
- Populate the new empty database with your data by sourcing the dumpFile from step 3:
shell > mysql -u crm_db_username -pcrm_db_password civicrm19Fix < dumpFile
- Don't forget to edit the CiviCRM Database your civicrm.settings.php file to point to the newly-prepared database!
- This file should be located in <drupal_root>/sites/default.
define( 'CIVICRM_DSN', 'mysql:
 | Migrating Activity History Records from 3rd Party Modules or with Types missing from current Activity Types list If your CiviCRM installation includes integration with other Drupal modules which have inserted Activity History records, or if - perhaps due to activity types having been renamed - there are Activity History records having types not in the current Activity Types list, and you want to retain these records - please refer to this document before continuing the upgrade. You can check for such records with the following SQL query:
SELECT DISTINCT(activity_type) FROM civicrm_activity_history
WHERE activity_type NOT IN (SELECT label FROM civicrm_option_value WHERE option_group_id = 1)
|
5. Backup and then delete all 1.9 code files
CiviCRM will not run properly if 1.9 files are present after the upgrade. Make sure you have a good backup of your complete 1.9 installation and then delete all files and directories from your <drupal_root>/modules/civicrm or <drupal_root>/sites/all/modules/civicrm directory tree.
 |
Be sure that your backup copy of the previous version codebase is NOT located below the <drupal_root>/modules or <drupal_root>/sites/all/modules directory. For example, placing your codebase backup in <drupal_root>/modules/civicrm.bak... will cause errors (Drupal executes any *.module files that are found in the modules or sites/all/modules directory tree). |
6. Unpack the 2.0 package
Unpack the 2.0 files into the (now empty) <drupal_root>/modules/civicrm or <drupal_root>/sites/all/modules/civicrm directory.
cd <drupal_root>/sites/all/modules
tar -xzf civicrm_download_file.tgz
7. Run the Database Upgrade script
This step is required for ALL upgrades.
 | MySQL 4.0 and 4.1 are Not Supported Support for MySQL versions 4.0 and 4.1 has been discontinued. This means that you may encounter various issues and/or unexpected behavior if you atempt to run CiviCRM under these versions, and the CiviCRM engineering team will not provide support for debugging or resolving these issues. You are strongly encouraged to upgrade to the current generally available release of MySQL. |
 | Upgrading From Versions Prior to 1.9 If you are upgrading from 1.8 or earlier versions, you will need to run the database upgrade procedures in sequence. However you do not need to install intermediate codebase versions. Upgrade scripts for prior versions are included in the 2.0 download, and instructions are here. |
- Point your web browser to the following URL (you should already be logged in to Drupal with administrator-level permissions):
http://<your_drupal_home>/index.php?q=civicrm/upgrade&reset=1
- You should see the CiviCRM 2.0 Upgrade: Step One screen.
- Click Begin Upgrade.
- There are six steps to the upgrade. Click Continue for each step. You will see an Upgrade Successful screen when the process is completed.
- You must complete all steps in order to have a valid 2.0 database. If you receive any errors during the process, please note down the exact step and error message, and check for solutions on the community support forum. Note: If you experience any foreign key errors on the upgrade, make sure you follow Step 4 above.
8. Delete all records from Drupal's session table (drupal.sessions)
Using command prompt:
1. shell > mysql -u drupal_user -h drupal_db_server -pdrupal_password drupal_db
2. mysql> use drupal_db; (just to make sure right db is used)
3. mysql> TRUNCATE TABLE sessions;
If you are using phpMyadmin:
1. Click the SQL tab for your Drupal database.
2. Type "TRUNCATE TABLE sessions;" and click Go.
- This step is recommended to prevent session corruption issues.
Coming from an older install I had to NULL civicrm_domain
Todo this I used phpmyadmin, browse and then edit the ONE entry in here. Then I clicked the check box NULL next to config_backend. The reason I knew this is past problems that left and old Smarty path pointing to /opt/. Overall this does not hurt since it refills itself based off of code and/or settings in CiviCRM
9. Reload Drupal Modules and Reset Drupal Menus
- Log in to the upgraded site with your Drupal Administrator login. (If you took the site offline earlier, you'll need to go to http://<yourSiteDrupalRoot>/user to be able to log in again.)
- Go to Administer » Site Building Modules.
- Check whether the send module is installed. If so, uninstall it, because send is incompatible with CiviCRM 2.0. You can replace it with the forward module to provide send to a friend functionality.
- Make sure CiviCRM is enabled (CiviCRM is listed under "CiviCRM").
- Click Save configuration at the bottom of this form (this lets Drupal find the new location of civicrm.module).
- Go to Administer » Site Building » Menus » Settings.
- Click Save configuration at the bottom of this form (this will rebuild the site menus).
10. Reset Your User Session and Cleanup Template Cache
- Temporarily enable CiviCRM debug features:
- Go to Administer CiviCRM » Global Settings » Debugging
- Set Enable Debugging to Yes and click Save.
- Click the Administer CiviCRM menu (or any other CiviCRM menu item). After the page is loaded, add two additional query string values (sessionReset=2&directoryCleanup=1) to the URL in your browser's location bar, and reload the page. (You may see a large number of missing file warning messages on your screen - depending on how your Drupal Error Reporting option is configured. These are expected and will disappear on the next page request.)
- Now reset Enable Debugging to No and click Save.
 | Do Not Leave Debug Features Enabled for a Public Site Debugging should be disabled for publicly available sites as it may allow browsers to view system configuration information. |
11. Verify and Update Resource URL Settings
If you are running this installation in a different directory from your 1.9 site you will probably need to update the configured CiviCRM Resource URL (Missing icons and images, as well as problems with javascript functions and stylesheets are all symptoms that this setting needs to be updated.)
- Go to Administer CiviCRM » Global Settings » Resource URLs
- Refer to the field help on this screen for instructions.
12. Update PayPal Processor Settings
 | This step is required if you are using PayPal Pro and/or PayPal Express. Otherwise, continue with the next step. |
Navigate to Administer CiviCRM » Global Settings » Payment Processors and Edit your PayPal processor settings. Verify the values of BOTH the Site URL and API URL fields:
13. Enable Components
If you plan on using any components that you weren't using in the prior version (e.g. CiviGrant for grant management) - you'll need to enable these component(s):
- Go to Administer CiviCRM » Global Settings » Enable Components
14. Review and Update Access Control Settings
- It's a good idea to verify Drupal role-based permissions which were added in recent releases. You can review and update these at Administer » User Management » Access Control:
- access CiviMail subscribe/unsubscribe pages : Enable this permission for the anonymous user role if you want any contact in your database to be able to subscribe to public "Mailing List" groups from http://<drupal_site>/civicrm/mailing/subscribe?reset=1 AND to unsubscribe by clicking a web-link in your mailings.
- view event participants : If you want to allow some constituents to see a list of registered participants for a given event at http://<drupal_site>/civicrm/event/participant?id=N&reset=1, then enable this permission for the appropriate Drupal role(s).
- access all custom data : You must enable this permission for any role which you want to view or edit custom data fields. EXAMPLE: If your site uses Profile(s) which include custom fields - make sure the role(s) that need to access these Profiles have this permission.
- access Contact Dashboard : You can now provide authenticated users with access to a screen where they can review their subscribed groups, contributions, memberships and event registrations (as applicable). Enable this permission for role(s) for which you want to provide this feature.
- access CiviEvent : If you plan to use CiviEvent, enable this permission for role(s) which will be creating and managing Events and Event Participants.
- register for events : If you plan to use CiviEvent and want to allow online event registration - enable this permission. Be sure to assign this permission for the "anonymous" role if you want to allow un-authenticated visitors to register for events.
15. Put the Site Online (for production site upgrades)
- Toggle the following feature, and put your site back online:
**Administer » Site maintenance* (In Drupal 5, this is in "Admin » Site Configuration » Site Maintenance")*
- Review Your Upgraded Site
- Verify that your data is intact.
- Check out the new features and improvements. A summary of the cool new stuff can be found here.
Upgrade Trouble-shooting
Check this section for answers to upgrade problems. If your problem isn't addressed here, check out the Installation and Configuration Trouble-shooting page for additional resources.
Verify and Update Configuration Settings File
CiviCRM v2.0 stores most configuration settings in the database. However values needed to load the code and database are stored in the settings file and will need to be updated prior to beginning the upgrade process if you are upgrading a copy of your working 1.9 site:
<drupal_root>/sites/xxx/civicrm.settings.php.
- Open civicrm.settings.php with your favorite editor and verify or update the following values:
- $civicrm_root : If you are running this installation in a different directory from your 1.9 site, update this setting with the new path.
- CIVICRM_TEMPLATE_COMPILEDIR : If you are running this installation in a different directory from your 1.9 site, update this setting with the new path.
- CIVICRM_UF_BASEURL : If the Drupal URL for this site is different from your 1.8 site, update this setting with the base URL for your Drupal home page.
- CIVICRM_UF_DSN : If this install will be using a different database for Drupal, update this setting.
- CIVICRM_MYSQL_VERSION :
define( 'CIVICRM_MYSQL_VERSION', 5.0 );
- CIVICRM_DSN : This setting must contain the correct information for your 2.0 database. If you are upgrading a copy of your 1.9 database that has a different database name - you will need to change the civicrm_db portion of the setting below. Also review the other values to make sure they are correct for the database that will be used for 2.0.
define( 'CIVICRM_DSN', 'mysql:
A fatal error appears when I try to load a CiviCRM page.
Fatal error: civicrm_initialize() [CRM:function.require]: Failed opening
required 'CRM/Core/Config.php' (include_path='.:/opt/local/lib/php')
in <drupal root>/modules/civicrm/modules/civicrm.module on line 206
This error likely indicates that the new CiviCRM configuration file is not in the expected location or that the $civicrm_root setting is incorrect. See step 3 above.
Foreign Key Errors or Warnings During the Database Upgrade
Foreign keys may have been assigned different names on some installations. Also, different versions of MySQL handle the dropping and adding of constraint checks differently. Try this procedure (or follow Step 4 from above) to reload your data into a new 1.9 database structure if you are having this type of issue with upgrading your database.
Errors Using PayPal Pro or PayPal Express for Contributions or Event Registration
If you are using PayPal Pro or PayPal Express and are getting the following type of error when submitting a contribution or event registration, then you'll need to verify / update your Payment Processor settings.
Payment Processor Error message
6:Couldn't resolve host 'nvp'
Navigate to Administer CiviCRM » Global Settings » Payment Processors and Edit your PayPal processor settings. Verify the values of BOTH the Site URL and API URL fields:
Calendar widget doesn't work (throws a Javascript error), and/or CiviMail scripts for open tracking, SOAP authentication, etc. don't function.
If your CiviCRM codebase is NOT located in either <drupal root>/modules/civicrm or <drupal root>/sites/all/modules (i.e. you are using a symlink from there to your codebase) - you will need to create a local file in the top-level directory of your codebase which points to the location of your drupal sites directory.
<?php
define( 'CIVICRM_CONFDIR', '/home/lobo/public_html/drupal/sites' );
?>
Access Forbidden (403) Error After Upgrade
This may be caused by directory permission settings. Make sure your <drupal_root>/files/civicrm directory is set with chmod -R 777 ./*
If you're still getting this error and have clean URLs enabled, try disabling clean URLS (Drupal >> admin >> settings) prior to running the session reset and cleanup (step 8 above). Then re-enable clean URLs.
Having an error in step 5? There's a forum entry on this.
Apparently what has happened is that names for custom items have become "NULL".
Go in and add names for them. This is easily done through PHPMyAdmin.
Once I did this, the upgrade ran fine.
Looks like the same is true for the 'name' column of the civicrm_groups table.
Having now upgraded to 2.0 more than a dozen installations from versions as early1.4, I've learned a few things worth knowing:
- Every upgrade is different. Be prepared to not get it right the first time. Expect to troubleshoot. Expect to clean up data with phpMyAdmin.
- After step 4 above, and making sure all your custom fileds & groups have a valid 'name' value, make a fresh mysqldump of your database, so you can quickly DROP, CREATE, SOURCE, and start over.
- Some times errors are seemingly random. I've had the exact same database fail at a completely different steps in the upgrade process, with no difference between the two attempts. My best guess is that mysql gets backlogged with queries, and the upgrade script gets ahead of the actual database. I've made a habit of running a console window with 'top' while doing the upgrade, and I never click 'Continue' for the next step until I see that mysqld is no longer showing in top.
- You'll get warned about some invalid custom_field names. Another term to avoid is 'match'.
- When you get FK errors that won't go away, look for IDs = 0 in the problem table. Deleting these has solved errors for me. If you can write a SELECT statement with a LEFT JOIN for the columns that are being keyed, this can be a big help in finding problem rows; just look for joined columns showing NULL.
- Sometimes I've been warned about 3rd Party Activity records when there were none. I don't know why this warning is triggered, but it seems it can be safely ignored if you don't think you have any third party activity records you want to preserve.
Updated by Dave Jenkins
May 06, 2008 16:21
- Same here. I've just encountered this upgrading a db where no 3rd party apps were used. The problem seems to be inconsistency in the activity_type stored in civicrm_activity_history: the db has over 5000 records with type 'Email Sent' and 31 with type 'Email', but civicrm_option_value has only 'Email'. Similarly civicrm_activity_history has records of type 'Event Registration' but civicrm_option_value has only 'Event'.
I'm not sure how this occurred. The db started life in Civi 1.4 . I couldn't rule out that the client has changed activity type labels in Civi admin; certainly they have added new ones.
Here's a query to identify any problematic activity types:
I resolved the problem by making the civicrm_activity_history records consistent with the civicrm_option_value activity types, e.g.:
The upgrade procedure now completes but much of the activity details have been lost: most dates are now NULL and most view links for activities are broken. So maybe don't do what I did. The fix for CRM-2914 does not resolve this - I tested with 2.0.3, same issue.
I frequently need the v1.9 schema file when upgrading earlier version to v2, and get annoyed that it isn't included in the 2.0 package. So here it is for easy access for all:
[http://www.NinjitsuHosting.com/files/civicrm_41.txt]
If anyone needs assistance with an upgrade, my company is available for hire. matt[at]NinjitsuHositng [d0t] com
Thanks for the Schema file above. I followed along only to realize that the civicrm_41.mysql from 1.8 was not working so I had to find an older site using 1.9.
The sites I use need civinode.
I noticed that going from 1.9 to 2.0 is breaking it in two ways.
1. civinode needs dojo the new civicrm2.x does not have what it needs (that I could find) so I take one file and one folder and place it in the right place
and dojo works again. More details below.
2. civinode just breaks anyways (maybe this should be one) but with some work and an extra module it will work again. More below
So I placed the how to on my site so I could also attach the files.
http://www.rivervalleytechcollective.org/civicrm_2_fixes\\