#Usability

I tried to update the patch here https://git.drupalcode.org/issue/drupal-867830/-/compare/11.x...867830-u...

The numbering may not matter, but because @lauriii is wonderful, the numbers aren't what I thought they were.

I think these are complementary issues, but definitely related.

There was a solution implemented for canonical entity routes in ✨ Display content moderation state in the Navigation Top Bar Active which is worth noting here.

@vsujeetkumar it has been 2 years, so this will need to be re-rolled.

What comments are still unaddressed?

@pasqualle suggested an approach that @ricksta recommended. I think the summary there is new variable "status_marker" and mark the old ones deprecated.

We would need a new variable name I think.

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 tested #7.

To clarify, this is not an issue when the components are stored (e.g. I publish them, even without "adding to components" aka status=1), only on the transient time when they are in auto-save, not published, not status=1, as we do this validation on config entity dependencies. That part IMHO is Works as designed, as the preview message is informative enough to fix the situation.

The original purpose of this issue still remains though.

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

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

Should the tests be expanded to test for internal: also?

Agreed with @eszszabo, this should really be solved in Core. Even Microsoft Word allows you to mark images as decorative, and surely Drupal is better with accessibility than Word. 😅

I run into the same issue as #546 is describing, when updated a project to 10.4 so I updated the patch. Feel free to test, its working as expected for me.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Could we make the soft delete as an explicit feature? I.e. hiding modules from the UI. I think this would be really useful in the beginning until we can associate which users can use which components. Tagging with needs follow-up for that.

We could still offer the delete as an option because there are scenarios where it's desired to delete a component and all of its uses altogether. However, there's a difference between content vs components referring to components. I'd say that uses of a component in another component should prevent deleting, but deleting a component used in content should not prevent the deletion (especially because even past revisions would prevent deletion).

What would be extremely useful is having a list of usages of the component. This is not only useful for the delete use case but also when you want to assess how components are being adopted.

Glad to see this go in. Mammoth effort

We did a walkthrough of a set of problems outlined by the following four issues:

• 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active
• ✨ Allow media items to be edited in a modal when using the field widget Postponed
• ✨ Media items translate items in modal Postponed
• ✨ Override media fields from the reference field Postponed

The current state of the https://www.drupal.org/project/media_library_media_modify → module was the basis for our discussion, and we worked through a set of user tasks. We've highlighted the problems we've encountered along the way within the media_library_media_modify module as well as the media module in general. Other issues that were touched during the meeting:

🐛 Impossible to override a media item on a node that is not saved yet Active
🐛 The form for overriding a media item is a homogenous mix of content and meta data fields Active
🐛 on the node edit page contextmod only shows global values for media items even though some are overridden Needs review
✨ Expose triggering update of media metadata + thumbnail to end users Needs review

Due to the fact that we haven't had enough time left to finish our exploration, we will need a second round. That is also the reason why there will be no comment on any of the referenced issues yet nor have we got to any discussions how to tackle the problems we've encountered. We will get to that when we have an overview of the entire problem space.

addressed feedback

Nobody disagreed with me in 5 years, so that's a yes for me.

Since there's been no follow up in 3+ months going to close out. If still a desired feature please re-open updating any missing information

Thanks!

Bumping 1 more time if this should be closed.

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!

Left comments in MR.

Thanks for letting me join today

I mean, obviously :D

Finally. 🥹

1. Create @todos pointing to a yet-to-be-created follow-up issue that drop XB's logic in favor of core's ComponentMetadata::getEnumOptions(), as well as any other things we could drop from XB once XB requires a core version containing #3493070.

This was added in #3 but is obsolete, because core didn't end up adding any such infrastructure 😅

Thanks, @penyaskito! 🙏

https://git.drupalcode.org/project/experience_builder/-/merge_requests/8... → well done!

Just one final question/thing that needs to be updated: https://git.drupalcode.org/project/experience_builder/-/merge_requests/8...

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The change makes sense to me, opened an MR with the patch that was posted.
The Belgrade theme is going to need a followup fix to follow the same approach as it is removing the checkout form CSS.

  commerce_checkout/form:
    css:
      theme:
        css/commerce_checkout.form.css: false

Great effort everyone, thanks @longwave

Patch for Drupal 10.5 for those who patch per file.

With ✨ Allow text field to enforce a specific text format Fixed landing that does that alter the text suggestion?

Still relevant in Commerce 3

I'm also against deprecating this field as I'm also using the textarea widget for text fields module for the exact same use cases: for adding strong, italics, exponents, etc. in title fields, SDC props, and other short text fields where it doesn't make sense for a full textarea/longtext field. I see I commented in the other issue 2 years ago, and just want to say it still works very well. I have custom text formats explicitly limiting the number of buttons that are used in the CKEditor for these fields.

Know we are planning to deprecate 🌱 [Meta] Deprecate text_with_summary Active do we want to really deprecate both?

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!

With default profiles being phased out with Drupal CMS and recipes not sure this is valid for D11 anymore.

Thanks all!

#175 applies to 11.2 either. Thank you.

I'm unsure how to best proceed with this.

One thing to consider is dropping the update specific logic. That's where we originally encountered this, but I think it makes this more complicated (why special case update, why not also install, ...).

