Problem/Motivation

Disabling civigrant extension in 5.47 [so post migration of civigrant from core component to extension] - crashes site hard when CE is installed. Uninstalling CE first allows civigrant extension to be disabled. It looks like CE needs needs to be patched to ignore disabled components.

Re-enabling CE after disabling civigrant extension works. But that's just for confirmation - not a viable option to delete all views etc.

Comments

KarinG created an issue. See original summary.

markusa’s picture

markusa commented

This was an attempt: https://github.com/eileenmcnaughton/civicrm_entity/pull/364
But really that would require a Drupal cache clear at the right time.

We need a hook that fires when a component is disabled.

markusa’s picture

markusa commented

If the issue is disabling the extension .. could clear some caches with this hook
https://docs.civicrm.org/dev/en/latest/hooks/hook_civicrm_disable/

I don't see anything for when a component is disabled.

karing’s picture

karing
Location 🇨🇦
commented

I've got some more time now to detail this ->

Steps to reproduce:

1. On D9.3.6, CiviCRM 5.46 enable CiviGrant (to do a small WFC demo) and enable CiviCRM Entity (to create a view with Activities)
2. upgrade CiviCRM beyond 5.47 -> I went to 5.48.alpha1
3. disable civigrant extension [perhaps you've decided to no longer want grant functionality]
4. observe WSOD on every single page
5. drush cr also fails
6. backtrace (fished out of watchdog):

| 198.166.228.187 | 1646268005 |
| 392815 |   1 | php            | %type: @message in %function (line %line of %file).                                    | a:6:{s:5:"%type";s:14:"LogicException";s:8:"@message";s:71:"The id field definition does not exist and it is used as id entity key.";s:9:"%function";s:66:"Drupal\Core\Entity\EntityFieldManager->buildBaseFieldDefinitions()";s:5:"%file";s:70:"/var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php";s:5:"%line";i:318;s:17:"@backtrace_string";s:4269:"#0 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php(193): Drupal\Core\Entity\EntityFieldManager->buildBaseFieldDefinitions('civicrm_grant')
#1 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php(448): Drupal\Core\Entity\EntityFieldManager->getBaseFieldDefinitions('civicrm_grant')
#2 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php(267): Drupal\Core\Entity\EntityFieldManager->getFieldStorageDefinitions('civicrm_grant')
#3 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php(88): Drupal\Core\Entity\EntityDefinitionUpdateManager->getChangeList()
#4 /var/www/drupal/web/core/modules/system/system.install(851): Drupal\Core\Entity\EntityDefinitionUpdateManager->getChangeSummary()
#5 [internal function]: system_requirements('runtime')
karing’s picture

karing
Location 🇨🇦
commented
Priority: Normal » Critical

We actually now suspect that any site (even those with CiviGrant component disabled by default) upgraded it to 5.47+ will get to the same WSOD on every page.

The difference between disabled extensions and disabled components is that civicrm_api3("Grant", etc) is still available even when the component is disabled.

Bumping this to Critical.

karing’s picture

karing
Location 🇨🇦
commented
Priority: Critical » Major

Back to status = major as it may only affect sites who have CE and civigrant enabled at the time of migrating across 5.47

https://chat.civicrm.org/civicrm/pl/a6grg67u3pnyikcjgykqporggh

markusa’s picture

markusa commented
Priority: Major » Normal

For people not using Drupal integration for CiviGrant, until some better solution exists, Can do this:
1) Comment out this section here for civicrm_grant entity: https://github.com/eileenmcnaughton/civicrm_entity/blob/8.x-3.x/src/Supp... .. lines 325-336
2) Clear Drupal caches
3) Upgrade CiviCRM
4) Optionally uncomment that section, and clear Drupal caches again

If using Grant in Views or other Drupal integration, one could try this, but not sure how Drupal will react to an entity type disappearing and config depending on it.

markusa’s picture

markusa commented

Further testing has revealed, that CiviCRM Entity as it is in 3.1, will be ok upgrading to 5.47
Caveat, it appears that if Redis, and likely if Memcache are used, this error can happen.

Most likely option now is to patch CiviGrant extension in 5.47

drupal_flush_all_caches() needs be called if CMS=Drupal8 (D8+) or cache_clear_all() if CMS=Drupal (D7-)

