Drupal8: Clear Drupal caches after enabling extension

After enabling an extension (e.g. KAM) new menu callbacks are registered in civicrm_menu but not in Drupal, resulting in a 404 Not Found error when visiting pages provided by the extension. Manually clearing the Drupal cache fixes this.

I suspect that Drupal caches are not being adequately cleared by CiviCRM, which is probably a low-level problem affecting more than just this.

Hi @colemanw - I encountered this problem recently and have some notes. @jackrabbithanna was also helpful in suggesting a fix, see this chat: https://chat.civicrm.org/civicrm/pl/1wx7dwxhppbiun7jjqdfztoymc

Here are my notes about how I think this problem can be replicated:

• Create an extension with two new routes: civicrm/foo and civicrm/bar/baz.
• On install, civicrm/foo will load; civicrm/bar/baz will not.
• Clear DRUPAL cache; civicrm/bar/baz should load.

I was also wondering what happens if I uninstall the extension without clearing D8 caches?

Ok I think I've got a better grip on what's going on.

CMS caches do not get cleared by CiviCRM; not when installing an extension, not when clearing the Civi caches, basically not ever - the only time I see a call to $config->userSystem->flush() is after performing an upgrade.

So why, you might ask, does menu caching not affect other systems? Well I think it's because all the paths we're talking about start with civicrm/. That tells Drupal 6 & Drupal 7 to go ahead and hand the request off to CiviCRM because they've already got civicrm/ registered in their menu and they don't care about the rest of the path string. WP and J! don't care either, because both of them get explicitly told to hand the request off to CiviCRM in their url arguments, they don't handle the routing at all.

Based on your report @JonGold it looks like D8 behaves a little differently than previous versions. It seems tolerant of one extra argument in the path but not two. So I'd hazard a guess that if your extension registered a path called civicrm/contact/view/who then it would work (because the civicrm/contact/view path already exists) but civicrm/contact/view/who/else would not work until D8 caches were cleared.

So what to do?

1. One solution is to explicitly clear CMS caches when un/installing an extension.

2. Another solution would be to investigate whether Drupal paths can be configured to be more forgiving of extra arguments, and try to register the /civicrm path as a "catch all" - this would mimic the behavior of D7 (which I believe has the same problem for any path that doesn't start with civicrm/).

mentioned in issue #105 (closed)

If we went with option 1 should this occur before or after the call to hook_civicrm_postInstall?

A bit related, there were some interesting details here about how Drupal8 routes work: https://github.com/civicrm/civicrm-drupal-8/pull/41 (users of d8 may have noticed that frontend page titles are often wonky).

For what it's worth, I would recommend clearning the d8 cache as late as possible, i.e. presumably after postInstall, because the cache-clear sometimes crashes mysteriously.

marked #105 (closed) as a duplicate of this issue

Merging bits from #105 (closed):

@johnk mentioned using this snippet after enabling extensions

drush ev '\Drupal::service("router.builder")->rebuild();'

@MikeyMJCO recommended:

\Drupal\Core\Cache\Cache::invalidateTags(['route_match']);

and Mikey wondered whether the d8 civi module can listen to civi symfony events. More details in #105 (closed).

mentioned in issue extensions/civirules#100 (closed)

mentioned in merge request extensions/cdntaxreceipts!117 (merged)

mentioned in issue #158 (closed)

marked this issue as related to #158 (closed)

I have created a quite similar issue (#158 (closed)) with a PR (See: https://github.com/civicrm/civicrm-core/pull/19888) This PR rebuilds the drupal router when the civicrm menu is rebuild.

Fixed by PR 19906 thanks @jaapjansma for putting this back on my radar!

mentioned in commit core@a11c1084

closed