I think a feasible option is to split of the actual fix in separate issues and get them in, like the user role stuff in 🐛 Config entity static cache is not cleared correctly when multiple language overrides are used Active . Everything that we need for that is present in HEAD, we just need to use the API properly. The work done here is forcing that data isn't being overwritten/corrupted, at the price of exceptions for end users and also things like module installs, which can be very tricky to recover from properly.

longwave → closed merge request !11100

Great work here - nice to see this finally land! Tagging as a release highlight and will publish the change record.

Committed e117838 and pushed to 11.x. Thanks!

I tried to credit everyone who provided code changes or helpful comments that moved the issue along in some way; I did not credit those who just uploaded patches, because we should be using MR workflows now. Apologies if I missed anyone.

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

Thanks!

Tested changes on branch 0.x , for following scenarios :

The initial idea during the discussion with meetup groups was to extend the scope of blocks be shown in the custom block library to every block available in the system

I strongly disagree with this. Look at 🐛 Inline blocks shouldn't be editable via the normal block content UI Active - inline blocks should never be edited outside of the context of the layout they are placed in.

Having them listed in the block library is just going to add confusion. What purpose would they serve? We would probably have to add a new column to show which page they are embedded in, but there would be no way to edit or delete or manage the blocks in any way from that screen. That must be done in layout builder directly.

Seeing as this is a view, and users are free to edit these filters after installation, I think what we have now is a good default setup.

the fact that core and contrib blocks aren't actual entities might entail potential confusion again for the users

I'm not sure what you mean here, they are entities.

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!

Back to green. Added the followup needed in IS.

Updated after 📌 Remove "List: number" as an available shape in the code component editor Active landed.

Can confirm that MR works on D11.2.2

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

Code looks great, and manual testing shows everything as expected. RTBC for a final backend sign-off. @larowlan, would you mind? 🙂

Looks like d.o is failing to render the MR? 😅 It's been flakey the past ~15 mins. So, here's the MR: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1249

@hooroomoo is going to tackle the (much bigger) FE changes 👍

wim leers → credited balintbrews → .

wim leers → credited effulgentsia → .

wim leers → credited lauriii → .

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!

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 have updated the code according to #21. Attached screenshot:

Following up on a suggestion to do user testing on this. To design a test I would need to know:
• Type of Drupal user likely to use this functionality (and therefore impacted by a change to the interface)
• Typical scenario in which the user would encounter this interface (e.g. when would they need/want to change the order of fields types in field type groups?)
• Desirable outcome from the scenario and problem the change in interface has addressed (e.g. we want to ensure the Drupal user can distinguish between the field types and field groups because not being able to do so would result in [what are the tangible negative consequences of the problem not being addressed])
Reviewing the comments above it seems @rkoller has gained input on target Drupal users the changes would impact so I am not sure if further testing is still required? and if so which unresolved questions this would seek to address?

Working on this to implement the changes as per the suggestions in #20 and #21.

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

If we have a big enough group we might tackle one of the "skeletons in the closet" in the issue summary for the meeting issue: ✨ Allow media items to be edited in a modal when using the field widget Postponed . Have prepared a few tasks covering many parts of the media module in general as well as https://www.drupal.org/project/media_library_media_modify → in particular (that module contains the code of the aforementioned issue).and along the way we could also cover 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active which also has the needs usability review tag and has the needs review status for a few weeks now. and finally we could tackle overriding alt text/decorational images covered in ✨ Override media fields from the reference field Postponed (that issue is also referenced in 📌 Design a UI to allow various kinds of alterations to referenced Media entities in a modal Active ). Everything is interconnected and has to be looked at as a whole.

Going to Chi's comment in #5

"Claro is using content property for drawing the separators. The possible fix would be to use background-image instead like Olivero does."

I think we need to go from:

.breadcrumb__item + .breadcrumb__item::before {
  display: inline-block;
  padding: 0 0.75rem;
  content: url(...); /* SVG image as content */
}

To something like:

.breadcrumb__item + .breadcrumb__item {
  position: relative;
  padding-left: 1rem; /* or adjust as needed */
}

.breadcrumb__item + .breadcrumb__item::before {
  content: "";
  position: absolute;
  left: 0;
  top: 50%;
  transform: translateY(-50%);
  width: 0.5rem;
  height: 0.5rem;
  background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' height='8' width='5'%3e%3cpath fill='currentColor' d='M1.207.647L.5 1.354 3.146 4 .5 6.647l.707.707L4.561 4z'/%3e%3c/svg%3e");
  background-repeat: no-repeat;
  background-size: contain;
}

Using a background-image avoids the problem because backgrounds are considered purely decorative by user agents and not exposed to screen readers.

While messing with this code, why not optimize the carrot (less than arrow, whatever):

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 5 8"><path fill="currentColor" d="m1.2.6-.7.8L3.1 4 .5 6.6l.7.8L4.6 4z"/></svg>

This is probably better:

.breadcrumb__item + .breadcrumb__item {
  position: relative;
  padding-left: 1rem; 
}

.breadcrumb__item + .breadcrumb__item::before {
  content: "";
  position: absolute;
  left: 0;
  top: 50%;
  transform: translateY(-50%);
  width: 0.5rem;
  height: 0.5rem;
  background-image: url("data:image/svg+xml,%3csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 5 8'%3e%3cpath fill='currentColor' d='m1.2.6-.7.8L3.1 4 .5 6.6l.7.8L4.6 4z'/%3e%3c/svg%3e");
  background-repeat: no-repeat;
  background-size: contain;
}