CiviCRM Community Forums (archive)

I'm trying to upgrade a Joomla site to CiviCRM 4.2.7 from 4.1.2, using the 'alt' zip.

On running the installer I get the following errors in debug mode:

        JInstaller: :Install: Cannot find XML setup file
        Failed deleting civicrm.php
        JInstaller: :Install: Cannot find XML setup file
        Failed deleting civicrm.php

However there are no php errors, and the install claims to have completed successfully.

Running the upgrade script fails with a blank screen but does not throw a php error.

Trying to open any CiviCRM page then dies with a fatal PHP error:
PHP Fatal error:  Allowed memory size of 524288000 bytes exhausted (tried to allocate 77 bytes) (as you can see, I already increased the memory to stupid levels)

Opening a membership page on the public site throws the following error:


Sorry. A non-recoverable error has occurred.
DB Error: no such table
Error Details
Additional Details:

Array
(
    [callback] => Array
        (
            [0] => CRM_Core_Error
            [1] => handle
        )

    [code] => -18
    [message] => DB Error: no such table
    [mode] => 16
    [debug_info] => SELECT *
 FROM civicrm_preferences
 
 WHERE (  civicrm_preferences.domain_id = 1 )  AND (  civicrm_preferences.is_domain = 1 )
 
 
 
 [nativecode=1146 ** Table 'cdhalton.civicrm_preferences' doesn't exist]
    [type] => DB_Error
    [user_info] => SELECT *
 FROM civicrm_preferences
 
 WHERE (  civicrm_preferences.domain_id = 1 )  AND (  civicrm_preferences.is_domain = 1 )
 
 
 
 [nativecode=1146 ** Table 'cdhalton.civicrm_preferences' doesn't exist]
    [to_string] => [db_error: message="DB Error: no such table" code=-18 mode=callback callback=CRM_Core_Error::handle prefix="" info="SELECT *
 FROM civicrm_preferences
 
 WHERE (  civicrm_preferences.domain_id = 1 )  AND (  civicrm_preferences.is_domain = 1 )
 
 
 
 [nativecode=1146 ** Table 'website.civicrm_preferences' doesn't exist]"]
)

Return to home page.

I'm guessing that's just telling me that the upgrade script failed.

I've tried a lot of things to find a solution, but in the end I have to run a site restore to get back to the original. Because the errors are kind of unspecific, I don't really know where to start. Playing around I've seen a lot of other PHP fatal errors indicating that basic Joomla classes like JFACTORY are missing.

Any ideas very greatly appreciated.

I'd expect to get at least a PHP Fatal error in my server logs when getting a blank screen, but actually there's nothing. The server is set to record reasonably verbose PHP error logs.

The site has a large number of plugins enabled ... it's a fairly complex site. Should I try disabling all plugins and trying again?

I ran the upgrade on a backup server which is, as close as I can get, identical to this server, and got the upgrade to work.

Hi,

Disable all plugins, extensions, etc, and run upgrade ... exactly the same result.

Do you have any idea what is causing the initial error (before trying to run the DB update script)? Is that likely to be responsible for the larger problem?

JInstaller: :Install: Cannot find XML setup file
        Failed deleting civicrm.php
        JInstaller: :Install: Cannot find XML setup file
        Failed deleting civicrm.php

Thanks ... that makes sense. After re-importing the DB tables will I need to re-run the upgrade script, or should it just work?

Appreciate it, thanks.

the "Failed deleting civicrm.php" seems like a permission issue on the file system

that error is also from the joomla install manager. If you have php skills, it might be a lot faster if you add some debug statements within the joomla install component and try and track down what is failing and why.

lobo

This is the latest I have established by enabling as much debugging as possible.

1. Running civicrm-alt upgrade script runs successfully (errors mentioned in initial post are gone).
2. Running database update script fails with WSOD - no PHP error, no MySQL error logged. (URL used is http://domain.ca/administrator/?option=com_civicrm&task=civicrm/upgrade&reset=1)

Visiting the CiviCRM dashboard then produces the following error:

Fatal error: Maximum function nesting level of '100' reached, aborting! in /home/stagingsites/staging.cdhalton.ca/webroot/administrator/components/com_civicrm/civicrm/packages/PEAR.php on line 2178
###LAST FEW LINES OF STACK DUMP ###
93 0.6692 10692372 CRM_Core_BAO_Navigation::createNavigation( ) ../Smarty.php:151
94 0.6692 10692540 CRM_Core_DAO::checkFieldExists( ) ../Navigation.php:533
95 0.6692 10693416 CRM_Core_DAO::executeQuery( ) ../DAO.php:512
96 0.6693 10693640 CRM_Core_DAO::composeQuery( ) ../DAO.php:865
97 0.6693 10693848 CRM_Core_DAO::escapeString( ) ../DAO.php:929
98 0.6693 10693892 DB_DataObject->escape( ) ../DAO.php:1171
99 0.6694 10693936 DB_DataObject->_connect( ) ../DataObject.php:1628
Here are the MySQL queries generated by the dashboard before it dies:

1213 Query SELECT extension_id AS id, element AS "option", params, enabled
FROM qdcm_extensions
WHERE `type` = 'component' AND `element` = 'com_civicrm'
1214 Connect dbnameusr@localhost on
1214 Init DB dbname
1214 Init DB dbname
1214 Query /*!40101 SET NAMES utf8 */
1214 Init DB dbname
1214 Query SELECT *,  config_backend, locales, locale_custom_strings 
 FROM civicrm_domain
 
 WHERE (  civicrm_domain.id = 1 )
1214 Init DB dbname
1214 Query SET @civicrm_user_id = 2933
1214 Init DB dbname
1214 Query SELECT v.name as valueName, v.value, g.name as optionName
FROM   civicrm_option_value v,
       civicrm_option_group g
WHERE  ( g.name = 'directory_preferences'
OR       g.name = 'url_preferences' )
AND    v.option_group_id = g.id
AND    v.is_active = 1
1214 Init DB dbname
1214 Query SELECT *
 FROM civicrm_preferences
 
 WHERE (  civicrm_preferences.domain_id = 1 )  AND (  civicrm_preferences.is_domain = 1 )
1214 Init DB dbname
1214 Query SELECT
   option_value.id          as id,
   option_value.label       as label,
   option_value.value       as value,
   option_value.name        as name,
   option_value.description as description,
   option_value.weight      as weight,
   option_value.is_active   as is_active,
   option_value.is_default  as is_default
FROM
   civicrm_option_value  as option_value,
   civicrm_option_group  as option_group  WHERE option_group.id = option_value.option_group_id  AND option_value.is_active = 1 AND option_group.name = 'languages' ORDER BY weight
1214 Init DB dbname
1214 Query SHOW COLUMNS
FROM civicrm_preferences
LIKE 'navigation'
1214 Init DB dbname
1214 Query SHOW COLUMNS
FROM civicrm_preferences
LIKE 'navigation'
1214 Init DB dbname
1214 Query SHOW COLUMNS
FROM civicrm_preferences
LIKE 'navigation'
1214 Init DB dbname
1214 Query SHOW COLUMNS
FROM civicrm_preferences
LIKE 'navigation'
1213 Quit
1214 Quit

I've tried everything with this thing ... it's driving me crazy because I really can't work out where to start looking for the problem.

As I mentioned before, when I tried a manual DB update table by table, I ran into InnoDB foreign key constraints, but I can't actually see any evidence that it gets that far in the upgrade script.

Thanks ... I'm biting the bullet and getting my hands dirty.

In case anything leaps out at you, I managed to get the CiviCRM backtrace working, and this is what I get:

backTrace
/home/path/to/site/webroot/administrator/components/com_civicrm/civicrm/CRM/Core/Error.php, backtrace, 296
/home/path/to/site/webroot/administrator/components/com_civicrm/civicrm/CRM/Upgrade/Page/Upgrade.php, fatal, 113
/home/path/to/site/webroot/administrator/components/com_civicrm/civicrm/CRM/Core/Invoke.php, run, 224
/home/path/to/site/webroot/administrator/components/com_civicrm/admin.civicrm.php, invoke, 87
/home/path/to/site/webroot/administrator/components/com_civicrm/admin.civicrm.php, civicrm_invoke, 40
/home/path/to/site/webroot/libraries/joomla/application/component/helper.php, require_once, 383
/home/path/to/site/webroot/libraries/joomla/application/component/helper.php, executeComponent, 351
/home/path/to/site/webroot/administrator/includes/application.php, renderComponent, 153
/home/path/to/site/webroot/administrator/index.php, dispatch, 46
This at least suggests where to look for the problem.