Upon installing and activating the module, going to the main /admin page encountered a fatal error which displayed only the error msg below. Interestingly, evidently it seems somehow no other pages are affected -- e.g. /admin/modules, /admin/plugin_manager/settings, etc. all seem to work -- everything except the main admin page. Removing the Plugin Manager directory, the admin main page worked again; restoring the Plugin Manager directoy again broke the admin page; removing only "plugin_manager.install," the admin main page worked again. I checked and the install script seems to have worked; 4 plugin_manager tables were created in the database. I guess I can simply keep that script out of the module's directory until such time as I might ever need to uninstall it, then I can just copy that file back in and run it at that point.

I don't know which module, Plugin_manager or CiviCRM, is at fault or why the heck the /admin main page was the only one affected. But I thought I would pass this along.

**** Error statement ****

Fatal error: Cannot redeclare _pear_call_destructors() (previously declared in /usr/lib/php/PEAR.php:775) in /home/username/public_html/drupal/sites/all/modules/civicrm/packages/PEAR.php on line 806

**** CODE from PEAR.php (lines 771-806) below ****

// {{{ _PEAR_call_destructors()

function _PEAR_call_destructors()
{
global $_PEAR_destructor_object_list;
if (is_array($_PEAR_destructor_object_list) &&
sizeof($_PEAR_destructor_object_list))
{
reset($_PEAR_destructor_object_list);
if (PEAR::getStaticProperty('PEAR', 'destructlifo')) {
$_PEAR_destructor_object_list = array_reverse($_PEAR_destructor_object_list);
}
while (list($k, $objref) = each($_PEAR_destructor_object_list)) {
$classname = get_class($objref);
while ($classname) {
$destructor = "_$classname";
if (method_exists($objref, $destructor)) {
$objref->$destructor();
break;
} else {
$classname = get_parent_class($classname);
}
}
}
// Empty the object list to ensure that destructors are
// not called more than once.
$_PEAR_destructor_object_list = array();
}

// Now call the shutdown functions
if (is_array($GLOBALS['_PEAR_shutdown_funcs']) AND !empty($GLOBALS['_PEAR_shutdown_funcs'])) {
foreach ($GLOBALS['_PEAR_shutdown_funcs'] as $value) {
call_user_func_array($value[0], $value[1]);
}
}
}

Comments

PghFreeNet’s picture

PghFreeNet commented
Priority: Normal » Critical

After configuring the settings, I went to the "Search" page of the Plugins_Manager and selected a package to install. When I tried several times to install, variously using the "Install Queued Plugins" or "Install" in the menu, I again got:

Fatal error: Cannot redeclare _pear_call_destructors() (previously declared in /usr/lib/php/PEAR.php:775) in /home/username/public_html/drupal/sites/all/modules/civicrm/packages/PEAR.php on line 806

Repeated trying to install a different module using Plugins_Manager with same results. Going to http:/sitedomain/drupal/admin/plugin_manager/install returns the same message. It only breaks the install page (i.e. /admin/plugin_manager/install) this time. It also does not install the selected module (unlike with the initial Plugin_Manager module install, which successfully installed it while breaking the admin page).

NOTE: the Plugins_Manager.install file (used to install its own module) remained deleted from the Plugins_Manager directory during the this round of behavior.

I have since manually installed a couple other modules through the /admin/modules page using the standard method without any apparent problems, so it seems to be something about the install process used in Plugins_Manager.

cosmicdreams’s picture

cosmicdreams commented

Subscribing, I'm also experiencing this. I can add that I wasn't having this issue when I was using CiviCRM 2.2 alpha 3, but since I upgraded to CiviCRM 2.2 beta 3 I am plagued with this.

Is plugin_manager invoking Civicrm code? or is this error caused by civicrm intruding on the "install plugins" action?

cosmicdreams’s picture

cosmicdreams commented

I think I found the issue at hand (at least for me). http://forum.civicrm.org/index.php/topic,267.0.html

I do in fact have two civicrm codebases in place. one in my /sites/all/modules and one in my /sites/_site_name_/modules. I guess this isn't a valid use case for civicrm.

No removing the other civicrm codebase did NOT solve the problem. I think I might try renaming the functions through out civicrm to see if that works.

PghFreeNet’s picture

PghFreeNet commented

Ah ha! I've submitted a bug issue (http://issues.civicrm.org/jira/browse/CRM-4200) with civicrm.org and referenced this Drupal node in it. Since it worked for you in Alpha3, if there is anything you can add could you please submit a comment there too, it might help get this fixed before final release.

I was using CiviCRM 2.2 Beta 2 when I first reported this here. I've since updated to Beta3 and while the install/uninstall/update problem is still there, at least the Admin page now works OK when both Plugins_Manager and CiviCRM 2.2 are enabled. I haven't seen if CiviCRM has any problems with the Plugins_Manager enabled at the same time, have you?

WORKAROUND: When I disable CiviCRM but do not uninstall it, Plugins_Manager works fine. When I'm done working with the Plugins_Manager, I just re-enable CiviCRM.

It would be nice if I didn't have to do that though.

PghFreeNet’s picture

PghFreeNet commented

CiviCRM's reply:

"you will need to diagnose and help fix this issue. We do not have the resources to ensure that CiviCRM works with all drupal modules. I'm not sure if we know of any good solutions if two modules are using PEAR (other than ensuring that your include path has only one PEAR version etc) "

Without my having a chance to reply, they closed the issue and marked it "Won't Fix" (rather abrupt of them, if you ask me).

I guess the thing to do is run a diff between CiviCRM alpha 3 and beta 3 and see what areas might be suspect (I don't know when I can get to it or if I can still get the alpha3 code easily). Looking through the Plugin_Manager code, I didn't see any direct reference to PEAR anywhere. So since CiviCRM beta3 code does, it would be very interesting to find out if the corresponding alpha3 file had the same code in it; looking that up shouldn't be too hard.

DISCLAIMER: I am a user, not a coder, so I'm just able to look around; I don't purport to be able to come up with the definitive solution. So, until we get one, I guess the work around will have to do.

lobo’s picture

lobo commented

apologies for the abruptness in closing the issues. We are marching towards a 2.2 release and tend to either fix issues or mark them as wont fix.

we'll be happy to reopen the issue and integrate your patch if you can get it working with plugin_manager

lobo

dblack-1’s picture

dblack-1 commented
Issue tags: +workaround

as workaround, just remove /home/username/public_html/drupal/sites/all/modules/civicrm/packages/PEAR.php if /usr/lib/php/PEAR.php version is above or same.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Status: Active » Closed (outdated)
Issue tags: -workaround

I am closing this issue, since it's for a Drupal version no longer supported.