To answer my own question, it is possible to update CiviCRM with drush but this isn't completely straightforward either. For the benefit of others I post the steps I took below.
put the site into maintenance mode: drush vset maintenance_mode 1
clear all caches: drush cc all
take a full backup of site and test that this works on a development server
Disclaimer, as with other answers, this is aimed at a fairly technical person who kinda understands what they're doing and has made lots of backups :-)
As Sophie points out you can find the exact problem looking at the latest log in the ConfigAndLog directory.
For several of us the problem has been that there's a key defined incorrectly and the script's ...
The recommended and least invasive fix is to resolve the underlying SSL issues.
It was intentional that PHP5.6 tightened security here. If your hosting environment doesn't validate the SSL certificate you're communicating with, one of these things is probably true -
The hosting environment has a misconfigured certificate chain. (Fix varies by hosting ...
If you have installed civicrm-buildkit and configured civibuild, then you can use the tutorial steps at Daily Coding: Upgrade Tests.
If you don't use civibuild, then you can piece-together a similar workflow using civicrm-upgrade-test.
For more discussion about writing upgrade logic, see Upgrade Reference on the wiki.
For a general, high-level overview of ...
The pop-up message should have a link "View details and manage alerts" that takes you to the System Status page. That includes an Update Indices button (yes there is a typo in 4.7.19 but it doesn't affect the function).
Update Indices should create the missing indices which may take a while depending on which indices are missing and how much data you have ...
This may be related to Status page angular load error. Make sure that the following two items point to the same place:
Image Upload URL at Administer > System Settings > Resource URLS
Image Directory at Administer > System Settings > Directories
If this doesn't work, try disabling Asset Caching at Administer > System Settings > Debugging and Error Handling ...
You can get a list of Civi-related Drush commands simply by typing drush on the command line. Excerpt:
All commands in civicrm: (civicrm)
civicrm-api (cvapi) CLI access to CiviCRM APIs. It can return pretty-printor json formatted data.
civicrm-enable-debug Enable CiviCRM ...
The 5.x series has a new point release every month, with a focus on stability (generally, large new features go into extensions).
So upgrading 5.0 -> 5.7 is the equivalent of upgrading 4.7.20 -> 4.7.27, a minor upgrade and generally considered safe to do at once.
Are you using the wkhtmltopdf option in CiviCRM:
Administer CiviCRM >> System Settings >> Misc
Its a local binary installation (needs to be done by your system admin), but gives you a lot better performance than the php pdf libraries shipped with CiviCRM
Thanks to eug for finding the problem (see comments). Eug's solution worked for me: Edit the file administrator/components/com_civicrm/civicrm/templates/CRM/Admin/Form/Setting/Path.hlp to replace the first crmResPath with crmResURL
Update: problem persists in 4.7.3. Have upgraded the bug report priority to Major.
Update: problem persists in 4.7.4.
The instructions you found I have used several times and I think they are still valid. So, in your case first upgrade CiviCRM to a version with both a drupal 6 and drupal 7 version, then upgrade drupal and use the same version of CiviCRM. Then I'd advise to further upgrade CiviCRM to the Long Term Support version 4.6.
I have been dealing with upgrades a lot lately, and I have the process "down" so that it is very fast. I am impressed with how fast I can do an upgrade. The key is shell access - or something that mimics it - because using sftp is very slow. That might be your problem. Once I have the data backed up it basically goes like this:
ssh into the server and ...
Maybe you can try to run the upgrade script again to go from 4.7.10 to 4.7.12
Documented on the Wiki Upgrading CiviCRM for Wordpress .
We have found that there are problems with both civicrm_option_value and civicrm_case_contact table indexes that have not been properly fixed by https://github.com/civicrm/civicrm-core/pull/10908 as of 4.7.25 or the rc's for 4.7.26 and 4.7.27 as of late October 2017.
When we encounter this we have been runing the following queries in the relevant MySQL ...
CiviCRM is not warning you about a file named Array.php, the confusing error message is because it's rendering a PHP array to a text string.
I've opened an issue in JIRA about this and submitted a suggested quick fix:
CRM-17909: File 'Array' presents a security risk and should be deleted.
It looks like the fix is as simple as adding  as shown in this ...
Pete is right that even recent versions of CiviCRM (certainly in the 4.6.x series) work with Drupal 6 sites. The "no longer officially supports" issue is that the core team won't go out of their way to make D6-specific fixes.
That said, I have encountered problems with new installations on Drupal 6, but this has been for testing--why else would someone ...
In general, I'd recommend no.
Some extensions - literally - may not be reinstallable if they aren't qualified for that version of Civi.
My recommendation: TAKE BACKUPS!!! Then don't disable extensions and just go ahead with the upgrade.
The slowest part of upgrading on a large installation is usually the civicrm_mailing_event_* tables. That data is also often stale, so consider deleting it if you don't need to keep historical information about past civimailouts.
The LTS as you know it is the last one!
Eileen explained the details here: https://civicrm.org/blog/eileen/the-lts-going-forwards
Essentially the idea is that through better release/QA/testing we can make the current 4.7 the Long Term Stable release. In combination with the fact that innovative ideas / new features are going to be housed in extensions.
After upgrading to 4.7.19 I found that indices cannot be created automatically; you can look at your CiviCRM error log to see which database statement is causing a fatal error - you might see problems such as a duplicate index.
In my case I had to run these database statements before/after repairing indices, but it could be different on your site:
The fix to the file CRM/Utils/System/Joomla.php suggested in the link
made the cron jobs run again for CiviCRM 4.7.25 and Joomla 3.8.1.
In short - no. Moreover, if it did, it would be dangerous, because the Drupal module can't know which database writes are part of the legitimate upgrade and which aren't.
In my experience, only upgrades that add/remove indices take any appreciable amount of time. Is it possible that more frequent upgrades will result in shorter downtimes for your use case?...
Is the site configured for multi-lingual? If so then it might be an error with schema rebuild. Can you try rebuilding the schema using api explorer or drush?
Or You will need to manually add the 'frontend_title' field to the table by running below sql query.
ALTER TABLE `civicrm_uf_group` ADD `...
Looks like one of your customfield extending 'Contact', 'Individual', 'Organization', 'Household' has missing machine name. The best way to check would be to run below sql query to check if there is any result
SELECT id, name, label FROM civicrm_custom_field WHERE (name = '' OR name IS NULL)
If you found any rows than run below query to update the name ...
Can you ensure that you do not have two copies of the civicrm codebase (irrespective of what you might have renamed it to) under
Most likely the error is caused by php finding two copies of the CRM/Core/ClassLoader.php file
Two issues. 1. Database is getting reset when you upgrade 2. you cannot restore from backup.
Answer to #1 is this: Make sure you are following the upgrade procedure on
this page: http://wiki.civicrm.org/confluence/display/CRMDOC/Installation+and+Upgrades
Answer to #2 is this, before restoring from backup, follow this procedure.
a. ensure that the backup ...
This is a tricky one to resolve yourself. You basically need to identify whereabouts in the upgrade it failed. For example it might have done all the tasks for a particular point version & failed afterwards, or it might have run some sql & not completed.
If you look in the db the civicrm_domain table has a field called version. Once you know where ...
I just ran drush civicrm-upgrade-db and saw upgrade messages in the output.
While the formatting could certainly be improved, this does seem to work (in some cases?).
As Coleman notes below and in CRM-16946 - pre upgrade warnings/notices are not displayed by Drush upgrade, while post upgrade notices are.
UPDATE: CRM-18526 fixes this issue - it's just been checked in. To bypass this problem, upgrade to CiviCRM 4.7.8 or higher.
John is correct about this being related to CRM-18345. There are two problems with the upgrade code - and the SET FOREIGN_KEY_CHECKS=0 others posted only solves one of them.
I've posted my analysis here, and I expect that someone ...
We have Drupal 6 sites running just fine on the 4.6.x series. I don't know where you read that 'civicrm no longer supports drupal 6" - is it not more the case that Drupal no longer supports Drupal 6 and hence all module information concerning D6 is incorrect