#Usability

Now Drupal Git Contributor Agreement & Repository Usage Policy → says:

All code submitted to the repository that is a derivative work of Drupal must be and it will automatically be redistributed as GPL-2.0-or-later.

A font is not code that is a derivative work of Drupal.

Would it be appropriate to change the target branch of the existing merge request to 11.x (the default branch), or would you recommend creating a new branch from 11.x and applying the suggested changes there because I don't see any option to change the target branch?

Please advise on the preferred approach to proceed in line with current contribution practices.

Good idea! Put in a suggestion.

I think we should look at RevertOverridesForm too, that might be even more confusing than this one

@mark_fullmer, thanks for the idea and the MR.

In Drupal core changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to the Core change policies → . Also mentioned on the version → section of the list of issue fields documentation.

I'm not talking about removing user pictures entirely, I said remove the setting from "global theme settings". It should be per theme, if it's something the theme can handle.

I'm not sure about removing "user pictures" entirely, as I have quite a few sites where user (or avatar) pictures are included for both their authored content, profile pages, comments, etc.

But the current implementations are done using a new media entity image field for users, so this would need some major rework to be modern anyway.

Thanks!

and on a side note while going through the info files i've noticed too more detail probably out of the scope for this issue.

in pii_ui.info.yaml the second dependency is pii:pii_ui shouldnt that be just pii? and i guess it might make sense to also remove the requirement for drupal 9 in pii_ui.info.yaml and pii_api.info.yaml

After a brief discussion at todays monthly track meeting i'Ve changed the suggestion from Privacy to Privacy & Data protection per the recommendation from @jurgenhaas. According to him, the scope of the term privacy alone would have been too narrow.

the only detail, looking at the screenshot, the module names might need some adjustment as well, the three look sort of inconsistent.

This is likely needed by 🌱 [META] Experience Builder Personalization Active but otherwise I don't think there's a reason we'd block a release on this.

Tagging .

@lauriii: do you agree with ?

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!

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!

avpaderno → changed the visibility of the branch 2886816-when-you-remove to hidden.

Partial review, but I'm pretty sure I spotted some significant simplification potential? 😇

@avpaderno, Please review the changes in the MR

Path Auto is a module for to change the urls without making any changes to core code. Below is the link Path Auto Module →

UI eslint test failing.

I am working on it.

The patches are for Drupal core.

The patches are for Drupal core.

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

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

Yea but without a clear summary hard to review the code as it wasn’t clear what the we being accomplished

@smustgrave did you see #29?

Do we want a page with all revisions loaded

No, we still paginate revisions.

Can the summary be updated with what’s being proposed? Do we want a page with all revisions loaded? What if it’s 1000s of revisions

with the addition of recipes now is this something that's still needed?

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Changing to the standard issue template → would also help other contributors.

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Changing to the standard issue template → would also help other contributors.

@grimreaper I tried using this most recent patch and this didn't work for me unfortunately.

I tried using this most recent patch and this didn't work for me unfortunately.

Appears the instances have been replaced.

Definitely think a follow up will be needed but what would that scope be? Imagine tons of screenshots will need to be updated.

Also imagine Admin toolbar will need a ticket

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!

Tested this manually following the steps and did notice the text would update.

Would note I did have to discard my changes in layout builder AFTER I applied the MR for the change to take hold.

benjifisher → credited rkoller → .

benjifisher → credited simohell → .

It needs to fix a complex conflict.

and while writing up the summary in the previous comment i've also noticed one other detail, for consistency reasons it might be worth a thought moving the help text on the field upload group on the second step right before the field types instead of after them, after we've enabled help text on for example the selection list group right before the field types.

I’ve demo’ed the current state of the MR at the weekly lean coffee table call from the Drupal User Group Munich on Tuesday. For the record the attendees were @drubb, @franz-m, @jurgenhaas, and @martin mayer - most experienced longtime backend developers). All in all, the first impression was a good one, an improvement over the current state. They had a few comments on certain field types and groups we’ve taken a look at, in no particular order:

• On the first step in the dialog modal, with the list of field types and groups, they commented that some field types might be placed more prominently, for example finding the link field type close to the end felt surprising - it was considered an important and often used field type, and with more additional field types listed it could get easily missed.
• In regard to the description of the group for Formatted text “…with option to assign text editor”, the with “option to assign” sounded odd and off for none native english speakers.
• Looking at the descriptions for the three field types within the Formatted text group their first remark was about the order of the descriptions.
  • They considered the detail about, if a field type is single row or multi row the most important detail, instead efficient storage was the first bullet point on the field type for short text.
  • Even though the group title is formatted text, short is explicitly mentioning that you have certain formatting options, the other two don’t have that mention. By explicitly naming it for one field type , the indirect assumption/conclusion is that it is not available on for the others.
  • Aside reconsidering the weighing of bullet points for the different field types by importance, they also suggested to reconsider the grouping of text related field types. Instead of going with Plain text and Formatted text, the suggestion was as already mentioned to make the single and multi row aspect more prominent by grouping by single row and multiple row.
