3

With Drupal 8 + CiviCRM 5.30.1

The asset builder is unable to find the crm-menubar.css file, i.e. this url:

https://example.org/civicrm/asset/builder?an=crm-menubar.css

gives me:

Unrecognized asset name: crm-menubar.css

[after updating /Civi/Core/AssetBuilder.php to catch the error, previously it was generating error pages]

Any thoughts about how to debug this? I've checked and re-checked the urls/paths and everything else seems to be found properly. I see the crm-menubar.css file in the locations I would expect ...

The Drupal asset injector is installed - is it possible that might be interfering?

1
  • I've been able to reproduce this on another site as well, both were upgraded from earlier, but not a lot earlier, versions, and both use the now-standard composer installation methods (drupal-recommended + the four civi requires, i.e. not the roundearth method). – Alan Dixon Oct 23 '20 at 13:26
5

Answer to the Issue

The origin of the problem is when you ignore this: https://civicrm.org/blog/daved/action-required-drupal-8-installs-and-upgrades-composer-and-patches

To fix an existing installation which was upgraded or installed without the 'enable-patching' configuration, you can can do this:

composer config 'extra.enable-patching' true
composer update civicrm/civicrm-asset-plugin civicrm/civicrm-core civicrm/civicrm-drupal-8 civicrm/civicrm-packages  --with-dependencies

Original Post

I figured out that if you run

composer config 'extra.enable-patching' true

straight after

composer create-project ...

installation is going to work.

Background: We have a scripted install which worked fine with 5.28.4 so I thought to upgrade to 5.30.1 but got the following message at

cv upgrade:db
vendor/bin/cv upgrade:db
Found CiviCRM database version 5.28.4.
Found CiviCRM code version 5.30.1.
Checking pre-upgrade messages...
_Pre-announcement for upcoming version 5.30_: If your composer
configuration or composer.json does not enable patching, you MUST do that
BEFORE running composer to update your files to version 5.30. Either by
using `composer config 'extra.enable-patching' true`, or updating the top
level composer.json's extra section with `"enable-patching": true`. See
Drupal 8 installation guide [1] for details.
The default copies of the message templates listed below will be updated to
handle new features or correct a problem. Your installation has customized
versions of these message templates, and you will need to apply the updates
manually after running this upgrade. Click here [2] for detailed
instructions. 

    * _Events - Registration Confirmation Invite_ - Support negative hours for
cancellation/transfer
    * _Events - Registration Confirmation and Receipt (on-line)_ - Support
negative hours for cancellation/transfer

The default copies of the message templates listed below will be updated to
handle new features or correct a problem. Your installation has customized
versions of these message templates, and you will need to apply the updates
manually after running this upgrade. Click here [2] for detailed
instructions. 

    * _Contributions - Invoice_ - Ensure that amount paid is shown even when
fully paid



Links:
------
[1] https://docs.civicrm.org/installation/en/latest/drupal8
[2] https://docs.civicrm.org/user/en/latest/email/message-templates/#modifying-system-workflow-message-templates

I hope that helps.

3
  • Thanks, that seems useful. Any idea what gets patched? i.e. if I've upgraded without that already, what's the patch that would need to be applied? – Alan Dixon Oct 26 '20 at 21:53
  • If you upgraded to 5.30 without it, and you have "mysql:" in your DSN strings, you would notice right away since it wouldn't be able to connect to the database. See also civicrm.org/blog/daved/…. If you did upgrade and that happened, then enable patching and run composer install and hopefully should get back on track. But that seems different from the original asset issue here. – Demerit Oct 28 '20 at 1:40
  • Thanks for the enable-patching note. I've confirmed that I can do the composer config after the fact and then run composer update on the four civicrm required packages with dependencies - that will re-install and patch approx. 10 packages. Logging in again and it's now working! – Alan Dixon Oct 28 '20 at 13:34
0

We had the same problem - I think it came down to CiviCRM being installed incorrectly.

This is how the files sit in the now working copy:

