upgrade failure from 4.4.6 to 4.5.4

[ldgpangeo]

I'll try your recommendation to do it in incremental steps and post back here how it turns out.
 

[ldgpangeo]

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   

[Hershel]

Was the test copy upgrade run on the same server?

[jrmatson]

Mine was.

[ldgpangeo]

Yes, same server.

I suspect it's something about the mysql database itself because on that server...

a.  I can create a new 4.4.6 instance with no data and upgrade it to 4.5.4 with no problems.

b.  If I try to upgrade production from 4.4.6 to 4.5.4, it fails with the noted problems.

c.  If I create a new 4.4.6 instance and populate it with the production data, it fails with the same problems.

I've exported the db schemas without data and examined the diff (Linux compare two files) command output and see nothing that might account for this.

I've also tried an incremental upgrade of 4.4.6 to 4.4.9, but that also fails with the same problem.

The speed of the failure suggests that it's probably early in the upgrade process -- perhaps when the script checks to see what upgrade may be needed, but I don't know enough of the Civi internals to be able to confirm this.  Is there info on how the upgrade script functions and what it consults within the db?

I did install into the b. instance above some drupal tools such as devel and devel for firebug, but none of this generated any messages that proved informative -- at least to my skill level.

[Hershel]

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:

Code: [Select]

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

[jrmatson]

Well, I did the debug exercise that you suggested and found that the error occurs at this line of upgrade.php:

    echo CRM_Utils_System::theme($content, $this->_print, TRUE);

Unfortunately, my PHP coding skills are lacking which slows me down and I had to put my site back to a working state for production use so I can't go further right now.

Does isolation to that line suggest anything? Could it be related to the theme?

Thanks

[jrmatson]

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. 

[Hershel]

Glad you got it solved. One of the suggestions on the upgrade pages is to use a base theme. An unaltered one, that is.

[barbarae]

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.

[ldgpangeo]

Good Catch!

I changed the Drupal theme and the upgrades now work correctly on my sandbox units.   I'll try it in production once I can schedule a time slot to take it down.

Marinelli is "bad" for upgrades.
Garland worked fine.

How do we make this clearer in the upgrade instructions?  I've wasted probably 30 hours of time for such a simple solution.

[joanne]

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