Account created on 27 May 2020, about 4 years ago
#

Recent comments

Patches here aren't working for me with a setup like this:

<div class="layout-builder__region js-layout-builder-region layout__region layout__region--content">
  <div class="js-layout-builder-block layout-builder-block contextual-region">Block 1</div>
  <div class="js-layout-builder-block layout-builder-block contextual-region">Block 2</div>
  <div class="js-layout-builder-block layout-builder-block contextual-region">Block 3</div>
  <div class="my-custom-wrapper-here">
    <div class="js-layout-builder-block layout-builder-block contextual-region">Block 4</div>
    <div class="js-layout-builder-block layout-builder-block contextual-region">Block 5</div>
  </div>
</div>

It sounds like I should expect to be able to drag and drop 'Block 4' and 'Block 5' around after applying some of the patches here, however I am unable to.

From the original post:

The Drag-and-drop reordering doesn't work because the selector takes instead of .

Is something incorrect with my formatting perhaps? Seems like what I have should work?

My apologies, I realized that the functional test I had written previously was still trying to hit /editor/dialog/link/rich_text. This was calling linkit_form_editor_link_dialog_alter() which otherwise wouldn't be getting called. The old ckeditor was showing a form in a modal (the actual form URL being /editor/dialog/link/rich_text but the new ckeditor5 is doing it differently.

I've been using the code in #21 for a while on my site and it has worked great! I had a custom ckeditor plugin that opened up a modal that contained a few form fields, one of which needed to open our custom entity browser. However, I've been attempting to upgrade to ckeditor5, and I can not get this functionality to work any longer.

Clicking the button on the ckeditor5 toolbar opens up my modal successfully, and my other fields work...but I can't get the custom entity browser field to work correctly. Once I make a selection, I still see a 'No items selected yet' message. I would expect the image that I selected to appear there. Even if I hardcode media:123 for example as the default value, I still see the 'no items selected yet' message.

Just wondering if anyone has seen a similar issue? I really don't know what could be causing this to happen.

Hey all, just posting again here. I've been considering deleting all paragraphs (and nodes of the node type that uses them) and re-importing after I switch from the 'Paragraphs (stable)' widget to the 'Paragraphs Legacy Asymmetric' widget. However that is slightly risky...if there is a good reason for those duplicates I mentioned above to exist (perhaps something with revisions), I will keep using the 'stale' widget.

I have a block on my site that was using an entity query to get these paragraphs...however that query was returning the duplicates. I was able to work around that problem.... but I just don't think those duplicates should exist at all.

I was seeing this problem on my sites... pulling down the latest merge request does fix the problem for me.

I was also seeing this problem on my site. The latest patch does fix the problem for me (I'm on 10.2.x).

I added the upload widget to a custom entity browser that I'm using. However, I noticed users were still able to view that tab when the entity browser was open (even though they did not have the permission to view it). The patch in #8 did fix the problem for me.

I ran into this same problem (my functional tests were failing locally after I added this feature to my custom entity browser). The patch in #3 fixes the issue for me.

I'm no longer seeing this issue in my project since claro no longer uses stable as its base theme in D9.

I've been trying to reproduce this in D9 by using classy as the base theme for my custom theme instead (since stable is still the base theme of classy). I added a custom libraries-override in classy.info.yml just to test this out. I'm actually not seeing the issue anymore (I see the custom override when I view the page source is coming from classy). If I reverse the theme order from the code snippet in my original post (which is how I fixed this issue locally in D8), I'm now incorrectly seeing the override come from stable instead. So it seems that this issue has been fixed and there is no need to reverse the base theme order in D9.

One thing that is strange to me though is if I inspect, the theme order still looks to be incorrect (classy is loading first). So it appears that issue has been somehow fixed, I'm just not sure where/how as of yet.

I'm using a different tool for accessibility scans on my site and #13 fixed the issue. All font awesome icons are still working as well.

Production build 0.69.0 2024