redis and memcache should have hooks that clear their respective caches when those functions are ran.

I think still D7 module would need a similar patch to what was done in the D9 module. Will post when that is done and release made.

markusa’s picture

markusa commented
Status: Active » Closed (works as designed)

Backported fix for D7 version, that was in 8.x-3.1
https://www.drupal.org/project/civicrm_entity/releases/7.x-2.4

karing’s picture

karing
Location 🇨🇦
commented

I don't think this is resolved completely though - we can't be the only providers using redis or other forms of caching.

markusa’s picture

markusa commented
Status: Closed (works as designed) » Active

Well .. AFAIK there is no way to react to a CiviCRM extension being disabled / enabled in a Drupal module.
This likely needs a Core patch to fix.

hook_civicrm_disable() is only called in the extension that is disabled, not all modules. So in CiviGrant, this hook should be added or augmented to:
drupal_flush_all_caches() needs be called if CMS=Drupal8 (D8+) or cache_clear_all() if CMS=Drupal (D7-) on extension install/enable/disable

If there is some programmatic method we can use, then we'll definitely do it.

For now people should:
Disable redis or memcache
Disable CiviGrant extension
Re-enable redis or memcache

markusa’s picture

markusa commented
Status: Active » Postponed (maintainer needs more info)
markusa’s picture

markusa commented
Status: Postponed (maintainer needs more info) » Needs work

Another idea would be a Core patch that would dispatch a Symfony event when an extension is disabled, then have a D9 event subscriber that could listen for that and clear caches.

This would not work with Drupal 7 though, because no Symfony there.

Drupal needs a "needs patch upstream" status for their issue queue

elisseck’s picture

elisseck commented

Re: #6 - Not sure if this falls into a weird edge case or not but I just ran into this issue without CiviGrant enabled (I do not believe this site has ever used CiviGrant).

- Drupal 9.4.1
- CiviCRM 5.49.5

CiviCRM Entity code existed but was not previously installed. Click "Install" in the GUI leads to the WSOD on every page until files are removed or the SupportedEntites code is commented out for CiviGrant as outlined above. The patch in #7 does work fine in this case since the organization is not using CiviGrant.

markusa’s picture

markusa commented

Are you using CiviCRM Entity 3.3?

elisseck’s picture

elisseck commented

@markusa yes, this is required as "drupal/civicrm_entity": "^3.3". Not sure why that site is acting up yet but thought it might be useful to know and I can dig into the specifics if it would help you.

I could not, however, reproduce this morning with a clean site i.e. something like this appears to work fine:
`civibuild create d9clean --type drupal9-clean --url http://d9clean.localhost --civi-ver master`
`composer require drupal/civicrm_entity`
`drush en -y civicrm_entity`

markusa’s picture

markusa commented

It would be interesting to see if this condition continues to manifest in 5.51

I had tested the patch by upgrading from 5.45 to 5.48 with CiviCRM Entity enabled
and enabling / disabling the CiviGrant extension .. and it seemed to go fine in my tests.

I did not test trying to install CE into a new site with Civi 5.48 or 5.49 instance fresh. But you say it works fine on a new, clean site. Since you are using master branch, its possible something in Civi has been updated.

For it to error on install, Civi 'entity' api 'get' action must say that Grant is an available entity, but the other necessary files that provide that entity type must not be discoverable. I need a better way to tell.

IDK if upgrading your site from 5.49 to 5.51 is an option for you.

elisseck’s picture

elisseck commented

Ah the fail condition is good info I can check what's going on there, and i'll let you know what happens when this site gets upgraded. I think they'll get the August release unless there is a security release in the next couple weeks.

elisseck’s picture

elisseck commented

@markusa well I was pretty wrong about the upgrade schedule for this particular site for a number of reasons, but I am confirming that this issue went away i.e. I can remove the patch from #7 and not WSOD the site any longer once CiviCRM was upgraded to 5.52.3.

Thanks! It's possible this could be closed for now if the expectation is that people are up-to-date.

markusa’s picture

markusa commented
Status: Needs work » Fixed

For future searchers .. we also found that its better to either have the CiviGrant enabled or disabled.
If upgrading a version where CiviGrant is already an extension, better to have installed, or uninstalled, but not "disabled"

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.