user@server /var/www/html/site/drupal $ find -type d -name civicrm
./web/modules/contrib/civicrm
./web/sites/default/files/civicrm
./web/sites/all/modules/contrib/civicrm
./web/libraries/civicrm
./vendor/civicrm
user@server /var/www/html/site/drupal $ ls -l web/modules/contrib/civicrm
total 212
-rw-rwxr--+  1 user dev  1686 Aug 21 09:50 civicrm.config.php.drupal
-rw-rwxr--+  1 user dev   275 Aug 21 09:50 civicrm.info.yml
-rw-rwxr--+  1 user dev  5386 Aug 21 09:50 civicrm.install
-rw-rwxr--+  1 user dev   102 Aug 21 09:50 civicrm.libraries.yml
-rw-rwxr--+  1 user dev   134 Aug 21 09:50 civicrm.links.menu.yml
-rw-rwxr--+  1 user dev   346 Aug 21 09:50 civicrm.links.task.yml
-rw-rwxr--+  1 user dev 11690 Aug 21 09:50 civicrm.module
-rw-rwxr--+  1 user dev    73 Aug 21 09:50 civicrm.permissions.yml
-rw-rwxr--+  1 user dev   866 Aug 21 09:50 civicrm.routing.yml
-rw-rwxr--+  1 user dev   471 Aug 21 09:50 civicrm.services.yml
-rw-rwxr--+  1 user dev  2492 Aug 21 09:50 civicrm.user.inc
-rw-rwxr--+  1 user dev   765 Aug 21 09:50 composer.json
-rw-rwxr--+  1 user dev   649 Aug 21 09:50 COPYRIGHT.txt
drwxrwxr-x+  2 user dev  4096 Aug 21 09:50 css
drwxrwxr-x+  2 user dev  4096 Aug 21 09:50 drush
drwxrwxr-x+  6 user dev  4096 Aug 21 09:50 icons
-rw-rwxr--+  1 user dev 35147 Aug 21 09:50 LICENSE.txt
drwxrwxr-x+  3 user dev  4096 Aug 21 09:50 modules
-rw-rwxr--+  1 user dev  2989 Aug 21 09:50 README.md
drwxrwxr-x+ 10 user dev  4096 Aug 21 09:50 src
drwxrwxr-x+  2 user dev  4096 Aug 21 09:50 templates
user@server /var/www/html/site/drupal $ ls -l vendor/civicrm/
total 48
drwxrwxr-x+  5 user dev 4096 Oct 19 11:51 civicrm-asset-plugin
drwxrwxr-x+ 25 user dev 4096 Oct 19 11:51 civicrm-core
drwxrwxr-x+  6 user dev 4096 Oct 19 11:51 civicrm-cxn-rpc
drwxrwxr-x+ 30 user dev 4096 Oct 19 11:52 civicrm-packages
drwxrwxr-x+  4 user dev 4096 Oct 19 11:51 composer-downloads-plugin
drwxrwxr-x+  5 user dev 4096 Oct 19 11:52 cv

Hope that helps.

if you need any more let me know.

7
  • I am seeing exactly the same problem after updating from CiviCRM 5.29.1 to 5.30.0 and then 5.30.1. My file layout looks like the one above though web/sites/all/modules/contrib/civicrm was empty. I assume crm-menubar.css should be here: <drupal_site>/vendor/civicrm/civicrm-core/css/crm-menubar.css. What else am I missing? – Stephen Palmstrom Oct 23 '20 at 10:33
  • I don't think you are missing anything, I believe there's a bug. – Alan Dixon Oct 23 '20 at 13:20
  • I tried a fresh install following the instructions, but still see the same issue. I see it has been reported as a bug and claims to have been solved (lab.civicrm.org/dev/core/-/issues/2137) but I am still unclear how. Enabling patching in composer gives a string of 'Could not apply patch!' errors, presumably because the modules in question have already been patched. – Stephen Palmstrom Oct 30 '20 at 10:29
  • I've done some more investigation - A Drupal7 installation was fine. I did a fresh install of Drupal 9 and CiviCRM. No problem except for an error message about text/html mime type in the browser console. I then changed the locale from en-US to en-GB, and lo and behold, the issue surfaced. I had unpacked the localisation files before doing that. – Stephen Palmstrom Nov 5 '20 at 18:41
  • To replicate the above issue, all that was needed was to save the localisation information with no change, i.e. the locale change was a red herring. I'm not expert enough in the inner workings of CiviCRM to determine exactly what is happening, this call is where the error is thrown: \CRM_Utils_Hook::buildAsset($name, $params, $mimeType, $content); if ($mimeType === NULL && $content === NULL) { throw new UnknownAssetException("Unrecognized asset name: $name"); } The $mimeType and $content variables are both null on entering and exiting the buildAsset function. – Stephen Palmstrom Nov 6 '20 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.