Upgrading to 5.27 hits fatal errors getting to the upgrade screen

@eileen are you using https://github.com/mecachisenros/woocommerce_civicrm or is it a custom integration?

OK I reproduced with https://github.com/mecachisenros/woocommerce_civicrm. I must add Woo to the testing sites....

I'll test the patch and report back.

mentioned in commit a400890c

Note we added patches that resolved this but I'm leaving this open for visibility in case there are other ways this can be experienced.

I do not have woocommerce installed. Nor any other checkout module. But as soon as I replace the latest code base with 5.27, my site breaks with following error. Cleared cache doesnt help either.

Error: Class 'Civi\Api4\Event\Subscriber\ContactSchemaMapSubscriber' not found in CachedCiviContainer->getCiviApi4EventSubscriberContactschemamapsubscriberService() (line 426 of /home/webadmin/public_html/cmm-uat/sites/default/files/civicrm/templates_c/CachedCiviContainer.69c33a1bd2c1b046653ce2f7b8bfb2a5.php).

@tapash this file is a cache

/home/webadmin/public_html/cmm-uat/sites/default/files/civicrm/templates_c/CachedCiviContainer.69c33a1bd2c1b046653ce2f7b8bfb2a5.php

and if you can delete it it may help? (Although I think clearing caches should have deleted it?)

@eileen I was talking with @haystack this morning about this. Is there any reason we don't clear caches as the first step of the upgrade? I do this using command line, but why not add to the UI?

ContactSchemaMapSubscriber.php was removed from 5.26=>5.27. The class is a "subscriber" which (long-story short) means that (in 5.26) it was loaded on every page-view (in order to run getSubscribedEvents()). This requirement gets compiled into CachedCiviContainer.

The CachedCiviContainer should have a built-in freshness check - if a file like that changes or disappears, then it recompiles the CachedCiviContainer. For some reason, that didn't happen. Some possibilities:

There is a bug circa CRM_Api4_Services::loadServices(). This file creates $resource objects are basically hints for the freshness check. (Every $resource is checked during a freshness test.)
The hidden option CIVICRM_CONTAINER_CACHE has been set to always, which bypasses the freshness check.
Maybe the file was not web-writeable and couldn't be deleted automatically?
If the new codebase was crashy, then maybe they switched back to the old codebase, cleared cache on the old codebase, and then switched to new codebase. This would not work since "cache clear" isn't really a clear operation - it's more of a reset or rebuild operation.

I've just posted a possible workaround here: https://github.com/civicrm/civicrm-core/pull/17740

@kcristiano We posted at the same time :) #17740 should have the effect of clearing the container-cache pre-emptively during upgrade (ie the new version will use a different cache file).

Thanks @totten @haystack mentioned doing it similar to the way https://github.com/christianwach/civicrm-admin-utilities does

public function clear_caches() {

		// Bail if no CiviCRM.
		if ( ! $this->plugin->is_civicrm_initialised() ) return;

		// Access config object.
		$config = CRM_Core_Config::singleton();

		// Clear database cache.
		$config->clearDBCache();

		// Cleanup the "templates_c" directory.
		$config->cleanup( 1, true );

		// Cleanup the session object.
		$session = CRM_Core_Session::singleton();
		$session->reset( 1 );

		// Call system flush.
		CRM_Utils_System::flushCache();

	}

Changed of course to be CMS independent, but clearing everything

Hmm, yeah, I see the value in cleaning up even more of those caches pre-upgrade, and the civicrm/upgrade page does some of that pre-upgrade cache-clearing, but I'm not quite seeing how we'd get that kind of snippet to address the last reported problem.

Here's one issue. Consider a shorter subset of that logic: just call CRM_Core_Config::singleton()->cleanup(1, true) to delete templates_c/* (w/CachedCiviContainer.XXX.php etal). The call to singleton() means that it's going to boot the system (instantiate the container, run a few hooks, etc). The attempt to delete CachedCiviContainer.XXX.php will require loading CachedCiviContainer.XXX.php first. Chicken<=>egg.

What #17740 does is to tie the value of XXX to the installed version. As soon as you get newer code (ie as soon as xml/version.xml changes), the XXX changes (ie XX1 => XX2). If something calls CRM_Core_Config::singleton(), it will ignore the old CachedCiviContainer.XX1.php and use a newer CachedCiviContainer.XX2.php.

Of course, it is also a good idea to clear all those other things during upgrade - and 17740 doesn't speak that.

I agree, I just took a function used in Admin Utilities, which runs this from WP so it has to do all that.

I'd like to:

CRM_Core_Config::singleton()->cleanup(1, true);
CRM_Core_Config::singleton()->clearDBCache();
CRM_Utils_System::flushCache();

Are we going too far, being redundant?

mentioned in commit 00486d04

mentioned in commit 89fa20c8

@kcristiano @totten is this closable now - I feel like we have merged but maybe not dropped related fixes

changed milestone to %5.27.1

Closing - https://github.com/civicrm/civicrm-core/pull/17740 resolved I believe

closed

@colemanw @eileen I hit another issue related to this on one of our sites.

On 5.26.2 trying to upgrade to 5.27.2

With current release 5.27.2

[21-Jul-2020 12:32:06 UTC] PHP Fatal error:  Uncaught Error: Class 'Civi\Api4\Event\Subscriber\ContactSchemaMapSubscriber' not found in /srv/www/site/wp-content/uploads/civicrm/templates_c/CachedCiviContainer.d25332a03004d13cd6fc168d22df6b6a.php:449

then I tried 5.27.2 + https://github.com/civicrm/civicrm-core/pull/17876

[21-Jul-2020 12:38:23 UTC] PHP Fatal error:  Uncaught CiviCRM_API3_Exception: [no such field: DB Error: no such field thrown in /srv/www/site/wp-content/plugins/civicrm/civicrm/api/api.php on line 133

Temporarily commenting out lines 132-134 allowed the upgrade to complete. Not a slution at all.

After this upgrade to 5.28RC was successful as well.

A direct upgrade to 5.28 RC (build from this morning:

Fatal error: Uncaught CiviCRM_API3_Exception: [no such field: DB Error: no such field thrown in /home/site/www/dev/wp-content/plugins/civicrm/civicrm/api/api.php on line 133

Upgrading to 5.27 hits fatal errors getting to the upgrade screen

Child items ...

Activity