Thanks for the reply. For now I'm downgraded back to the previous version. When i get a chance, I'll try upgrading again on my local and post debugging info/ideas here.
I should add that this also broke the required by role functionality as well. On the editpage of the node, fields that should not have been required for admin were showing as required.
Forced to roll back `drupal/required_api (3.0.0-beta1 => 2.1.0)`
And `drupal/required_by_role (2.0.0-beta2 => 1.3.0)`
Rolling back fixes for now.
robbdavis β created an issue.
Yes, this causes problems for css that previously used .navbar-nav.
The new template also forces 'flex-row' class on the menu (with !important). I have multiple footer menus that display as flex column and this breaks it. I was forced to rollback and put the old menu--footer.html.twig into my theme's template file.
This 'fix' is also bleeding into my theme. I've got many .view divs that are being displayed with flexbox. Forcing the .view into a display:block breaks the theme.
There is another issue dealing with this. This one should be closed. But the code to ignore the patch from #6 in that thread worked for me:
"enable-patching": true,
"patches-ignore": {
"drupal/lightning_core": {
"drupal/core": {
"2869592 - Disabled update module shouldn't produce a status report warning": "https://www.drupal.org/files/issues/2869592-remove-update-warning-7.patch"
}
}
},
"patches": {
Thanks for #6! patches-ignore in composer.json sorted it out!
I have the same issue. Unfortunately lightning is still so tightly interwoven with my site that I haven't been able to fully divest it. Now this patch from a module (ugh!) won't apply.
Just had a client stumble upon this and the custom maintenance page and text made no sense in the context of failed login. They asked for a separate message / theme for failed login.
A separate template option would be great.
As a hack, I used a path-name class in the the body and hid the maintenance stuff and displayed blocked login stuff based on whether the path was `path-login`.
One more piece of info. This is only happening when logged in when drupal's tabs are on the page (view/edit/ etc./).
OK this is definitely an issue with the jquery dependency.
Removing the jquery dependency and updating nav-tabs.js with vanilla javascript per this issue π Remove jquery dependency Fixed will fix.
robbdavis β created an issue.
I love the option of breaking out the bootstrap components. I think I'll borrow that.
As for bootstrap, an option in config to use a cdn or /libraries version (installed via composer?) would be awesome.
OK I tried using math.abs() but it wasn't working until I found you need to use @use 'sass:math' at the top of the file. Not sure how to create a patch file so here's the code that works for _theme.scss:
@use 'sass:math';
@each $state, $value in $theme-colors {
$alert-background: shift-color($value, $alert-bg-scale);
$alert-border: shift-color($value, $alert-border-scale);
$alert-color: shift-color($value, $alert-color-scale);
@if (contrast-ratio($alert-background, $alert-color) < $min-contrast-ratio) {
$alert-color: mix($value, color-contrast($alert-background), math.abs($alert-color-scale));
}
.color-#{$state} {
--#{$prefix}alert-color: #{$alert-color};
--#{$prefix}alert-bg: #{$alert-color};
--#{$prefix}alert-border-color: #{$alert-border};
// @todo: remove .alert-link and enable line below when 5.2 is removed.
//--#{$prefix}alert-link-color: shade-color($alert-color, 20%);
.alert-link {
color: shade-color($alert-color, 20%);
}
}
}
I'm getting this warning too.
I set up gulp to trigger my sass watch. So not sure the error is due to the way I set up sass to compile or if this is a legitimate deprecation warning due to using the most recent version of sass?
Deprecation Warning: Passing percentage units to the global abs() function is deprecated.
In the future, this will emit a CSS abs() function to be resolved by the browser.
To preserve current behavior: math.abs(40%)
To emit a CSS abs() now: abs(#{40%})
More info: https://sass-lang.com/d/abs-percent
β·
6 β $alert-color: mix($value, color-contrast($alert-background), abs($alert-color-scale));
Same issue.
I hit this issue too. I had uninstalled some aqcuia lighting modules and entity browser. The permissions never got removed during the uninstall and after that I'd hit this error when trying to save permisions or unintall other modules.
I tried to manually remove the permissions from the roles config.yml. This solved the issue locally but on config import on a test eviro, the modules were deleted before the updated permissions imported and I hit this error again.
Looks like patch in #11 fixed the issue.
This is still an issue. We want all users landing at /user to be redirected to saml login. But we also want drush uli
to work for local environments or test environments where saml is not hooked up.
The patch in #13 does work and seems fine for us given that we won't enable 'allow default login'. But it it's certainly a hack. It would nice to just have a configuration option to make drush uli work.
With that enabled, you can scan all your custom modules. It will show you exactly where you need to add the new access checks.
Just fyi. That link above appears to be an application for a different module.
Seems obvious in retrospect but I lost an hour or more to not noticing that and hunting for why my style sheet wasn't loading in ckedtior5.
Yes. Thanks @justcladwell!
For those on Pantehon, fyi, in the config.php, you'll need to set the 'loggingdir' to null.
'loggingdir' => NULL,
#15 alone worked for me... for now.. we'll see if we still have issues and need #29
I am also seeing this issue. The above patches don't help. No errors in the console.
Any chance we can roll this into the dev version?
robbdavis β created an issue.
Thanks for this. Merge plugin stopped working on Pantheon and having the library disappear caused a few errors:
An error occurred during the execution of the Ajax response: The following files could not be loaded: //chosen.css
Getting the library back with the posted method fixed. So, yeah, this alternative method should be in the read me.
robbdavis β created an issue.
media_library_media_modify provides a media reference field that allows applying focal point just for that field. The concept is great but there is currently an issue where the user needs to view the preview in order to get the focal point to change.
Just did some more testing and the TLDR is that the only way the focal point change applies is if the preview image option is enabled AND the user actually previews the image.
If preview is not viewed, the changes do not apply.
This is on my local machine with caching off.
I am seeing this behavior also. I am using media-library_media_modify so that I can alter the focal point only on this particular reference field.
When I go to configure the block where this image exists, then try to change the focal point, the change only applies if I view the preview first.
This is still an issue.
I am also having trouble figuring out how to do this.
This is also broken with adminimal theme. Patch #3 fixes the issue.
I'm a Drupal developer who has never had to use a js framework. I know basic js and jquery but the writing is on the wall; I'm going to have to learn one of these frameworks soon. From what I've been reading, vue is the most accessible and possibly the best. This article for example:
Why you should leave React for Vue, and never use it again.
https://blog.sourcerer.io/why-you-should-leave-react-for-vue-and-never-u...