We tried this solution as well as all others listed in
🐛
Consider to remove exception handling from search_api_views_data
Needs review
. Unfortunately, nothing helped. The issue indeed occurs not always and seems like it is related to site visitors' activity.
In our particular case we not even using Search API views, the issue is triggered by a decouple request to the Drupal backend. So we are going to try to fix it on the upper level by avoiding calling hook_views_data or something like this. But It's interesting to know how it eventually ends up.
Thanks @nicolas bouteille for sharing your findings.
Hi folks, we have exactly the same issue as described in #16.
@nicolas bouteille have you eventually solved the issue for your project?
Hi folks, the MR has been prepared, please review it.
iamdroid → created an issue.
Thanks @carlos romero,
It is very helpful and works as expected.
Hi folks, thanks for your work on this.
Patch from #5 works for me as well.
Please provide steps to reproduce it, otherwise, I can only guess what is wrong.
Thanks @beloglazov91 great work, happy to merge it.
Click on the link element in the menu closes the drawer, true, and it is expected behavior. It is made so for handling anchor links on the same page. If your menu item is not intended to lead the user to another location but is intended for only expanding and collapsing the submenu, it shouldn't be a link element. It should be a span
element instead and clicking on it won't close the drawer. To render the menu item as the span
element you can use <nolink>
as the link target.
Mixed menu elements, which can act as a link and have an additional dropdown button, are currently not supported by the Drawer component.
If it does not solve your issue still, please provide more details about your setup or how to reproduce the issue.
Just tested it again and noticed that the state of the checkboxes is not actually saved.
Hi folks. I've reviewed the code and tested the actual behavior, everything looks good. Thanks.
Changing to RTBC.
The issue looks solved by [3463796]. Attaching the screen recording.
Thanks for the review, @yannick bloemen , I've added a small fix for the initial focus state when the radio is not yet checked.
Hi folks, I am going to check 🐛 Ensure sticky action buttons to work with modals and ajax refresh-calls Needs review actually solve this issue.
iamdroid → made their first commit to this issue’s fork.
Hi @janc48,
First of all, if you are using version 2.x, I'd recommend to upgrade to 3.0.0. It is much more stable and doesn't require additional actions to update.
The next step is to check the doc for the navbar and for the drawer or overlay, depending on the mobile menu style.
Basically to make it work 3 steps need to be done:
- Put a toggle button in the Navabar region
- Put a menu block into the drawer/overlay region
- Hide desktop navigation for small screens in any way you like (CSS, JS, block class, whatever)
As an example for step 1, you can check this template.
Make sure the button has class overlay-open__button
or drawer-open__button
depending on the mobile menu style.
Good luck.
Hi folks.
Here is a reroll of #9 against 2.0.4.
Hi.
According to what I see in the video, MDC elements are not initialized and therefore are not working.
It may happen for multiple reasons. The most common reasons are:
- JS errors caused by custom JS code
- not attached JS libraries
- misconfiguration of
YOURTHEME/scss/mdc/components.scss
file - issues during theme building
The best way to avoid most of these errors is to generate your theme with a subtheme generation script, according to this doc, have you done it?
There is a point to continue. I added #3 and #4 to be 100% sure nothing is blocking #5 and the rest of the commands.
The main commands are #1, #5, and #7.
Hi.
The root of the issue is material_stable9
is a hidden theme, so it can't be uninstalled via appearance page, usually.
Could you please try this:
composer require 'drupal/material_base:^3.0'
drush cr
drush thun material_base_mdc
drush thun material_base
drush thun material_stable9
drush cr
drush cron
composer removee drupal/material_base
Hope it helps.
Merged into 2.x.
iamdroid → created an issue.
Hi. This is a dupe of #3316641: Replace "Stable" base theme → which was merged into 2.x-dev.
But I would recommend using 3.0.0-beta1 straight away.
The root of the issue is that the stable theme was removed from the core but stable9 is still there. The reference was fixed in stable9. However in 2.x we used an alternative approach and used our own copy of that theme, which turned out wrong decision. And it is a good example of why it was a wrong decision since didn't receive the fix automatically when it was fixed in stable9. In 3.x branch we moved back to core's stable9 theme.
Hi Folks,
Thanks for your work, this patch has been merged.
@codedrill if you still have an issue with Anu, it should be addressed on the Anu side. Feel free to create an issue there.
Thanks @elaman for working on this, looks great, merged.
Here is the patch.
iamdroid → created an issue.
Hi @jkdev,
Have you tried to update to v3 → ?
material_stable9
theme had been removed from dependencies in favor of core's stable9
. Hope it helps.
Hi folks, thanks for checking this.
We will review the patch soon. Seems like we will need a new release without Drupal 8 support.
Related change record Context argument added in code that extends from Symfony's Serializer component → .
Thanks for checking this.
Closing as a dupe of 🐛 Issue with supportsNormalization declaration RTBC .
Hi @linno,
If I am understanding you right, to achieve that you just need to unset max-width
for main-content__container
class.
Hi @linno,
It is hard to understand the problem of overriding, without seeing the code. But what I can definitely say, if you need to replace the library or file with your file, it needs to be done the way I described in the previous post, in THEMENAME.info.yml
file.
If you just need to add some CSS files to the website, then yes, it can be done in THEMENAME.libraries.yml
.
By the way, it is a bad practice to change files of the base theme, I'd recommend creating your own custom theme and putting your changes there. You can find how to create a custom theme based on Material base here.
Regarding layout, it is expected behavior for page_layout = TRUE
. In this mode, the only content region is rendered. It is designed for cases when the page layout is controlled by some other way than regions, like, Views, Layout builder, and so on.
Probably I could recommend something if you would explain what are you trying to achieve.
Hi @linno,
To override some library or file in your custom theme it needs to find the definition of that library first.
Seems like you are trying to override we_megamenu_backend.css
file, right? If so, it is defined in we_megamenu.libraries.yml
file in we_megamenu
module folder. The definition is:
form.we-mega-menu-frontend: version: 1.0 css: theme: assets/includes/bootstrap/css/bootstrap.min.css: {} assets/css/we_megamenu_backend.css: {} # ...
To override it, in your theme's info file (THEMENAME.info.yml
) needs to place something like this:
libraries-override: form.we-mega-menu-frontend: css: theme: # here dist/css/we_megamenu_backend_custom.css is relative to your custom theme folder. assets/css/we_megamenu_backend.css: dist/css/we_megamenu_backend_custom.css
I hope you got the logic, here you can find more info drupal.org/node/2497313 →
Second question answer
To use a full-width layout basically the only thing that needs to be done is to set the TRUE
value for page_layout
variable in the corresponding page.html.twig
file.
There are multiple options for how exactly it can be done. For example, if you need to have this feature for all pages of the website, you can do it directly in page.html.twig
file in your custom theme by putting this somewhere at the top of the file:
{% set page_layout = true %}
If you need this only for specific pages you can either create additional page templates based on template suggestions or pass the value of page_layout in the preprocess function:
/** * Implements hook_preprocess_page() for page.html.twig. */ function THEMENAME_theme_preprocess_page(array &$variables) { // Some condition. if ($SOMETHING) { $variables['page_layout'] = TRUE; } }
iamdroid → made their first commit to this issue’s fork.
Hi @Nchase, @jwwj are you already on Drupal 10?
The error looks like an incompatibility with Symfony from Drupal 9.x.
You can use the patch from #2 to prepare the codebase for the Drupal 10 upgrade. After the upgrade, the patch from #10 can be applied.
Thanks a lot @beloglazov91,
The fix has been merged into 2.x.
Thanks a lot @beloglazov91,
The fix has been merged into 2.x.
Thanks a lot @dastan56,
Your fix has been merged to dev version.
Hi folks,
Here is a re-roll of #9 against the latest dev.
Thanks.
Hi folks,
Thanks for your work here.
Here is a re-roll of #24 against 1.0.0.
Also, I added a couple of guard conditions for fieldset suggestions since recently we faced these warnings on one of our projects.
Warning: Undefined array key "#type" in themable_forms_theme_suggestions_fieldset_alter() (line 73 of modules/contrib/themable_forms/themable_forms.module). ... Warning: Undefined array key "#type" in themable_forms_theme_suggestions_fieldset_alter() (line 76 of modules/contrib/themable_forms/themable_forms.module).
Thanks @malcomio,
I've reviewed and tested your MR, it works like a charm!
RTBC. Let's probably wait for at least one more comment and update the status then.
Hi @coaston,
I just double checked on a fresh Drupal installation, and you are right, it didn't work out of the box.
Initially, I tried it on the working project which already has oomphinc/composer-installers-extender
plugin installed. Also, it somehow depends on the installer-types
option which seems unrelated at all but without it, nothing is working.
So the complete setup looks like this:
composer require oomphinc/composer-installers-extender
- update
composer.json
by adding
"extra": { "installer-types": [ "npm-asset", "bower-asset" ], "installer-paths": { "web/libraries/{$name}": [ "jjj/chosen" ], } }
composer require jjj/chosen
No need to do steps 1 and 4 from your list.
I have to admit that the full setup looks more or less like previously suggested options in terms of complexity unless you already using composer-installers-extender
for managing npm and bower assets.
And it is odd it is not working out of the box because it is what the official doc said https://www.drupal.org/docs/develop/using-composer/manage-dependencies#installer-dirs
Good luck.
Hi folks,
Thanks for the suggestions. From my end, I'd like to share an even simpler solution: since jjj/chosen
is already available as a composer package there is no need to specify any repository for it. The only thing left to do is to specify the path to the libraries folder, like this:
"extra": {
"installer-paths": {
"web/libraries/{$name}": [ "jjj/chosen" ]
}
}
and then run composer require jjj/chosen
Hi @Promo-IL, thanks for reporting this.
I tried to reproduce this but saw nothing similar.
Could you please provide more info on how exactly you are getting this error? Basically which base/custom theme structure do you have?
The patch for the entity reference revision module. It looks too custom to put it directly in the ERR module issue, but we need to store it somewhere for referencing in composer.json
.
iamdroid → created an issue.
Hi @rv0, thanks for this report.
Long story short the proper solution is enabling the Stable 9 theme.
It is a Drupal Core theme but hidden from the theme list.
It should be enabled automatically during the initial installation of the Material Base 3.x theme or during updating the theme but only for Drupal 9.4+ (starting 9.4 themes support post-update hooks).
It is hard to say why exactly Stable 9 remains disabled in your case, did you run the update script after updating the theme? Also, you could double-check stable9
exist in the configuration (core.extention.yml
). In any case, you can just enable Stable 9 via Drush and it should solve everything. material_stable9
is supposed to be removed in further versions, so it shouldn't be enabled.
Good luck!
Hi folks, thanks for working on this.
I've tested MR!50 - it works!
+1 for RTBC.
Hi @Dubs, Thanks for this.
I've reviewed the patch, it has been applied smoothly, code changes look good, the module works normally, and no problems were found.
RTBC
Hi there. Thanks for the patch and review but I am afraid you wasted your time.
First, it looks like the theme style weren't properly applied. So it is either the wrong base theme or misconfiguration in theme.scss or styles weren't actually compiled.
Please check docs/subtheme-template.md for reference.
If everything is done in accordance with the doc and the problem still appears, then please provide steps to reproduce the error and reopen the issue.
Second, the provided patch removes Drupal's functional element. The button just won't work without it.
p.s. With proper configuration the button should look like this
Hi @craigkendall, thanks for reporting this.
Downloading themes (or modules) by Composer doesn't automatically install them. And removing themes by Composer doesn't automatically uninstall them from Drupal as well.
What put these themes to core.extension
is not a Composer but Install (or Install and set as default) action on the Appearance page (or enabling theme by Drush).
To get rid of unnecessary themes you have to do Uninstall action on the Appearance page (or do it by Drush) before removing the theme by Composer.
The same way as any other theme, by the way.
But you are absolutely right regarding material_stable9
, this theme is hidden and can't be uninstalled from the Appearance page. To uninstall this theme you either have to remove hidden: true
property from material_base/themes/material_stable9/material_stable9.info.yml
to make it visible on the Appearance page or uninstall it by Drush: drush theme-uninstall material_stable9
. This bit is not yet documented anywhere because I still have doubts regarding using own instance of the Stable 9 theme, it may be subject to change.
Spleshka → credited iamdroid → .
Spleshka → credited iamdroid → .