@bgreco

I'm still able to reproduce this issue in 2.0.0-beta16 by following the steps in the issue summary. Entities referenced by removed layout builder blocks are still listed as "published". For now, I've adapted the patch from this issue to work with 2.0.0-beta16.

bgreco → created an issue.

Updated patch for 8.x-2.0-beta14

bgreco → created an issue.

bgreco → made their first commit to this issue’s fork.

After some additional testing, I've found that the approach in this issue (creating a new language negotiator) works better than the approach from 🐛 Rendering is not changing the current content and string translation language Closed: duplicate .

The patch from the other issue fixes config and string translations, but entity references are still rendered in the request language. (Specifically - in layout builder, non-translatable custom blocks that reference translatable entities.) The branch from this issue is more complete and fixes all three - config, string, and entity translations.

bgreco → changed the visibility of the branch 3035977-change-language-existing-services to hidden.

I created a new branch with the patch from 🐛 Rendering is not changing the current content and string translation language Closed: duplicate that doesn't create a new service. I haven't been able to figure out how to write a test for it though.

bgreco → made their first commit to this issue’s fork.

Update patch #20 to be compatible with Drupal 10.3

I'm seeing similar issues. I found that changing
html:has([data-fullscreen="fullscreenoverlay"])
to
body[data-fullscreen="fullscreenoverlay"]
in fullscreen.css fixed most of the issues for me, except the link balloon still isn't visible.

The merge request from #7 fixes the issue for me.

I can reproduce this too using Drupal 10.2.4 and color 1.0.3.

1. Select a theme that supports the color module (such as bartik)
2. Select a non-default color scheme
3. Remove the site logo by unchecking "Use the logo supplied by the theme".
4. Save the color settings.
5. Visit the site home page.

The error appears in the log (or on the screen, depending on error reporting settings).

bgreco → created an issue.

I enabled JS aggregation for some tests, and that seems to be enough. The updated tests fail without this fix, and pass again with it.

bgreco → created an issue.

There's no dev release listed on https://www.drupal.org/project/plupload_widget/releases → , which is probably why composer can't find it.

The merge request fixes the problem for me.

bgreco → created an issue.

Update #43 for 10.1

Quick fix

bgreco → created an issue.

bgreco → created an issue.

@Anybody It works in a site's default language, when changing the text at /admin/config/system/cookies/texts like @Grevil did.

It does not work in a site's non-default language, when adding additional translations at /admin/config/system/cookies/texts/translate.

Thanks... looks like composer.json isn't even needed → .

bgreco → created an issue.

bgreco → created an issue.

bgreco → created an issue.

Thanks for your response. Perhaps I'm misunderstanding how the dialog works, but I thought the button I clicked was the overall Link balloon panel's save button, which I hoped would simply insert the link I typed without needing to accept the "no suggestions found" result first.

A different way of addressing the need to click twice might be to simply remove the "no suggestions found" result if ✨ Provide a hook/event for modifying the suggestions list Active is possible.

Created an issue fork with a fix for the query and a test.

bgreco → created an issue.

Here's a workaround which changes the font plugin to generate <span class="font-size-*"> instead of <span style="font-size: *px">. You also need to create corresponding CSS rules to apply the font size to the font-size-* classes.

function hook_editor_js_settings_alter(array &$settings) {
  foreach ($settings['editor']['formats'] as &$format) {
    if (isset($format['editorSettings']['config']['fontSize']['options'])) {
      foreach ($format['editorSettings']['config']['fontSize']['options'] as &$option) {
        // Change the font size plugin to generate <span class="font-size-*">
        // instead of <span style="font-size: *px">.
        // Adding the 'view' property causes the font plugin to treat the option
        // as a "full definition".
        // See getOptionDefinition(), isFullItemDefinition(), and namedPresets
        // in ckeditor5-font/src/fontsize/utils.js
        $option['view'] = [
          'name' => 'span',
          'classes' => 'font-size-' . intval($option['model']),
          'priority' => 7,
        ];
      }
    }
  }
}

function hook_ckeditor5_plugin_info_alter(array &$plugin_definitions) {
  // Replace the <span style> element with <span class>, since we alter the
  // plugin to use classes instead of inline styles.
  $font_plugin_definition = $plugin_definitions['ckeditor_font_font']->toArray();
  $font_plugin_definition['drupal']['elements'] = ['<span>', '<span class>'];
  $plugin_definitions['ckeditor_font_font'] = new CKEditor5PluginDefinition($font_plugin_definition);
}

Updated patch #12 for 2.0.0-beta3

I created a merge request with a change to make the toggle button switch the text direction to LTR if the content language direction is already RTL.

bgreco → made their first commit to this issue’s fork.

bgreco → created an issue.

bgreco → created an issue.

Is there a possibility of adding an option to continue using the off-canvas dialog instead of a modal? When creating custom blocks, the preview is displayed directly in the Layout Builder interface, not the tray, so there are no problems with it being styled differently. And having the live preview directly in the Layout Builder interface provides a a simpler experience when designing a page than having the page obscured by a modal dialog does.

#2 fixes the problem for me as well

This patch further extends patch #11 to:

• Synchronize the referenced block revisions in all layout translations when the layout is saved in the source language - rather than only doing the synchronization when the layout is saved in the translation language.
• Synchronize the referenced block revisions in all languages, including if there are 3 or more languages.
• Add tests.

Updated patch to respect the form redirect destination

bgreco → created an issue.

What is the use case for having the duplicates_checksum field translatable in the first place? It seems like this issue could be solved by making the field not translatable.

@anybody Yes, it fixes the issue for me.

bgreco → created an issue.