Civicrm 5.5 upgrade: Difference between revisions
m (→Upgrading: markup tweaks) |
|||
Line 134: | Line 134: | ||
I'm told | I'm told | ||
<nowiki>System Status: Error | <nowiki> | ||
System Status: Error | |||
Cron Not Running | Cron Not Running | ||
Remote Profiles Enabled | Remote Profiles Enabled | ||
Line 177: | Line 178: | ||
text | text | ||
:<nowiki>{ts}Please print this confirmation for your records.{/ts}</ | :<nowiki>{ts}Please print this confirmation for your records.{/ts}</nowiki> | ||
Finally | Finally | ||
<nowiki>git add sites/all/modules/civicrm | <nowiki> | ||
git add sites/all/modules/civicrm | |||
git commit -m "upgraded civicrm" | git commit -m "upgraded civicrm" | ||
git gc # for good measure | git gc # for good measure | ||
</nowiki> | </nowiki> |
Latest revision as of 12:51, 20 September 2018
System requirements
Our hosting provider recently upgraded servers to debian 9, which had the side effect of upgrading php5 to php7. Our version of civicrm turns out not to be compatible with php7, meaning that it's time to upgrade.
Civi doesn't quite support Drupal 8 (yet), but still supports drupal 7. So, we're okay staying with drupal 7.
The 4.6.x series of Civicrm is compatible with php 5.6, but not php 7.0. Php 7.x compatibility requires civicrm 5.x. So, we'll opt for the current 5.x release (5.5.1, as of this writing), for Drupal 7.
See https://docs.civicrm.org/sysadmin/en/latest/requirements/ for a list of system requirements.
Upgrading
https://docs.civicrm.org/sysadmin/en/latest/upgrade/ lists general requirements for upgrading. Normally, I would absolutely agree with the idea of doing a dry run upgrade on a test copy of the site. However, because Civic 4.x doesn't run at all under php 7, we have nothing to lose by doing the upgrade on a live site.
Of course, we will take backups first.
The drupal 7 specific upgrade instructions are here: https://docs.civicrm.org/sysadmin/en/latest/upgrade/drupal7/
Civi was not our drupal home page, so nothing to do there.
We weren't using an Civi modules, so nothing to disable.
Backup the database, as one would normally do.
Run "git status" to make sure the filesystem is clean (no outstanding changes). This effectively provides a restore point for the web site files.
The instructions state that one should log into drupal before starting the upgrade process. Unfortunately, the php version incompatibility prevents me from doing that. Oh well.
Move directories around and unpack code
mv sites/all/modules/civicrm/ ~/civicrm.PREV cd sites/all/modules tar -zxpvf ~/civicrm-5.5.1-drupal.tar.gz
I'm logged in as the web server user, so no need to modify file ownerships.
clear templates_c. This takes a little while.
cd DRUPAL_ROOT rm -rf sites/default/files/civicrm/templates_c/*
Database upgrade. This also takes a while. You may want to connect to your (MariaDB) database and "show processlist" to keep tabs on what's going on. Lots of alter tables, and truncation of cache tables.
$ drush civicrm-upgrade-db Upgrade outputs: CiviCRM now includes the easy-to-use CKEditor Configurator. To customize the features and display of your wysiwyg editor, visit the Display Preferences [1] page. Learn more... [2] Default version of the following System Workflow Message Templates have been modified: * Personal Campaign Pages - Owner Notification If you have modified these templates, please review the new default versions and implement updates as needed to your copies (Administer > Communications > Message Templates > System Workflow Messages). The custom fatal error template setting has been removed. By default, CiviCRM now disables the ability to import directly from SQL. To use this feature, you must explicitly grant permission 'import SQL datasource'. CiviMail no longer forces CKEditor to add html/head/body tags to email content because some sites place these in the message header/footer. This was added in 4.7.5 and is now disabled by default. You can re-enable it by visiting the CKEditor Config [3] screen and setting "fullPage = true" under the Advanced Options of the CiviMail preset. Default version of the following System Workflow Message Templates have been modified: * Additional Payment Receipt or Refund Notification * Contribution Invoice If you have modified these templates, please review the new default versions and implement updates as needed to your copies (Administer > Communications > Message Templates > System Workflow Messages). Default version of the following System Workflow Message Templates have been modified: * Contribution Invoice If you have modified these templates, please review the new default versions and implement updates as needed to your copies (Administer > Communications > Message Templates > System Workflow Messages). A new permission, "save Report Criteria", has been added. It is not granted by default. If your users create reports, you may wish to review their permissions. Links: ------ [1] http://default/crew/civicrm/admin/setting/preferences/display?reset=1 [2] https://civicrm.org/blogs/colemanw/big-changes-wysiwyg-editing-47 [3] http://default/crew/civicrm/admin/ckeditor
Finally, some cache clearing
drush cc views drush cc all
Post Upgrade
Now, I'm able to log in to drupal, and load civicrm. After doing so I'm told
System Status: Error Cron Not Running Remote Profiles Enabled
I disabled remote profiles, via https://masspirates.org/crew/civicrm/admin/setting/misc?reset=1
In Upload Directories, I parametered "Temporary Files Directory", "Image Directory", "Custom File Directory", and "Extensions Directory" with [civicrm.files] as a the path prefix. That happens to be where the directories are currently located.
Customized Resource URLs, as follows:
- CIVICRM Resource URL: [cms.root]/sites/all/modules/civicrm
- image upload url: [civicrm.files]/persist/contribute/
- Extension resource url: [civicrm.files]/extensions/
Civi tells me that cron is not configured. Our site user has a crontab with several civi-related entries. Used crontab -l to see them, and then manually executed them from the command line. That dismissed the dashboard warning about cron not being configured.
I see an information notice saying
- This MySQL database stores certain fields with data-type "DATETIME". To improve timezone support, you may want to change these from "DATETIME" to "TIMESTAMP".
I opt to be reminded about this in a week. This will be a bunch of alter tables.
As a test, I found a civi event for PirateCon 2018, and registered myself.
https://docs.civicrm.org/sysadmin/en/latest/upgrade/#after-upgrading lists other post-upgrade tasks. Much of the space is devoted to system workflow message templates. We appear to have changed one - the online event registration, to remove the text "please print this confirmation for your records".
I reverted to the default template, then went back and removed the text
- {ts}Please print this confirmation for your records.{/ts}
Finally
git add sites/all/modules/civicrm git commit -m "upgraded civicrm" git gc # for good measure