Patch in #2 works fine but we found issues in prod site were this file is cached by the browser. Please find attached a minor improvement patch, whcih adds an empty get query to avoid browser caching.
The Slider filter element is styled incorrectly in RTL pages.
Steps to reproduce
- Install a RTL language (e.g. Hebrew)
- Translate a page to the RTL language and add the exposed Slider filter
- Observer the slider min and max handles are wrongly styled. See sample screenshot
How to fix:
Add support for the direction option of the noUiSlider JS library.
bmunslow → made their first commit to this issue’s fork.
Beware that #5 will likely re-introduce the compatibility issue with Drupal 10.2 that the Undefined file entity bundle was attempting to fix.
IMHO, #2 is preferred as a temporary fix until this issue is resolved.
I was hit by this as well. I can confirm this issue was introduced in 8.x-2.0-rc5. Issue disappears after downgrading to 8.x-2.0-rc4 or previous versions.
I compared revisions 8.x-2.0-rc5 and 8.x-2.0-rc4 and there is a single commit of difference between them, which introduced the issue.
In short, a new hook was added in file_entity.module which defines the Undefined bundle to fix validation issues.
As @Berdir anticipated in #3403892 📌 Set up Gitlab CI, fix tests and 10.2 compatibility Fixed , this hook fixed the 10.2 compatibility problems as a workaround, but introduced this new issue.
Hope this helps in moving forward to fixing it.
The approach by @riyas_nr is to keep the static caching of the view and differentiate based upon the view name or display ID. It fixes the issue tot, although view name and display ID should BOTH match before returning the static object (since it's quite common to have views with different names but same display IDs, e.g. block_1, etc.).
The attached patch improves on #9 by make sure both the view name and display ID match the static object or otherwise creating it from scratch.
Important to bear in mind #3 though. IMHO removing static caching altogether would be best in this case, although patch #8 needs a re-roll...
But, this is wrong, $view_args should be set from the exposed filters.
I think this is a big assumption to make, since not all views with contextual filters may have those filters exposed.
Good thing is draggableviews provides a hook to alter the view arguments if needed for a specific scenario, like the one you mentioned.
In my case, I use contextual filters for the Draggableviews Order page, but I display the results in a block that is rendered by means of the viewsreference_filter module, which exposes the filter instead of using contextual filters.
I was able to work around it by implementing the following hook_draggableviews_join_withargs_alter() as follows:
/**
* Implements hook_draggableviews_join_withargs_alter().
*/
function MY_MODULE_draggableviews_join_withargs_alter(&$view_args, &$context) {
if (empty($view_args)) {
// Give draggable view a chance to use exposed filters as arguments,
// since these may have been passed on from viewsreference_filter module.
if (!empty($context['view_query']->view->exposed_raw_input)) {
$view_args = array_values($context['view_query']->view->exposed_raw_input);
}
}
}
In addition, I had to apply the RTBC patch in this issue: https://www.drupal.org/project/draggableviews/issues/3336466 🐛 "Pass Contextual Filters" option is broken on multiple sorts RTBC
Patch works for me too, looking forward to seeing this included in the next release!
Uploading patch file based on MR 25
Patch in #5 tested successfully. Applies cleanly too. Manually tested functionality of the toggle, it is correctly preserved between pages, and the right class is appended to the body as well.
Setting this to RTBC since the patch is quite straightforward. A new release compatible with D10 will be much appreciated.
bmunslow → made their first commit to this issue’s fork.
bmunslow → created an issue. See original summary → .
The most straightforward workaround is obviously to disable the limit_html filter.
Sadly, as far as I know, it's not really possible to transform the style attribute to class names in this case (although it is doable with the color button plugin → , for instance).
The only option would be to develop your own custom font-size and font-family CKEditor5 plugins so they create and assign class names to style each element, instead of using the style attribute.
CKEditor 5 Dev Tools → would be a good starting point.
Fixed issue by providing a derivative to generate the help local task dynamically, only if the help module is enabled.
It looks like the above commit is not enough to fix the issue. Accessing the firebase.configuration route throws the following exception:
Uncaught PHP Exception Symfony\Component\Routing\Exception\RouteNotFoundException: "Route "firebase.help" does not exist." at /var/www/html/docroot/core/lib/Drupal/Core/Routing/RouteProvider.php line 206
The issue lies in the firebase.help local task, which remains defined if the help module is uninstalled and references the non-existing route firebase.help.
That's correct, filter_html filter is incompatible with the ckeditor_font pugins (font size and font family), because the style attribute is not allowed.
See:
- https://www.drupal.org/project/drupal/issues/3109650 ✨ Refactor Xss::attributes() to allow filtering of style attribute values Needs work
- https://drupal.stackexchange.com/questions/282371/ckeditor-stripping-all...
bmunslow → created an issue. See original summary → .
The patch is quite straightforward, it passes the Upgrade Status scan cleanly, setting this to RTBC
bmunslow → made their first commit to this issue’s fork.
MR16 applies the automatic rector patches and fixes additional D10 compatibility issues.
Link to merge request in patch format for your convenience.
Upgrade Status scan passed cleanly:
bmunslow → made their first commit to this issue’s fork.
MR5 patch doesn't apply to 3.0.0 version so here's a re-roll of the patch, just until a new release is created
WARNING: #195 solves the issue, yet it does cause another issue.
After applying patch #195, anonymous users can't search any contents on the site using drupal's default search.
Patch needs more work!
#195 worked great for me too.
Similar context: View with an non-required entityreference field relationship to access additional field from the referenced entity.
Anonymous users did'n't get the rows with an empty referenced entity.
Patched fixed the issue, thanks, no side-effects for the moment.