#Usability

✨ Support CKEditor5 Needs review has been closed and marked fixed. Since this now has a working solution in contrib, should this issue re-focus efforts around inclusion of the functionality from https://www.drupal.org/project/edit_media_modal → into core's Media Library CKE5 integration?

Bot changed status, but I think it is ready for review?

Won't hold it up but lets see!

I have a Drupal 10.4.x site that still requires this patch. I've re-rolled the patch from #206 to apply to 10.4.x

Inter-diff from last patch added as well.

Just wanted to leave a note here, that we need something similar, but not for the alt-text, but for a subset of fields of the media entity to override in the referencing media reference field wiget.

https://www.drupal.org/project/media_library_media_modify → is close, but implements its own field type, which is a problem for existing sites. Instead, it should be a field widget for the existing media references.

Updated the error messages in ErrorCodesEnum::getMessage() as per feedback from @tedbow.

Automatically closed because Drupal 7 security and bugfix support has ended → as of 5 January 2025. If the issue verifiably applies → to later versions, please reopen with details and update the version.

Opened an MR with a naive first draft of this. Curious how much will break as a result. 😅

Just following up if this should be re-open,. if no follow up in 3 months could be closed

All of the following call for this to be implemented:

• 🐛 Special characters cause regex error when creating components Active
• 🐛 Cannot add component to the component library using the contextual menu Active
• 🐛 Can't add in-browser code component with checkbox prop to the library Active
• … and more

That would increase the quality/detail of many bug reports.

The Drupal core Accessibility → core gate states that a goal of core is to conform to WCAG 2.1. That standard has recommendations, https://www.w3.org/WAI/WCAG21/Techniques/general/G200, for this case.

There is an item here to add a sniff for target=_blank. But there are valid cases for using _blank so adding a sniff to to warn about it's use could be disruptive when running commit-code-check.sh.

Therefor, I think everything is done here.

Thanks everyone!

Creating new MRs for rebases is not ideal, now reviewers/contributors don't know where to look. Same goes for uploading patches for various fixes, now it's not clear what the canonical source is. We need to make sure the fixes from the patches in #119 and #120 are valid and they are rolled into the canonical MR.

Closing the old MR for now.

acbramley → closed merge request !11100

acbramley → changed the visibility of the branch 3274635-upstream-use-ckeditor to hidden.

But does this warrant a full bootstrap being a functional test?

@smustgrave I don't feel like testNodeMetaInformation is the right place to test the visibility of the Published checkbox. I prefer test cases to be succinct in what they test rather than having massive test cases asserting all sorts of things. It makes it easier to maintain and understand why something failed when it does.

Clarifying issue title; issue summary could still use an update. Per @tedbow, 🐛 Click publish shortly after making a change can lead to error Active probably is the right thing to do here, because that reduces the probability of ever seeing these messages.

Created 🐛 Click publish shortly after making a change can lead to error Active as idea how we might make this situation in #9 less likely

@lauriii thanks. Yeah that is the case that I could reproduce manually but not all the time.

I ran into this by making a change and then quickly trying to publish it after making that change. I think the error I got was "This item is unexpected." and it was really confusing because I had no idea what is "this" in the context of the message and why it was unexpected.

@lauriii since you made this issue did you run into these messages while using XB or just reviewing?

If you ran into it using XB what circumstances where they under? Locally where there was only one person using XB or where there might have been more?

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

I did. I think we should do the narrower scope from 📌 Handle components without HTML wrappers Active for stable and leave this as a separate issue to deal with later.

Given that 📌 Add a container parameter that can remove the special behavior of UID#1 Fixed has been fixed, this should be probably closed.

@lauriii 📌 Handle components without HTML wrappers Active has already been closed in favor of this — were you really intending to link to that? 🤔

@tedbow: can you propose improved UI strings? 🙏

I've updated the messages in \Drupal\experience_builder\Controller\ErrorCodesEnum::getMessage() to make them more helpful and actionable.

Working on it

Should this be re-opened or can it be closed out. If no follow up in 3 months will close out.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

I've created a MR that applies the patch in #26 (after checking: issue still exists, patch still applies, patch fixes the issue).

Can anybody please confirm that this needs test coverage? I cannot find any existing tests that verify if the expand functionality works for normal links, so it seems a bit odd to write a test only for <nolink> items. Thanks!

Could you please explain better how this part of test coverage works? I'd be happy to learn and contribute to this issue.

@liquidcms A true revert would either be a patch or overriding the two JS files updated but the quickest way to go back to the earlier behavior is probably to disable the scroll lock immediately after it is activated.

in a custom module add a jQuery event listener on 'dialog:aftercreate', which is triggered immediately after the scroll lock is added.

In the callback, run the same code that is run when the modal dialog closes

const $scroll = $element.find('.scroll');
    if ($scroll.length) {
      bodyScrollLock.unlock($scroll.get(0));
    }

This might not be it line-for-line, I didn't actually try it, but this approach should work - fortunately an event is dispatched right after the scroll lock so it's quite available for disabling.

This seems to be "fixed" in 10.4. Can someone suggest how to revert this back to the way it was in D9 (despite everyone saying no one would want to scroll the background when a modal is open, my client is pretty annoyed this is now broken).

For those wondering, yes there is a module to overcome this for the time being: https://www.drupal.org/project/start_end_date_format →

There has been no activity here for 10 years.

Is this still needed? If confirmation that this is still needed isn't supplied this may be closed after three months.

Thanks!

There is still one @todo in the MR - do we need to discuss that? I do not see it mentioned anywhere in this issue. Thanks!

Apologize for taking so long to get back to this one, even after posting it in slack lol

But feedback appears to be addressed.

Can the issue summary be cleaned up some. Using some hybrid template (maybe that was the template back then haha) but updating it would help with reviews.

benjifisher → credited simohell → .

benjifisher → credited worldlinemine → .

I moved the patch to a merge request.

I tested this change:

- If you click on a token in the list, it will populate the last field that had focus. With this change, the last field will become the new token filter field. See screenshot
- It needs some styling to make it look a bit smoother (I checked it with Gin) . See screenshot
- I checked how filter field are being used in Views , maybe that pattern can be applied here as well. See screenshot

Automatically closed - issue fixed for 2 weeks with no activity.

Automatically closed - issue fixed for 2 weeks with no activity.