Problem/Motivation

#3065903: Add label sort ability to Select element added the ability to sort the options in Select elements, but Radios and Checkboxes could use the same functionality.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

With Drupal 10.1.3 I encounter an PHP error message when trying to replace an existing private file or when uploading a private file:

Error: Call to undefined function Drupal\file\Element\file_move() in Drupal\file\Element\ManagedFile::valueCallback() (line 110 of /srv/shared/builds/tilburg-university.edu-42/htdocs/core/modules/file/src/Element/ManagedFile.php).

According to this change record: https://www.drupal.org/node/3223520 this function has been removed since Drupal 9.3.0 and replaced by a service.

file: modules/file/src/Element/ManagedFile.php

        // Move files to another uri scheme if a change is detected.
        // Depends on $fids having only 1 entry.
        if (!empty($fid) && isset($input['uri_scheme']) && count($fids) === 1) {
          $file = File::load($fid);
          $current_uri_scheme = explode('://', $file->getFileUri())[0];
          if ($input['uri_scheme'] !== $current_uri_scheme && file_exists($file->getFileUri())) {
            $destination = str_replace($current_uri_scheme . '://', $input['uri_scheme'] . '://', $file->getFileUri());
            $directory = \Drupal::service('file_system')->dirname($destination);
            if (\Drupal::service('file_system')->prepareDirectory($directory, FileSystemInterface::CREATE_DIRECTORY)) {
              file_move($file, $destination);
            }
          }
        }

Steps to reproduce

There are multiple ways:

1. Upload a file as public.
2. Change upload destination from public to private.

1. Replace an existing private file with another file.

1. Upload a file as private.

Proposed resolution

Double check core for deprecated functions mentioned in: https://www.drupal.org/node/3223520
Replace them with the new service.

Problem/Motivation

We have a very nice translation system in place that is based on translating fields on entities. For many cases this work very well, but in some cases we need to special care. One of these places are menu items. Right now, when you display menu items, fx with the menu block from core, all menu items are displayed regardless of it being translated or not. This is bad for a few reasons.

• Having a menu with mixed languages is often not desired for site builders / end users
• Different menu blocks can have different requierments (e.g. filter main menu by current language, but not the footer menu)
• It's not possible to hide menu items on certain languages (where they might not be relevant)

Steps to reproduce:

1. Install Drupal with several language and enable menu translation
2. Display the main menu with the core menu block
3. Create some pages with links in the main menu
4. Visit a page with the menu with a UI missing translations for menu items

Actual result:

All the menu items are displayed in the menu, untranslated in the original (or another) language.

Expected result:

Only the translated menu items are displayed in the menu.

Proposed resolution

Add a new API to allow manipulating menu link trees: this has been requested in #3091246: Allow MenuLinkTree manipulators to be altered and #2854013: Allow SystemMenuBlock tree manipulators to be altered too.

Add first usage of this API to Custom Menu Links module to add a new setting that allows limiting the menu block to display menu items for the current language, or those without a specific language (not specified, not applicable).

Remaining tasks

Decide how handle different types of menu items (from code. *.links.menu.yml, from views, from menu link entity). This could potentially be a follow-up issue.

User interface changes

TBD.

API changes

None.

Data model changes

None.

Available work-arounds

• Content Language Access
• Menu Manipulator
• Menu Multilingual
• Menu block current language

Problem/Motivation

Both BlockForm::submitForm() and EntityForm::save() save the entity.

Condition plugins with valid schemas are only correctly handled because BlockForm *saved the block twice*. Once explicitly in ::submitForm(), once in its parent ::save().
The flow was:

1. condition is checked for default state, failed due to type mismatch
2. saved in submitForm()
3. values casted to correct type by Config::castValue
4. condition is checked for default state, correctly removed
5. saved in save()

Proposed resolution

In order to properly compare the values without saving the entity twice, the values must be cast before being compared.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

So while creating/editing the menu link, the Parent item select input of the Menu Settings opens up a very long list of the every single possible menu item in one giant select list which can be a little crazy.

Steps to reproduce

- Navigate to edit any menu link.
- Open the Parent link select list.

Proposed resolution

So the proposed solution that we came up with after having a discussion with @lauriii was to have 2 separate select list. The first select list will contain the List of main menus and based on the selection of the first select list the second select list would contain it’s subitems.

Remaining tasks

1. Accessibility review

User interface changes

Current

Proposed

API changes

Data model changes

