Upgrade 4.0.0 to 4.2.4: database upgrade fails, says []

[zmi]

Hello, I tried to upgrade our civicrm from 4.0.0 to 4.2.4. The install of civicrm files was smooth, until calling the page which showed "Upgrade Now" (means the database) in a green frame. After clicking that, a new page opens, only telling me

[]
              Retry Skip

The only error I can find is in the apache error log:

File does not exist: /docroot/administrator/http:, referer: http://<our_host>/administrator/?option=com_civicrm&task=civicrm/upgrade/queue/runner&reset=1&qrid=CRM_Upgrade

What should I do?

[Hershel]

Did you refresh that page? Sometimes that makes it work.

[zmi]

Did you refresh that page? Sometimes that makes it work.

Yes, went back and forth several times, pressed F5, deactivated eaccelerator, restarted Apache web server, .... no help.

Do you know where the [] could come from? I have no idea what to do, as there's just no message displayed or logged anywhere.

[Hershel]

Actually the 4.2.3 and 4.2.4 releases were both pulled due to problems with the upgrade script.

Perhaps try 4.2.2 now, as 4.2.5 isn't ready yet.

[zmi]

Actually the 4.2.3 and 4.2.4 releases were both pulled due to problems with the upgrade script.
Perhaps try 4.2.2 now, as 4.2.5 isn't ready yet.

Argh! I just downloaded 4.2.4 yesterday, and it's still on sourceforge now. OK, I'll give 4.2.2 a shot....

Damn, doesn't work too. I'll attach a screen shot so you can see what I see. Before this screen, I see a green window with this message:

Use this utility to upgrade your CiviCRM database from 4.0.0 to 4.2.2.

Back up your database before continuing. This process may change your database structure and values. In case of emergency you may need to revert to a backup. For more detailed information, refer to the Upgrade Documentation.

Click 'Upgrade Now' if you are ready to proceed. Otherwise click 'Cancel' to return to the CiviCRM home page.

[Hershel]

Can you look in the Network tab of Firebug for Firefox (install Firebug if you don't have it) and see what URL is being loaded via Ajax for CiviCRM and right click and open that in a new tab?

There's a chance you may see an error message that way....

[zmi]

Can you look in the Network tab of Firebug

Nice catch! 

I can see it tries to load a lot of css/js files which it doesn't find. Looking at it, the URL is broken:

http://<our_host>/administrator/http://<our_host>//components/com_civicrm/civicrm/css/deprecate.css

Good, so I know the URL is put together in a wrong way. Which configuration field should I change to get that correct?

[Donald Lobo]

Note that the 4.2.x series is fine for all web based upgrades

there is an issue with drush based upgrades that will be fixed in 4.2.5

lobo

[Hershel]

I can see it tries to load a lot of css/js files which it doesn't find. Looking at it, the URL is broken:

http://<our_host>/administrator/http://<our_host>//components/com_civicrm/civicrm/css/deprecate.css

Good, so I know the URL is put together in a wrong way. Which configuration field should I change to get that correct?

Not sure. Can you check in your two civicrm.settings.php files to make sure the URL is correct?

Note that the 4.2.x series is fine for all web based upgrades

there is an issue with drush based upgrades that will be fixed in 4.2.5

Ah, good to know. I see now that Dave updated his blog post. Updates don't go into RSS so I didn't see that before.

[zmi]

Both civicrm.settings.php have similar:

define( 'CIVICRM_UF_BASEURL'      , 'http://<our_host>/' );
define( 'CIVICRM_UF_BASEURL'      , 'http://<our_host>/administrator/' );

So that seems OK to me. I also on the website in settings, all looks correct. Still, no database update.

[Hershel]

I'm not sure. Can you delete your Config.IDS.ini file?

[Eileen]

Note that if you have devel output enabled you'll get this symptom. I think any print_r or echo that is triggered with cause it.

[zmi]

Note that if you have devel output enabled you'll get this symptom. I think any print_r or echo that is triggered with cause it.

OK, and where would that be set? The config has debug=0.

I retried it now, and found that some directories did not have write permission for the webserver: and that solved it! Well, only half: Now the DB upgrade script at least started, but it crashed, saying it needs the SUPER privilege (we have MySQL 5.1.49, I thought it would work without SUPER on 5.1.x?). Any, set that, restored DB, ran again. Then came this:

Code: [Select]

CREATE TABLE `civicrm_setting` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `group_name` varchar(64) COLLATE utf8_unicode_ci NOT NULL COMMENT 'group name for setting element, useful in caching setting elements', `name` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL COMMENT 'Unique name for setting', `value` text COLLATE utf8_unicode_ci COMMENT 'data associated with this group / name combo', `domain_id` int(10) unsigned NOT NULL COMMENT 'Which Domain is this menu item for', `contact_id` int(10) unsigned DEFAULT NULL COMMENT 'FK to Contact ID if the setting is localized to a contact', `is_domain` tinyint(4) DEFAULT NULL COMMENT 'Is this setting a contact specific or site wide setting?', `component_id` int(10) unsigned DEFAULT NULL COMMENT 'Component that this menu item belongs to', `created_date` datetime DEFAULT NULL COMMENT 'When was the setting created', `created_id` int(10) unsigned DEFAULT NULL COMMENT 'FK to civicrm_contact, who created this setting', PRIMARY KEY (`id`), KEY `index_group_name` (`group_name`,`name`), KEY `FK_civicrm_setting_domain_id` (`domain_id`), KEY `FK_civicrm_setting_contact_id` (`contact_id`), KEY `FK_civicrm_setting_component_id` (`component_id`), KEY `FK_civicrm_setting_created_id` (`created_id`), CONSTRAINT `FK_civicrm_setting_domain_id` FOREIGN KEY (`domain_id`) REFERENCES `civicrm_domain` (`id`) ON DELETE CASCADE, CONSTRAINT `FK_civicrm_setting_contact_id` FOREIGN KEY (`contact_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE CASCADE, CONSTRAINT `FK_civicrm_setting_component_id` FOREIGN KEY (`component_id`) REFERENCES `civicrm_component` (`id`), CONSTRAINT `FK_civicrm_setting_created_id` FOREIGN KEY (`created_id`) REFERENCES `civicrm_contact` (`id`) ON DELETE SET NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1 [nativecode=1050 ** Table 'civicrm_setting' already exists]

OK, so restore DB again, run

Code: [Select]

alter table civicrm_setting rename to civicrm_setting_zmi;
run upgrade again: and I get the [] output again! WTF?
(OK, the 2nd time it complained because I had not dropped the DB, just imported again, so this is my fault.)

[Eileen]

OK- so when you revert to backup you need to drop the database & recreate it - otherwise tables created last attempt will still be there & the upgrade will fail when it tries to create them

[zmi]

Yes, I just fixed my posting to say the same