This is a duplicate of https://www.drupal.org/project/open_university/issues/3553209 → .
Closing this issue.
I've created a merge request that fixes this.
Instead of recreating the CSS file in the hook_rebuild() function, it's delayed until the file is needed in hook_css_alter() function.
To do this I pulled some common code into helper functions to help with readability and reducing duplicate code.
The generation function has been split into generation and cache clearing functions. This splits the responsibility of the functions and allows better control of the required operations.
So now the order of operations is as follows.
- Clear the cache (including
drush updb) simple_menu_icons_cache_flush()hook is called- This deletes any generated CSS files.
- Clears the CSS cache
So now the generated CSS is not available. When you then visit a page and the CSS is needed:
- The output CSS is changed with the
simple_menu_icons_css_alter()hook - The file name of the generated CSS is derived. If the file is absent, it is created.
- The generated CSS is added to the output code.
This defers the code generation to when it is required, meaning that the theme data is available for use.
john cook → changed the visibility of the branch 3.0.x to hidden.
I've been doing some research into this and I think I've found out what's happening.
In essence, hook_rebuild() is being called before hook_theme(). This means that the theme data isn't available when the css file is being generated.
This might cause other problems as well, because if the css can't be generated then the existing css file is deleted. This, in turn, removes the icons. I had to edit an icon to fix it.
I think I've got a fix but it's a bit large and I want to do some more testing before creating a branch.
mradcliffe → credited john cook → .
xjm → credited john cook → .
liampower → credited john cook → .
liampower → credited john cook → .
liampower → credited john cook → .
As a side note, I noticed this bug because I have /web as a symlink to /docroot after changing host providers.
I had problems applying the diff / patch using cweagans/composer-patches, with a segment being rejected in components.info.yml. This was due to versioning information added by the packaging script on Drupal.org. I manually added the two line change before testing. I don't see this being a problem once the issue has been merged.
I tested with just the patch to make sure that the duplicates are reported by default. As expected, the errors appeared in the watchdog log.
Then I tried again after adding $settings['components_ignore_duplicate_templates'] = TRUE; to my settings.php. After I cleared the cache and refreshed the same page, the errors are no longer logged.
Moving to RTBC.
I've tested the patch in #58 🐛 Blockmode "Auto" will not work in Drupal 8 with core's domready library Needs work and it works as expected.
I've check the patch and it doesn't appear that @dmsmidt's points in #43 🐛 Blockmode "Auto" will not work in Drupal 8 with core's domready library Needs work have been addressed. This will need to be done before this can proceed further.
I've tested
patch 2
✨
Select/Options formats in views as exposed filter
Needs work
/
MR 3
✨
Select/Options formats in views as exposed filter
Needs work
and the exposed component can be limited as desired. In my case the configuration looks like this:
This produced the filter like this:
I checked that the patch and the MR submitted the same code, which they do.
I also looked at patch 7 ✨ Select/Options formats in views as exposed filter Needs work . This reversed the configurability for the filter, so I would not recommend this patch. Although having the ability to define a dynamic range could be helpful in some cases. Maybe for another issue though.
The MR only add a new filter.
Setting to RTBC for the MR.
john cook → created an issue.
mradcliffe → credited john cook → .
mradcliffe → credited john cook → .
mradcliffe → credited john cook → .
john cook → created an issue.
Hi @gto1.
I think it's a problem with DDEV rather than Drupal CMS. I get the same error with a lot of the sites I run locally.
I find that running ddev start again fixes the issue. Mutagen doesn't take as much time to run the second time.
I know it's annoying, but it's a work-around that gets the site running while the DDEV folks find out what the problem is.
To get around this for now, commit 'f6ec3c8e6286b7fba880ca7a9d52f230e2b4df27' can be used.
```
composer require "drupal/facets:dev-3.0.x#f6ec3c8e6286b7fba880ca7a9d52f230e2b4df27"
```
john cook → created an issue.
john cook → created an issue.
jjchinquist → credited john cook → .