CiviCRM Community Forums (archive)

I just tried your recommendation of incremental upgrade from 4.4.6 to 4.4.9 before trying to go up to 4.5

It still fails in the same manner   

Mine was.

Yes an empty DB is always easier to upgrade than one with data.

Given what you said, you may need to manually debug the code, by putting in debugging statements to figure out where it fails.

You can do this very simply by using:

echo 'Got to here.';die;
and figure out where it's failing.

Solved!  It was related to the theme, though I'm not sure exactly how/why.

I'm using a customized version of the Marinelli base theme on my Drupal site. To avoid this upgrade failure I followed all of the steps outlined by ldgpangeo above, but prior to running 'civicrm/upgrade?reset=1' to trigger the script I changed the Drupal theme from my custom theme to an unaltered theme that I had installed, Beale Street. I suspect that changing to one of the out-of-the-box Drupal themes like Bartik would have worked as well. Once the new theme was active I ran the upgrade script with success.

I don't know that this issue is actually related to a particular version of CiviCRM but in my case I was on 4.4.3 and wanting to upgrade to 4.4.10  I did an initial upgrade from 4.4.3 to 4.4.5 and then a second one from 4.4.5 to 4.4.10. After successfully reaching 4.4.10 I switch the Drupal theme back to my custom production theme.  All is well.  I don't know if it will be necessary to switch themes again to do the next upgrade or not. I'll do some trials on my test instance when I can. For now the production site is up to date and I'm relieved.

I want to note that prior to starting the upgrade process I followed the instructions here:  http://wiki.civicrm.org/confluence/display/CRMDOC/Ensuring+Schema+Integrity+on+Upgrades   to insure that my schema was clean.

Thanks to everyone who added posts to this thread. The combined input is so frequently what solves a problem for me. 

I have run upgrades multiple times now with the same problem as others have had - although one of my installs is now working (thank goodness).
But: even though I finally have a working civicrm 4.5.4, if I go to the "clean up caches and update paths" option:
  - the base directory and base url recommendations mess up the civicrm dashboard (the green "@" signs across the page), and I had bad links again
  - I used the back arrow to reverse to the "clean up caches and update paths" option and copied my old references back again. Pressed <save> & now ok

I have installed 3 times using the drupal civicrm distributions:
  - 1st, the original one that is "static" to drupal 7.32 and civicrm 4.4.6 which we are immediately recommended to update to d 7.34 and civi 4.4.10.
     I applied the usual method of replacing the civicrm module with a 4.5.4 download and the update ran perfectly - except for the above base dir and url
     problems. Until upgraded, I was ok.
  - 2&3: tried the new drupal 7.x civicrm 4.x distribution that is a superior idea that can be updated without constant warnings about a variance to the
    original distro version number not matching (Thank you to whoever took the time to do that).
  - On the 3rd attempt, I went from civicrm 4.4.10 to civicrm 4.5.4 and have finally (manually) I think figured out why these updates are going wrong (at
    least for me) when migrating to civicrm 4.5.4:
    1. I am using the "profiles" location for the civicrm files because of the way the distributions work. I could easily have moved everything to the normal
    drupal 7 location under all/modules, but did not for 2 reasons:
       a. I am running my local desktop version under the acquiadev desktop 2 server, and I would be "overriding" the expected structure - so unable to 
           synchronize correctly, etc. in the future. I'll submit a separate question on that one.
       b. Drupal 8 is heading in the similar direction with distributions in their own profile/vendor locations, so best to figure this out now.
     2. with distributions (drupal/civi/pantheon...), the base address has to be longer to account for the "starterkit_civicrm" folders added to the usual base.

I have currently got my screens all close to "normal looking, except for some of the civicrm icons that are missing - they were there when the rest did not work, but either gone, or way too small now. So those problems are likely based on using a responsive theme (?). I'll research until I find the answer.

It seems to me, once we have installed a module, there needs to be a much simpler civicrm.settings.php file with our installed "modules/civicrm" location to avoid the struggle that the current civicrm.setting.php code has to go through as a "generic" solution. I am not a php coding wizard, but I am tempted to remove references I know I don't need (in a separate copy) and try that as a workaround to the dir/url challenges that so many variations have caused in the civicrm.settings.php program.

Is this perhaps causing several of us to have problems when other's don't - a challenge when the civicrm modules (and contribs) are not in the usual location.

Any helpful thoughts about my icons disappearing when I finally got the basics working?  And is there a running discussion on the upgrade process?
If the latter, I am glad to join the group to brainstorm ideas - especially since my other question is about having multiple profiles in the same application like my having both the acquia, and the civicrm profiles in a single application. I have to do a profile switch between them in order to update only one at a time (and if anything is in the wrong ("all/modules...) location, those modules could be deleted by the profile in control.Not sure how we will ever survive with single threading each distribution especially with drupal 8 heading in that direction.  P.S. I also tried the Pantheon drupal/civicrm distribution download and install - with similar/same results.

If you have, or sign up for, an account for the wiki, you should be able to add a warning to the upgrade instructions.