Within Olivero, if the toolbar is open and in vertical mode, various components can create horizontal scrolling including wide images, block quotes, code blocks etc.

Problem/Motivation

The code in FormBuilder::handleInputElement():

    if (!empty($element['#disabled'])) {
      if (!empty($element['#allow_focus'])) {
        $element['#attributes']['readonly'] = 'readonly';
      }
      else {
        $element['#attributes']['disabled'] = 'disabled';
      }
    }

These should actually be boolean attributes:

    if (!empty($element['#disabled'])) {
      if (!empty($element['#allow_focus'])) {
        $element['#attributes']['readonly'] = TRUE;
      }
      else {
        $element['#attributes']['disabled'] = TRUE;
      }
    }

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As part of #3343940: Field UI 2023 User Research, we noticed few challenges related to our use of local tasks:

1. Few of the test participants navigated to edit fields of an incorrect bundle or even incorrect entity type. When asked, they thought they were editing the entity type or bundle we instructed them to edit. Without knowing the content model of the site, the only indication in the UI that this is not the case is in the breadcrumb
2. Users don't always understand what's the context for the tabs (especially problematic for the second level). For example, on Manage Display there are "Default" and "Teaser" tabs, and users didn't realize they were view modes.

Nielsen Norman describes this navigation pattern as local navigation. Their definition is following:

Local navigation is a type of navigation that is contextual to the user’s current location — showing sibling pages within the current category, and if applicable, the children or nieces and nephews of the current page.

It also says that:

local navigation indicates the category of the current page and, thus, works as an orientation element.

Currently the only UI element that indicates the category and helps with the orientation is the breadcrumb.

We are also rendering the local tasks as horizontal tabs. The design pattern usually makes people expect it to change content below the tabs, not above it. This is why navigating using Drupal local tasks (rendered as horizontal tabs) feel strange to at least some of the users.

Proposed resolution

Allow displaying the page title based on the current local tasks context. This is configurable in the page title block, which is updated to use the new pattern by default in Claro. Other themes continue to use the previous experience unless they explicitly opt-in.

We need to also figure out how to indicate the correct page title for screen readers. Current proposal is to append the current page title (current tab) to the page title: [Section page title]: [Current page title], e.g. Article: Manage fields.

We are also proposing to append the section title to the document title: [Current page title] | [Section page title] | [Site title], e.g. Manage fields | Article | Drupal. We could potentially change the separator to something like : or ». This will require changes to templates, so to keep the scope of this issue as tight as possible, ideally this could be done in a follow-up.

How this looks like with the current page titles can be seen in: https://docs.google.com/spreadsheets/d/1XhQtXZA1JCwa8qnE3vp8gyW8HJT8zZxg....

Here's how the pattern looks like on Github.com.

Interesting note is that the new behavior we are adding is also how Drupal 7 page titles worked! It doesn't look like it was an intentional change from UX perspective.

Remaining tasks

1. Write a prototype patch for this and confirm with user tests that the change is an improvement over the status quo.✅: #3379160: Toolbar Prototype Usability Testing Phase I
2. Decide how to handle the screenreader titles.

User interface changes

API changes

Data model changes

Release notes snippet

This is a UX improvement to display the page title based on the current local tasks context. Previously the page title was always displaying the current page title which was confusing to some users because this left breadcrumb as the only UI element that indicates the current context.

• The page title block now have a new option to display the page title based on the current local tasks context. In Claro it is updated to use this new pattern by default. Other themes continue to use the previous experience unless they change their configuration and/or provide an upgrade path.
• The document title is also updated to include the section title.

When setting width and/or height to null in remote video media field (in one of display mode with custom values), the two hash in function render() are not equal. This occurs because the getter $request->query->getInt('max_width', NULL) returns the value 0 instead of null (line 122 in /core/modules/media/src/Controller/OEmbedIframeController.php).

When the two hash are not equal the system returns Access Denied message and the media is not showed.

