🇺🇸United States @chrisgross

I'm running into a similar problem on 10.3.2. However, the suggested solution does not work for me, though my use case is perhaps slightly different.

I am using core's included Block Content Permissions, but I have chosen not to give any roles "Create new block content" permissions for my various custom block types and this is preventing media from being uploaded to fields on those blocks in Layout Builder. Granting those permissions does fix that and allow media to be added to the library within Layout Builder blocks, however, it also allows users to add new instances of these custom block types under '/block/add', which I do not want. I only want those users to be able to add those blocks in Layout Builder.

The "Create new block content" permissions are not required in order to actually add these custom blocks in Layout Builder at all (which I believe is how it's supposed to work), but they are required in order to add media to fields within those blocks. So I believe this is a variation of this same problem, which is that Layout Builder is using faulty access checks when uploading media to custom blocks.

I'm not sure why the solution in #37 does not work for me.

This just happened to me for the first time, as well. There definitely needs to be a way to configure whether locks stay in place or not, and perhaps configure the expiration time. I just had a mission-critical feed stay locked for a week before anyone noticed (that might sound contradictory, but it's not).

I am running into this, too, and have seen it for a long time now. If this isn't easily fixable, shouldn't core maintainers roll back the commit that caused this problem? This is a majorly critical issue because it makes it impossible to edit text formats, which is, needless to say, really important.

I'm still having what I think is the same issue and the latest patch does not fix it. Perhaps this is a slightly complicated example, but I will simplify it as best as possible.

Here I have I two select lists. The first one uses an ajax callback to modify the options contained within the second one, which has a couple hardcoded default values:

$form['billing_date'] = [
  '#type' => 'select',
  '#title' => t('Billing Month'),
  '#options' => $options,
  'callback' => '::equipmentUpdate',
];

$form['equipment'] = [
  '#type' => 'container',
];

$form['equipment']['equipment_id'] = [
  '#type' => 'select',
  '#title' => t('Equipment Number'),
  '#options' => [
    0 => '- Select - ',
    'other' => 'Enter manually'
  ],
];

My custom equipmentUpdate callback does a lot of other things, but here is the command I use to update the options of the second select list:

$response->addCommand(new ReplaceCommand('#edit-equipment .form-item-equipment-id', $equipment)

This ReplaceCommand occurs after $equipment (which is a copy of $form['equipment']['equipment_id']) has been modified to add new values after the two defaults set earlier.

That functionality works just fine, but what does not is the state of a third field, whose visibility depends on a value contained within the second select list, which is modified by the ajax call:

$form['equipment']['equipment_id_other'] = [
  '#type' => 'textfield',
  '#title' => t('Equipment Number'),
  '#states' => [
    'visible' => [
      ':input[name="equipment_id"]' => [
        'value' => 'other'
      ],
    ],
  ],
];

Before the ajax callback, the visibility of this text field is correctly controlled by the equipment_id select list. After the callback completes, this no longer works, and the visibility of this field does not change. I have tested by experimenting with other ways of organizing the data and using different ajax commands, like HtmlCommand, but nothing works. No matter what I do, subsequent ajax calls continue to correctly modify the select list values, but the visibility state of the text field is broken.

I have confirmed that all the markup in all fields and wrappers are exactly the same before and after the ajax command, except that that ajax operation changes element ids, for example, from edit-equipment-id to edit-equipment-id--Ronn-Os05Q0, but my visibility selector is targeting the name attribute, which does not change, so this shouldn't matter.

I have been able to work around this by not using ReplaceCommand to replace the entire select element and instead manipulate the option elements directly:

foreach ($results as $result) {
  $id = $result['id'];
  $response->addCommand(new RemoveCommand('#edit-equipment select option[value="other"] ~ option'));
  $response->addCommand(new AfterCommand('#edit-equipment select option[value="other"]', '<option value="' . $id . '">' . $id . '</option>'));
}

This works, but should not be necessary, as replacing the entire select list should not cause the states of another field to stop working. Doing it this way is also mildly inconvenient because, as far as I can tell, I cannot pass options as a render array (or a subset thereof) to the ajax commands, so I have to write the markup for each option manually.

I get no console errors or anythig

@Berdir Okay, I see that now. That sort of makes sense, although it seems very confusing for the versions to not match.

In any case, I already did attempt to patch that 4178 diff you linked, but for me, it fails to apply to 10.2.0 (I had to do this upgrade before 10.2.1 for change control reasons). What would be the proper protocol in that situation?

@capysara How do you recommend this should be handled by those of us who are already using older patches for versions that are no longer being targeted even though they are still current and supported? My team has been using a now three-year-old patch until recently for this functionality, which no longer applies after the 10.2.x updates. Throughout the many years I've worked with Drupal, this is this first time I've been told that this method of submitting patches for community use is not acceptable. A large number issues tracked by developers are many, many years old and this has long been the method used by the community, in my experience.

Do we need to re-roll patches like this and then self-host them even though doing so means others who may need it can't see it or are you suggesting that we commit changes to drupalcode even if we know they will never be merged just so we can share them? It makes sense to target 11, but that version won't be out for a while now, so if the rules have changed, I'd just like to make sure I am following them, while still providing solutions for those that need them in the meantime.

#82 is the newest patch that is working for me after a re-roll against 10.2.x. I'm not sure if it's the mish-mash of patches and direct commits and jump straight to 11.x since then that are causing this confusion, but no combination I've tried will apply or work, even after attempted re-rolls. So if anyone has a working patch for 10.2.x, please upload it.

In the meantime, the attached patch is the only thing that works for me. Since #66 worked on 10.1.x, this is good enough for me, at least for now. If anyone can get the newer commits working on 10.2.x, please share it.

@codechefmarc Do you have a patch that applies cleanly against 10.2.1? I tried applying https://git.drupalcode.org/issue/drupal-2999491/-/commit/1330eff91b12349... and it failed.

Actually, after testing this patch #46 more, it seems to create more problems than it solves. For some reason, with the current state of D10/CKE5, media embedded within lists get shoved inside additional list element, which is confusing to editors.

Before this patch, I could theme around this by hiding the list styles and margins in my theme, but after the patch, embedded media has wildly inconsistent behavior.

When inserting media in a list, the media gets inserted INSIDE a 'ck-list-bogus-paragraph' element. After saving the content and returning, it is now appearing AFTER the 'ck-list-bogus-paragraph' element, and so the list styles cannot be removed with CSS.

Okay, I think I understand how the patch works. Images can be now embedded "inline" insofar as they do not break lists within the editor itself and can be dragged around and placed back in lists. But there is still no true inline option for rendering images within text, which I guess is the bigger issue, as this is a standard CKE5 feature.

Here's an updated patch with the correct file paths for contrib.

Here is a patch that seems to fix this issue. It uses identical code as the media patch @Zooney linked to, so thanks to them for connecting those dots. It allows these embeds to exist within lists just like media elements. It does have the odd side effect of appearing to nest the embed within an additional list element. This is only visible within the editor, not when viewing content, but this also happens with the core media fix, so that is probably just a separate core issue that needs resolved. I have just been hiding those list markers in my theme's CSS in the meantime.

I can confirm this issue. I think the reason it is possibly "critical" is because CKEditor 4 is out of support, and thus technically a security concern, and upgrading to 5 breaks this module's functionality. As a result, security updates are actually being held back because stakeholders won't abide by what they see as a loss of features that they previously had, and content is their primary concern. So if there is a relatively simple way to resolve this, that would be the motivation for treating this as critical.

#46 applies for me, but it doesn't seem to do anything. No images are inserted inline at all.

I just tried out the CKE5 live demo on their website and media alignment just works. Shouldn't Drupal already support all of CKE5's basic native functions out of the box in order to be the default editor that every single Drupal sites uses? Maybe this is off-topic, but it seems irresponsible to have included this new version as the native editor at all if that is not the case.

I can confirm that this issue still exists in 10.1.6 and the most recent patch does not apply.

It looks like the issue described in #68 happens when "Adds reset facets link." is before 'Adds single submit button." in the Processor Order, but it works correctly when they are swapped. In most cases, the apply button should come before the reset link, so this is a problem.

This change record → was helpful in getting the in-editor themes mostly worked out, particularly the second row in the table, but requires some trial and error, depending on your theme and design system. This has allowed me to work out most of my issues with getting the front-end styles into the editor. The key for me was creating a separate scss file for ckeditor and telling my gulpfile that I now have two main sources. I don't love that this seems to effectively double to size of my CSS assets, but in theory only one set is loaded at a time if you are using a separate admin theme.

The problem still remains that some admin theme styles still appear within the editor. I've found that across themes, button styles are the most problematic, as they always seem to override my front-end styles. This can be worked around but overriding some button CSS in your front-end theme, and this may work for other elements as well. I still think it's problematic that this is necessary in the first place, but I'm not sure what the solution to that particular problem is.

Also, the version was recently changed to 11.x, but this seems to be affecting 9 and 10 as well, basically anything using ckeditor5.

I'd say the implementation of ckeditor5-related stylesheets is a major issue right now. On top of not working at all for some people, we are also dealing with admin theme styles leaking into the editor when the are unwanted, as well as front-end theme styles leaking onto the admin pages when we only want it in the editor. If this is a natural consequence of doing away with iframes, is there a way to solve these issues so this all works the way it did before ckeditor5? If not, that is a major problem.

I am running into a similar issue on 9.5.11. I am getting my admin theme's CSS in CKE, which I do not want, and it seems that the intended way to disable this is to add the following to your admin theme's info.yml file:

ckeditor5-stylesheets: false

This does not work for me. When I go into ckeditor5.module and debug _ckeditor5_theme_css() to figure out why this is happening, it looks like the 'stable' theme is being injected into the $info variable, which per the code should only happen if the $theme variable is not set. I am not finding any documentation about this, but there should definitely be away to easily disable admin theme CSS within the editor

I'm not sure if this belongs here or in another issue, but even with this patch, I am running into issue with pagers when using this module.

I am seeing a problem where re-used displays appear to be using some sort of hidden shared variable for their pagers (I don't know if it is using the pager ID behind the scenes or what). If I place the same views block on a layout builder page twice, but simply change the "Items per block" on one block, which leaving the other on the default value, the pagers completely break.

For example, if I set the first block to show one result per page and the second one to use the default (5), all results are displayed in both blocks and they both lose their pagers. If I instead set the first block to use the default (5) and the second block to display one, then both blocks get pagers that indicate there is only one result, but the first block is displaying all of its results. So if I click on one one of the pager numbers for that block, the results disappear, as if I have navigated to a page that doesn't exist, and then that pager disappears.

It sounds like this is similar to the issue being described here, only it is something that happens when multiple identical blocks are placed on a page.

The latest patch does seem to work as far as hiding the filters are concerned, but I question the purpose of choosing which filters to hide when placing the block. In our use case, the people placing blocks are content editors, and they don't really have any concept of what an exposed filter is or whether they should hide them. Adding this option just serves to confuse them, doubly so since the filters are all displayed by default and have to be turned off.

My understanding of the purpose of this module is simply to let content creators decide how to filter the content that appears in the blocks they place, which is what they are doing in the block settings. Letting them then choose not to hide said filters from the user-facing page sort of defeats the purpose of setting the value in the block config, does it not?

Perhaps if there truly is a use case for this, it should perhaps be configurable somewhere else?

Is this supposed to work when a views display is AJAX enabled? It does not seem to for me.

@joegraduate Yeah, I just realized we switched to using CKEditor 4 in contrib due to the core change, which explains it. The patch in the issue you linked works. Thanks!

Patch #21 worked for me on 9.3.6, but #52 does not on 9.5.5. Is anyone else experiencing this?

I am seeing this issue myself and changing the time zone to UTC in the feed config for the fields does not seem to work. I am in UTC -5 and have a JSON feed providing times in UTC. However, the date-only fields I am importing into end up with the wrong date if the times stamp is too close to midnight.

For example, the feed provides "2023-05-16T03:45:00.000Z" and when I import it, the destination field is "2023-05-16". But being in UTC -5, I need this to be "2023-05-15". Changing the time zone field in the feed mapping does not seem to affect this at all. This might be partially due to the fact that core's default date field handling seems pretty bad, but is there no way to fix this? Do I have to process the feed items in a custom Event Subscriber to correct this?

I've run into this issue, too. For whatever reason, some of my sites have the site_frontpage variable stored as the alias to the front page node, in my case 'home'. I don't know if this is from an older version of drupal that allowed this or something. Either way, wouldn't it be safe to change the code in drupal_is_front_page to

$is_front_page = ($_GET['q'] == drupal_get_normal_path(variable_get('site_frontpage', 'node')));

since drupal_get_normal_path() will return the node path regardless of which path is passed to it?