• In regard to the description “Maximum values depend on the system” on the integer number field type, attendees have asked, where would it be possible to find that kind of information if it is mentioned here? A direct pointer is sort of missing.
• in the File upload group it was confusing to see the example of jpeg/png/webp/gif for the file as well as the image field type.
• Within the Reference group, why the “Other” field type label? It was considered confusing and sort of ambiguous.
• On a related note in general it would be helpful to provide clear and brief instructions for media/file/image when to use which

With the help of Claude I created a first draft. The priority works for a normal select box, but not for radio buttons yet

This is green now.

Want to get a review on the code changes before going ahead with a full IS update + CR.

After debugging this more it's clear that the current code is definitely masking some pretty weird issues.

E.g set up the following:
1. Install standard
2. Install content_translation module
3. Add another language (e.g Dutch)
4. Edit Basic page content type and mark it translatable
5. Create a node, then translate it to the new language, adding a revision log of "create LANGUAGE revision".

At this point this will create 2 new revisions - one for English and one for Dutch. The English one will be marked with revision_translation_affected = NULL
The node_revision table will have 2 records, but node_field_revision will have 3. 2 of those will be for vid 2, one for each language. Vid 2 for english will have values copied from vid 1 (i.e created/changed dates).
Since the revision_log field is not translateable, the node_revision table will have "create LANGUAGE revision" for vid 2, which is the default revision for english.

6. Go to node/1/revisions (i.e the English revisions page). You'll see 1 revision marked as current, but this is actually revision 1. You won't see a revision log message, which IMO is incorrect. The reason this is incorrectly shown as the current revision is because of this code:

        // We treat also the latest translation-affecting revision as current
        // revision, if it was the default revision, as its values for the
        // current language will be the same of the current default revision in
        // this case.
        $is_current_revision = $revision->isDefaultRevision() || (!$current_revision_displayed && $revision->wasDefaultRevision());

These conditions were added in #2465907: Node revision UI reverts multiple languages when only one language should be reverted → so it will be crucial we don't regress on that bug

Commit https://git.drupalcode.org/project/drupal/-/commit/7940793ae0bbfdb64fb5e...

Added related/dupe issues for core and Diff. I think the main issue here is the isRevisionTranslationAffected check.

The generic revision UI also has this same check in VersionHistoryController::loadRevisions. Whatever fix we do for Node should apply there too.

Agreed that we should keep this one simple and potentially add a language filter in another issue if needed.

As alexpott said we filter dangerous attributes so most tags that would be dangerous otherwise are not.
However we can't guarantee that we remove dangerous attributes for every possible tag (for example we didn't remove srcdoc attributes on iframe until 🐛 Remove srcdoc attributes in Xss::filter() Active ).

So in order to keep this simple and not duplicate the list of safe tags, I think we should display the warning when allowing tags that are not in filterAdmin().
This does not mean that any additional tag would be dangerous, but that it could be because our XSS filter might not remove some attribute that could be dangerous on this specific tag.

Drupal 7 is no longer supported. If this applies to a supported version, please re-open.

Drupal 7 is no longer supported. If this applies to a supported version, please re-open.

There may be some cross-over with 🐛 Details elements have incorrect aria-describedby attributes Needs work , which is RTBC.

This came up as daily BSI target

Issue summary could use some love but #129 may be worth exploring?

Hi guys

As the last feedback review was given by #41, i made another up-to-date check after all last commits and the changes seems to address the requests.
The advanced column "is gone" as the collapsible behavior.

Checked with Drupal 11.2.x-dev

anjali rathod → closed merge request !791

I think we should do this.

A language selector would allow for a closer equivalent to the current behaviour for people that need it, but the page just does not properly work as it currently is, so I think we could open a separate issue to add that, and keep things simple here.

Added Windows 11 wording for setting.

#57 feedback was addressed.

The change record should explicitly reference the config key that's being removed. There will be some cases like distributions with a full set of exported config that could end up with stale config after this change and will need to remove the key manually.

I'm confused by the update number here - left a comment on the MR.