This do not occurs in a vanilla based installation (I don't know why...).

Problem/Motivation

Max value can be less than min value for NumericItems.

(Ps. I find it a bit surprising how such an obvious bug could slip through, so I searched the Core number.module's issue queue before opening this thread.)

Steps to reproduce

Tested scenarios:

1. Field type: Number (decimal)
   On these paths of entities:
   • Node: /admin/structure/types/manage/page/fields/node.page.field_number_decimal/storage
   • Taxonomy: /admin/structure/taxonomy/manage/forums/overview/fields/taxonomy_term.forums.field_number_decimal
   • User: /admin/config/people/accounts/fields/user.user.field_number_decimal
2. Field type: Number (float)
   On these paths of entities:
   • Node: /admin/structure/types/manage/page/fields/node.page.field_number_float
   • Taxonomy: /admin/structure/taxonomy/manage/forums/overview/fields/taxonomy_term.forums.field_number_float
   • User: /admin/config/people/accounts/fields/user.user.field_number_float
3. Field type: Number (integer)
   On these paths of entities:
   • Node: /admin/structure/types/manage/page/fields/node.page.field_number_integer
   • Taxonomy: /admin/structure/taxonomy/manage/forums/overview/fields/taxonomy_term.forums.field_number_integer
   • User: /admin/config/people/accounts/fields/user.user.field_number_integer

Test settings:

• Min = 4
• Max = -4
• Default = 2

Test results:

• Expected: form validation should deny submitted values
• Result: settings saved into DB.

Proposed resolution

Add tests of min and max value.

Remaining tasks

Start with the patches from the duplicate issue;

• #3327767-5: integer with minimum but no maximum causing ValueError: mt_rand(): Argument #2 ($max) must be greater than or equal to argument #1 ($min)
• #3327767-7: integer with minimum but no maximum causing ValueError: mt_rand(): Argument #2 ($max) must be greater than or equal to argument #1 ($min)

Add tests
patch
review
commit

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While reviewing #2035079: [PP-3] Figure out what to do with the install/uninstall modules page at #3373236: Drupal Usability Meeting 2023-07-14 we agreed that using a drop/split button for the module links could provide a better overall user experience, and make the module list slightly more consistent with other areas of Core.

Currently, the module links are hidden in the expandable description detail element, so moving them to a more prominent position could make them easier to access.

Steps to reproduce

Proposed resolution

This would involve adding a drop/split button to the far-right side of each module in the module list and moving the module links out of the expandable description detail element.

For installed module, the drop/split button would contain the existing links. We may also want to add a Uninstall link, as this could provide a slightly more convenient way of uninstalling a module right from the list.

For uninstalled modules, we could provide a single Install link, this could result in a slightly more convenient experience for installing a single module, where the user could simply click the link, rather than having to select the checkbox next to the module then scroll to the button of the list. On some sites the module list can be quite lengthy, so this could save time for users.

This issue does not currently have an opinion about whether or not the module link icons should be retained. Discussion and prototypes/screenshots may be required to assess how well icons work in a split/drop button layout.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

symfony/filesystem is currently a dev-dependency of Drupal core, which allows its use during the development of core, but not during actual site development. The component is not included in either the tarball or composer versions of Drupal

This issue aims to promote the dependency out of dev status, making those components available to parts of core Drupal developers may use in their projects.

Issues/Projects Impacted

#3364885: [PP-2] Making a theme compatible with core's theme generator is too difficult aims to use symfony/filesystem to mirror entire theme directories using a well-tested method rather than a custom recursive copy function. Additionally, filesystem is useful in renaming files as we change all instances of theme A's machine name and label in file names over to theme B's analogs

The automatic updates initiative also makes use of the filesystem component, though it seems their dependency structure is going through php-tuf/composer-stager rather than Drupal core.

Background

In slack, @catch says:

The main thing with both is that they've got overlap, but not interchangeable, with subsystems we've already got in core, so ideally we'd identify where that overlap is and isn't, and what should and shouldn't be converted etc. - it doesn't need to be fully done but it'd be good to have a start considering the last time this was looked at was ten years ago for finder.

Also that's probably the only thing, the normal dependency evaluation stuff is covered by 'it's another Symfony component' so it's just making sure we know where the lines are between it and existing code. We have the same overlap issues with the translation component (which we've been careful to avoid dependencies on) and other code.

If the answer is 'no we shouldn't use any of it', that's fine too but it should go in a change record or something.

Next Steps

1. Need someone with PHP expertise evaluate symfony/filesystem for additional potential usage outside of its use for starterkit
2. If there are no additional potential usages, we need to make sure that's reflected in the change record

For example, in a custom layout situation where the region content appears in a structure like this:

<div {{ region_attributes.first }}>
  <div>
    {{ content.first }}
  </div>
</div>

The Drag-and-drop reordering doesn't work because the selector takes .js-layout-builder-region > .js-layout-builder-block instead of .js-layout-builder-region .js-layout-builder-block.

Problem/Motivation

While reviewing #3097907: Active toolbar tray has weak affordance and fails WCAG color criteria during accessibility office hours (thanks!), @rainbreaw pointed out that while the new styles for the active tray are much better, the focus style is still very difficult to parse to see what item in the toolbar (either top-level tabs or even links within each subtray) currently has focus.

#3020422: Toolbar style update aims to improve this for Claro, but we should fix it in the core toolbar styles and Seven, too.

Steps to reproduce

1. Install Drupal core.
2. Login as an admin user that can access the toolbar.
3. Tab around and try to figure out which item has focus.

Proposed resolution

Add a focus ring to the toolbar styles so that the item with focus is truly obvious. Details TBD.

Remaining tasks

1. Design the right thing.
2. Implement it.
3. Write or expand tests for this?
4. Reviews / refinements.

User interface changes

TBD

API changes

Data model changes

Release notes snippet

Problem/Motivation

We are planning to rewrite UI Patterns upon SDC. To achieve this, we are proposing a few changes and additions:

• #3390980: Make SDC extensible
• #3352063: [PP-1] Allow schema references in Single Directory Component prop schemas
• #3390712: Add component variants to SDC
• #3390717: Allow declaration of template path in SDC
• SDC ComponentElement: Transform slots scalar values to #plain_text. The current issue
• #3391978: SDC: Add a method to retrieve only components not replaced by others

Today, #slots property of ComponentElement accepts only render arrays.

If something else is send, there is a fatal error:

Unable to render component "%s". A render array is expected for the slot "%s" when using the render element with the "#slots" property

We believe such a strong behaviour and expected verbosity don't fit with developers expectations and may hurt SDC adoption.

Steps to reproduce

When using component render element, instead of doing this:

[
     '#type' => 'component',
    '#component' => 'ui_patterns_test:close_button',
    '#slots' => [
       "foo" => [
           "#plain_text" => "Bar",
       ]
   ],
    '#props' => []
];

Do that:

[
    '#type' => 'component',
    '#component' => 'ui_patterns_test:close_button',
    '#slots' => [
      'foo' => "Bar",
    ],
    '#props' => []
];

Proposed resolution

More or less something like that:

@@ -105,13 +105,10 @@ class ComponentElement extends RenderElement {
     $template .= sprintf('{%% embed \'%s\' %%}', $id);
     $template .= PHP_EOL;
     foreach ($slots as $slot_name => $slot_value) {
-      if (!Utilities::isRenderArray($slot_value)) {
-        $message = sprintf(
-          'Unable to render component "%s". A render array is expected for the slot "%s" when using the render element with the "#slots" property',
-          $id,
-          $slot_name
-        );
-        throw new InvalidComponentDataException($message);
+      if (!Utilities::isRenderArray($slot_value) && \is_scalar($slot_value)) {
+        $slot_value = [
+          "#plain_text" => (string) $slot_value,
+        ];
       }
       $context[$slot_name] = array_reduce(
         $slots_alter_callbacks,

With update of related tests.

Remaining tasks

If there is a chance for this change to be accepted, we (UI Patterns team) can propose a merge request soon.

We have one month before the release of Drupal 10.2.0-alpha1.

API changes

It seems safe. Nothing breaking.

Problem/Motivation

We are planning to rewrite UI Patterns upon SDC. To achieve this, we are proposing a few changes and additions:

• #3390980: Make SDC extensible
• #3352063: [PP-1] Allow schema references in Single Directory Component prop schemas
• Introduce component variants to SDC. The current issue.
• #3390717: Allow declaration of template path in SDC
• #3391702: SDC ComponentElement: Transform slots scalar values to #plain_text instead of throwing an exception
• #3391978: SDC: Add a method to retrieve only components not replaced by others

Variants is a common feature in UI Components:

• Bootstrap cards have vertical and horizontal variants
• Material Design buttons have text, outilned, raised and unelevated variants
• ...

Declaring variants as a prop is not enough for many reasons.

1. Using a string type with enum doesn't allow proper documentation (label, description):

props:
  type: object
  properties:
    variant:
      type: string
      enum:
        - primary
        - secondary
        - inverted

2. Using a anyOf with constant is verbose and complicated:

props:
  type: object
  properties:
    variant:
      anyOf:
        - { "const": "primary", "title": "Primary", "description": "..." }
        - { "const": "secondary", "title": "Secondary", "description": "..." }
        - { "const": "inverted", "title": "Inverted", "description": "..." }

3. The prop ID is free and it will not always be "variant", but sometimes "variants", "variations", "versions", "scheme"... SDC ecosystem may suffer of this lack of consistency. A module which want to leverage components variants will have no way of guessing which prop is a variant.

Proposed resolution

Add a new "variant" property at the root of component declaration with the same structure as the slot property :

name:  Card
variants:
  primary:
    title: Primary
    description: ...
  secondary:
    title: Secondary
    description: ...
  inverted:
    title: Inverted
    description: ...
  primary:
    title: Primary
    description: ...
props: {}
slots: {}

Proposal 1: declare as variant, use as prop

Once declared, the variant is loaded a prop and used as a prop:

[
  '#type' => 'component',
  '#component' => 'card',
  '#props' => [
    'variant' => 'primary',
  ]
]

This is what we plan to do in UI Patterns 2.x if it is not done at the SDC level, not because it is our preference, but because we don't want to "hack" SDC too deeply.

Proposal 1: declare as variant, use as variant

With the introduction of a new property in the render element:

[
  '#type' => 'component',
  '#component' => 'card',
  '#variant' => 'primary',
  '#props' => [ ]
]

We have a preference for this solution.

Going further with variants templates

Some developers are using distinct template by variant:

card.component.yml
card--primary.twig
card--secondary.twig
card--inverted.twig

This can be useful when the markup is changing a lot from a variant to another, and help keeping each Twig template clean and simple.

Remaining tasks

If there is a chance for this feature to be accepted, we (UI Patterns team) can propose a merge request soon.

We have one month before the release of Drupal 10.2.0-alpha1.

API changes

Yes, but not breaking.

Problem/Motivation

In #3340712: Add Single Directory Components as a new experimental module comment #70 highlights the need to have sub-schema references, or type aliases. Then #104 explores how to use the JSON Schema reference syntax to structure complex schemas in SDC.

However we are not expanding prop schemas with $ref in the current implementation.

Proposed resolution

We can leverage the JsonSchema\SchemaStorage along with a custom URI retriever to allow referencing other schemas. I am proposing that we support module:/ and theme:/ in component props. The custom URI retriever will likely extend FileGetContents and will expand module:/my-module to file:///var/www/html/web/modules/custom/my-module (or similar).

This way we could have a module or theme with custom definitions:

In web/themes/custom/my-theme/schema-definitions.json:

{
  "$defs": {
    "iconType": {
        "type": "string",
        "enum": ["type1", "type2"]
    },
    "color": {
      "type": "string",
      "pattern": "^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$"
    }
  }
}

Then any component could do:

# ...
props:
  type: object
  properties:
    bgColor:
      $ref: theme:/my-theme/schema-definitions.json#$defs/color
      title: Background Color
# ...

Remaining tasks

Ensure schemas are expanded for all the schema uses:

1. Component validation
2. Replacement validation
3. Input validation

Note that SchemaStorage is not a full dependency but a core-dev dependency. We might need to do a similar trick as we did for setValidator.

User interface changes

None

API changes

None

Data model changes

None

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...

Enter a descriptive title (above) relating to class Table, then describe the problem you have found:

First, the documentation is missing a lot of details. Table seems to support #footer and #caption, which are not listed.

Second, the table rows are not being added to the #rows element. I don't think the table in the example would actually render correctly.

Problem/Motivation

The content translation manager sometimes looks for existing translations on the wrong revision ("active" instead of "latest") of an entity. This assumes content moderation is active for the entity, and there are at least two languages it can be translated into.

The access manager does not use the latest revision of the entity being checked for translation access if the source translation is in a draft state, and the target translation had a later draft which was just removed. This means the "active" revision of the source language is the revision before the source draft was created. If that active revision has a translation into the target language, linking to the add-translation page is technically not allowed (but no access check is currently performed for the operation).

Note that this only affects links, you can still access the actual form because it already handles loading the latest revision to work around this issue (see the top off ContentTranslationController::add().

Steps to reproduce

This was found while working on #2473873-111: Views entity operations lack cacheability support, resulting in incorrect dropbuttons because the test ContentTranslationRevisionTranslationDeletionTest::testOverview() failed. The test performs the steps below, which normally pass, but the patch from that issue now runs an access check on each operation link before rendering them.
(This is iteration 2 of the test, with the editor role. Iteration 1 passes because access checks are bypassed.)

1. Create an English published node "Test 2.1 EN"
   Verify translations can be added.
2. Add an Italian draft "Test 2.2 IT".
   Verify the draft can not be deleted because it's unpublished.
   
3. Publish the Italian translation "Test 2.3 IT"
   Verify it can be deleted.
   
4. Create an English draft "Test 2.4 EN".
   Verify Italian translation still exists.
   
5. Delete the Italian translation.
   Verify the 'Add' operation for Italian reappears. This failed
   
6. Publish the English draft "Test 2.6 EN".
   Verify the Italian translation does not reappear.
7. Add an Italian published translation "Test 2.t IT".
   Verify it can be deleted.
8. Create an Italian draft "Test 2.8 IT".
   Verify it can not be deleted.
9. Delete the Italian draft.
   Verify it can be deleted again.
10. Delete the Italian translation.
    Verify it can be added again.

When the Italian translation is deleted in step 5 the English draft "Test 2.4 EN" is the latest revision and no longer has a translation. The access manager gets its argument from the route match for the translation route, which has load_latest_revision = TRUE, but it loads the latest "active" revision - which the entity repository says is the last one which was translation affected.

The last English revision which was translation affected (titled "Test 2.1 EN") still had "Test 2.3 IT" as a translation, as the deletion created a new revision without any translations affected.

The result is that the 'Add' operation is missing for Italian on line 142 of that test. Editors still had access to the translate form if the current interface language was either Italian or French, but not in English. While the Add operation points to the Italian version of the translation form it being added depended on an access check performed on the "active" revision - which already has an Italian translation - so the link no longer show up because the URL is inaccessible.

As mentioned earlier, the page itself is still accessible in Italian or French (but not English)
There is a secondary issue in ContentTranslationController::add() which also causes problems for other links, like those in the language switcher block if you have that enabled, when testing this manually.
As the controller actually adds the target translation to the entity it will always exist for the latest revision when anything performing the same access checks after the form has loaded. The easiest way around that is to simply clone the entity for the purpose of the form so the rest of the system can rely on it being in the correct current state. Without this change the access checks only work before the form has been loaded as the latest revision is statically cached once loaded.

Proposed resolution

The access manager should use the latest revision when looking for existing translations, not the "active" revision, as already done by ContentTranslationController::add().

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

Steps to reproduce

Add a 'Test' field to the user profile at /admin/config/people/accounts/fields
Delete the 'Test' field
Actual status message: The field Test has been deleted from the User content type.
Expected status message: The field Test has been deleted from the User profile.

Add a 'Test' field to the Basic block block type at /admin/structure/block/block-content/manage/basic/fields
Delete the 'Test' field
Actual status message: The field Test has been deleted from the Basic block content type.
Expected status message: The field Test has been deleted from the Basic block block type.

Add a 'Test' field to the Default comments comment type at /admin/structure/comment/manage/comment/fields
Delete the 'Test' field
Actual Status message: The field Test has been deleted from the Default comments content type.
Expected status message: The field Test has been deleted from the Default comments comment type.

Add a 'Test' field to the Article content type at /admin/structure/types/manage/article/fields
Delete the 'Test' field
Actual Status message: The field Test has been deleted from the Article content type.
This makes sense, because the field in this instance is being delete from a 'content type'

Add a 'Test' field to the 'Audio' media type at /admin/structure/media/manage/audio/fields
Delete the 'Test' field
Actual status message: The field Test has been deleted from the Audio content type.
Expected status message: The field Test has been deleted from the Audio media type.

Add a 'Test' field to the 'Tags' vocabulary at /admin/structure/taxonomy/manage/tags/overview/fields
Delete the 'Test' field
Actual status message: The field Test has been deleted from the Tags content type.
Expected status message: The field Test has been deleted from the Tags vocabulary.

Proposed resolution

• When deleting a field from the User profile, the status message should say the field was deleted from the 'profile', not 'content type'
• When deleting a field from a Custom block type, the status message should say the field was deleted from the 'block type', not 'content type'
• When deleting a field from a Comment type, the status message should say the field was deleted from the comment type, not 'content type'
• When deleting a field from a Media type, the status message should say the field was deleted from the media type, not 'content type'
• When deleting a field from a Vocabulary, the status message should say the field was deleted from the vocabulary, not 'content type'

Remaining tasks

Discuss
Agree
Patch
Review

User interface changes

API changes

Data model changes

Release notes snippet