callinmullaney → created an issue.
We applied patch #14 to a recent project and ran into the same error that jrockowitz reported. We also noticed it occurs when a mix of plain text and formatted text fields are loaded in the same form. We opted to use a general `parentNode` to select the format wrapper for all fields instead. This might not be the preferred approach but it does seem to resolve the error and continue working for all previous field types.
I've also updated the available symfony submodules to 6.4.9 and initially things seemed to be work fine on Pantheon. But with some additional testing over a couple of days we're also running into an error related to caching as reported above. If a login attempt doesn't occur for awhile there is the following error:
The router "Symfony\Component\Routing\Router" cannot be warmed up because it does not implement "Symfony\Component\HttpKernel\CacheWarmer\WarmableInterface".
Refreshing the page and attempting again clears out the error and things work but only until some time passes again and another login is attempted.
The 8.x-3.x version of Emulsify (patternLab) has been unsupported for a long time and has since been moved to Storybook. Due to the age of the issue and the recent upgrade to 5.x for this namespace I'll be closing this issue.
The 8.x-3.x version of Emulsify (patternLab) has been unsupported for a long time and has since been moved to Storybook. Due to the age of the issue and the recent upgrade to 5.x for this namespace I'll be closing this issue.
The 8.x-3.x version of Emulsify (patternLab) has been unsupported for a long time and has since been moved to Storybook. Due to the age of the issue and the recent upgrade to 5.x for this namespace I'll be closing this issue.
The 8.x-3.x version of Emulsify (patternLab) has been unsupported for a long time and has since been moved to Storybook. Due to the age of the issue and the recent upgrade to 5.x for this namespace I'll be closing this issue.
Thank you @Nigel Cunningham for bringing this to my attention! We had this fixed in 4.9.1 release on our github but wasn't pushed to Drupal. I updated the release and composer should be working for you now.
laura.j.johnson@gmail.com → credited callinmullaney → .
Thank you for the quick response!
callinmullaney → created an issue.
callinmullaney → created an issue.
@josue2591's patches works pretty well. However, I found that the horizontal toolbar still needs to be accounted for. The following CSS did the trick:
[data-fullscreen=fullscreeneditor] .ck .ck.ck-sticky-panel .ck-sticky-panel__content {
top: 0 !important;
}
.toolbar-horizontal [data-fullscreen=fullscreeneditor].ck.ck-editor,
.toolbar-horizontal [data-fullscreen=fullscreeneditor] .ck .ck.ck-sticky-panel .ck-sticky-panel__content.ck-sticky-panel__content_sticky {
top: var(--gin-toolbar-y-offset) !important;
}
[data-fullscreen=fullscreeneditor] .ck .ck.ck-editor__editable {
max-height: 100%;
}Note: The solution proposed in #8 does resolve the fullscreen bug reported in this issue. However, remove this top styling would then break the sticky offset happening when it is not in full screen. See attached screenshot for clarification.
ltrainjohnson → credited callinmullaney → .
Thank you @Koustubh Dudhe and @generalredneck - I updated our d.o tags and linked 4.5.0 as our latest release which has D10 support.
volkswagenchick → credited callinmullaney → .
mherchel → credited callinmullaney → .
@hctom I think I'm having a similar issue to the one described above. The selected view modes are not available on the field edit page. There is a `View modes allowed to switch to` field that is set to required but there are no options to select any and the default value select list is empty and only says `-no-change-`.
Using the most recent version of Drupal 9.5.x and the latest version of the module you should be able to do the following to reproduce.
1. Create a paragraph with 3 view modes. default, custom_a, custom_b and make sure they are enabled for said paragraph.
2. Add the view_mode_switch field to the paragraph and select either all view modes or just the custom ones on the field_settings page.
3. On the following field_edit page the previously selected view_modes are not available in the default field value section. Attempting to save the field_settings page results in a drupal message of " View modes allowed to switch to field is required. "
heatherwoz → credited callinmullaney → .