Quantcast
Channel: Issues for Drupal core
Viewing all 298511 articles
Browse latest View live

Firefox retains form_build_id on form reloads, causing old form cache entry to be used and creating weird behavior for the Media Library widget

$
0
0

Problem/Motivation

Seems to be some issue with the form cache interaction with the media library widget, and possibly other complex widgets. Not sure where the issue is exactly though. The problem is that after clicking the "remove" button in the media library widget to remove an already-selected item, the form builder doesn't know that the remove button was clicked, and it instead assumes the first button in the form was clicked, which could be anything. On a simple node form with just a media library widget, the button it clicks is the "add media" button so the media library selection modal opens up incorrectly.

Steps to reproduce

  1. Use Firefox
  2. Clean install of Drupal with the Media Library module enabled
  3. Create a content type with a media reference field with all default settings
  4. Create a node of that type, select a media item (upload one), and save the node
  5. Edit the node and click the "remove" button in the media library widget. Observe the correct behavior of the item being removed and the widget reverting to its original empty state
  6. Don't save the node, reload the form in your browser
  7. Again, click the "remove" button in the media library widget. Observe that instead of removing the item and reverting the widget to its original state, the media library selection modal opens up incorrectly.

Here's a video demonstrating the steps above. I started with a fresh form load (no form cache set in key value).

If you have a more complex node form, like one with a paragraphs field on it, what might end up happening instead of the media library modal opening is it that the entire media library widget gets replaced with a paragraph form for a paragraph item!

The wrong behavior is because of this code in FormBuilder:

      // If a form contains a single textfield, and the ENTER key is pressed
      // within it, Internet Explorer submits the form with no POST data
      // identifying any submit button. Other browsers submit POST data as
      // though the user clicked the first button. Therefore, to be as
      // consistent as we can be across browsers, if no 'triggering_element' has
      // been identified yet, default it to the first button.
      $buttons = $form_state->getButtons();
      if (!$form_state->isProgrammed() && !$form_state->getTriggeringElement() && !empty($buttons)) {
        $form_state->setTriggeringElement($buttons[0]);
      }

The wrong element is set as the triggering element for the form submission. Why? Because the form object that's being acted on is used a cached version of the form (cached after step #4 above) which is missing the "remove" button for the media library widget. When the form is being processed, and input elements in the form are checked to see if they were pressed and were the triggering element, the "remove" button doesn't exist in the form so it never sets itself as the triggering element, so it falls back to that logic pasted in above which just picks the first button.

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet


Write functional javascript test for block visibility vertical tabs

$
0
0

Problem/Motivation

#3493182: Block visibility settings have summary duplicated in the title showed that we are missing test coverage for block visibility vertical tabs.

We should add some explicit coverage, specifically that the summaries have the correct text in them (the regression from the other issue), but would also be good to check clicking on one tab to make sure the correct form opens or similar.

Steps to reproduce

  1. Revert commit 89a009ac124657011ecaa0830a2950da48fa37ad
  2. Visit the block form and scroll down to the Visibility section, note that each vertical tab has the string "Not Required" appended.

Proposed resolution

Create test coverage for #3493182: Block visibility settings have summary duplicated in the title

Remaining tasks

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Make user roles accessible through REST APIs and the user edit form, if the user has permission

$
0
0

Problem/Motivation

It would be ok to allow users to view their own roles, through the UI at their user edit form, or through JSON:API / GraphQL. Viewing other roles shouldn't be possible as it would be a relevant information disclosure.

Steps to reproduce

  1. Install a fresh Drupal site and enable JSON:API module
  2. Add a new non-admin user with the "Content editor" role
  3. Login in as the new user and visit their user form. The user cannot view its own role
  4. Go to /jsonapi/user/user and check that the relationship roles is not present for the current user object in the collection.

Proposed resolution

Add a new permission "View own account details" to let the user view, but don't edit, their own roles.

Remaining tasks

  • Add the new permission and the AccessControlHandler changes. Done
  • Let the user view their own roles at the user edit form. Done
  • Functional test the user edit form. Done
  • Functional test the JSON:API. Done

User interface changes

Now the user can view, but don't edit, its own roles, and they cannot view other roles, from their user edit form, if they have the new "View own account details" permission.
User edit form now shows user roles

Introduced terminology

None

API changes

Now, the 'roles' relationship is returned for JSON:API own user--user object if the user has the "View own account details" permission.

Data model changes

None

Release notes snippet

A new permission "View own account details" was added to let the user view, but not edit, their granted roles.

Original report by @joaogarin

Hello,

I am using graphql with Drupal, but I think this issue might be a generic drupal core issue so opening it up in here. Currently when accessing the user roles via an endpoint (graphql, json api or REST I think ) the user's roles is always set to access denied and return empty if the user is not an administrator.

It might be a similar situation to https://www.drupal.org/project/drupal/issues/3026264 (?). With some pointers I would be able to get a patch started here and kick off the conversation.

I guess it would be ok to allow users to access their own roles by default, maybe accessing other user's roles could already be classified as an access violation of some sort.

Looking forward for some feedback! thanks! ) Cheers

Assert all expected values of in PerformanceTestTrait::assertMetrics at once

$
0
0

Problem/Motivation

Frequently, multiple things change at once in the performance metrics and the tests are very slow, so it is very time consuming to fix them.

Steps to reproduce

Build a single array of values, minus the bits we assert by range, then assert that at once.

Before:

1) Drupal\Tests\navigation\FunctionalJavascript\PerformanceTest::testLogin
Asserting CacheGetCount
Failed asserting that 64 is identical to 61.

/var/www/html/core/tests/Drupal/Tests/PerformanceTestTrait.php:672
/var/www/html/core/modules/navigation/tests/src/FunctionalJavascript/PerformanceTest.php:101

After:

Failed asserting that two arrays are identical.
--- Expected
+++ Actual
@@ @@
 Array &0 [
     'QueryCount' => 4,
-    'CacheGetCount' => 61,
+    'CacheGetCount' => 64,
     'CacheGetCountByBin' => Array &1 [
         'config' => 10,
-        'data' => 6,
+        'data' => 9,
         'access_policy' => 1,
         'bootstrap' => 6,
         'dynamic_page_cache' => 2,
@@ @@
     ],
     'CacheDeleteCount' => 0,
     'CacheTagChecksumCount' => 3,
-    'CacheTagIsValidCount' => 31,
+    'CacheTagIsValidCount' => 34,
     'CacheTagInvalidationCount' => 0,
     'ScriptCount' => 2,
     'StylesheetCount' => 1,
 ]

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Updating path alias language in workspace does not work

$
0
0

Problem/Motivation

When changing the language an existing path alias inside of a workspace, the path alias stops working.

Steps to reproduce

1. drush si
2. drush en -y workspaces content_translation
3. drush uli
4. Go to /admin/config/regional/language and add the Spanish language
5. Go to /admin/config/regional/content-language and enable translation for "Content", ensure to check "Article" under the "Content" fieldset
6. Add a new article node, and set the path alias to /test before saving it
7. Save the node
8. Switch to the staging workspace
9. Go to /admin/config/search/path/edit/1 and update the path alias to use "Not specified" language, save it.
10. Go to /test

See a 404 page.

Proposed resolution

The second proposed solution here should be reverted. That additional language condition causes the repository to not find a matching path alias if the langcode in the base & revision tables is different. This essentially means that changing the language of a path alias in a workspace does not work.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Moving modules breaks system

$
0
0

Problem/Motivation

Moving modules into contrib/custom after install doesn't seem to work. According to the documentation, all one has to do if one wants to move modules into a custom or contrib directory structure is mv the directory, and clear the cache. This does not work. In fact uninstalling a module, and installing it in one of these directories doesn't work.

Workaround: truncate the cache_container table manually.

Proposed resolution

Ultimately fix this if it can be fixed, but presently updating the documentation would help alleviate the 'oh crap' feeling of a broken site.

Remaining tasks

User interface changes

API changes

Data model changes

Fix 'Drupal.Commenting.VariableComment.MissingVar' in core/tests

$
0
0

Problem/Motivation

See #2909372-14: Enable 'Drupal.Commenting.VariableComment.MissingVar' coding standard for the reason why this child issue was created and #2909364: [meta] Fix 'Drupal.Commenting.VariableComment' coding standard for general instructions about working on Drupal.Commenting.VariableComment coding standard errors.

Steps to reproduce

Proposed resolution

Fix errors found by Drupal.Commenting.VariableComment.MissingVar in core/tests

Remaining tasks

Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

<front> menu links are missing active trail classes

$
0
0

Problem/Motivation

<front> menu links do not receive active trail classes. Reports for this problem since D7 have been about the <li> element that wraps links, but the problem can apply to the anchor links as well, depending on the theme. This is the case with Olivero where both the <li> and <a> should receive active trail classes.

Steps to reproduce

  1. Install Drupal with the Standard profile and Olivero as the theme
  2. Visit the front page.
  3. Inspect the HTML of the "Home" link in the navigation menu at the top of the page.
  4. Verify that the <a> has the attribute data-drupal-link-system-path="<front>".

Expected results

The menu link's <li> should have the .primary-nav__menu-item--active-trail class and the <a> should have the .primary-nav__menu-link--active-trail class.

To verify the expected behavior create a new node of any type, add it to the menu, visit the node, and then inspect the new menu link's HTML.

Actual results

Neither the <li> or <a> have the expected classes.

Proposed resolution

Update MenuActiveTrail::getActiveLink() to check whether <front> menu links should be returned as being active for the current request.

Before:
A screenshot of HTML showing the menu link missing the active trail classes

After:
A screenshot of HTML showing the menu link with the active trail classes after applying the merge request

Remaining tasks

  • Review the MR
  • Change record?

User interface changes

With the additional classes being applied to <front> links, there could be changes to the appearance of those links. These changes will be theme-specific.

API changes

The path.matcher service is added as a dependency to the menu.active_trail service.

Original reports

I've installed the bootstrap theme in a Drupal 8 site.
In the default main menu the home link is never active.
When I'm in the home page the class="is-active" won't appear.

This issue is not confined to any one theme. This appears to be a core issue.

See screenshots:

Active class missing (illustration)

active class missing

Active After Applying Active Class

Active Property after applying active

D7 explanation:

There is a bug with the "active-trail" class not showing up on <li> for menu items with Drupal 7.14. The problem is that "active-trail" is missing for a menu link to the front page (path "<front>"), all other links have "active-trail" just fine.

The situation is also slightly different for the horizontal primary link tabs that can be switched on from theme settings Toggle display - Main menu, than they are for the vertical navigation in the Main menu block. In the horizontal tabs the front page <li> has "active" but not "active-trail". So "active" could be used to do get around this issue for horizontal menus. But unfortunately if you want the vertical menu, there is no "active" nor "active-trail".

I verified that both "active" and "active-trail" are missing with a fresh install without any added modules on Drupal 7.4 to 7.14. The behaviour is identical with Bartik, Garland and Stark themes, as well as Zen.

The current MR fixes the bug by adding special handling for the front page when adding the active-trail class.

A better solution would be to get the 'in_active_trail' variable correctly set for links to <front>, but unfortunately I could not find out how to do that.


Add performance test coverage to the Umami term listing admin page

$
0
0

Problem/Motivation

The term listing for a vocabulary has had performance issues in the past, so we should have performance test coverage for it.

This needs example content to be useful, so can be added to the Umami install profile.

Drupal\Tests\demo_umami\FunctionalJavascript\VocabularyAdminPerformanceTest::testPerformance()

Other Umami and standard performance tests can be used as examples.

OpenTelemetryNodePagePerformanceTest
OpenTelemetryFrontPagePerformanceTest
StandardPerformanceTest

Steps to reproduce

N/A

Proposed resolution

Add performance test coverage to the Umami term listing admin page

Remaining tasks

Find out why the test is failing and fix as needed.
Review

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Random test failure in CronRunTest::testCronUI: The text "Last run: never" was not found

$
0
0

Problem/Motivation

Drupal\Tests\system\Functional\System\CronRunTest::testAutomatedCron
Failed asserting that 1691315956 is less than 1691315956.

/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:122
/var/www/html/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:55
/var/www/html/core/modules/system/tests/src/Functional/System/CronRunTest.php:82
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestResult.php:728

Occurred here:
- https://www.drupal.org/pift-ci-job/2734078#3379525: Convert enable/disable to install/uninstall in exception text
- https://www.drupal.org/pift-ci-job/2726809#3303925: D7 upgrade migration test shows incorrect node created, updated values are migrated

User entity reference selection filter default configuration schema mismatch

$
0
0

Problem/Motivation

The schema type for entity_reference_selection.default:user: roles is sequence, but the Drupal\user\Plugin\EntityReferenceSelection\Checkboxes::defaultConfiguration() returns NULL. This can cause problems under some (as yet unknown) condition when enabling the entity reference selection filter "User Role".

The Role selection returns a set of checkboxes, but the Drupal\Core\Render\Element\Checkboxes::valueCallback() expects '#default_value' to be an array.

Steps to reproduce

I have not tracked down the exact condition that triggers this yet. It works fine in most of our installs, so there is likely something else wrong, but when it does fail, I receive:

Warning: Invalid argument supplied for foreach() in /app/web/core/lib/Drupal/Core/Render/Element/Checkboxes.php on line 100

Regardless of what other issue may exist in my project, simply changing the default value from:

  /**
   * {@inheritdoc}
   */
  public function defaultConfiguration() {
    return [
      'filter' => [
        'type' => '_none',
        'role' => NULL,
      ],
      'include_anonymous' => TRUE,
    ] + parent::defaultConfiguration();
  }

to

  /**
   * {@inheritdoc}
   */
  public function defaultConfiguration() {
    return [
      'filter' => [
        'type' => '_none',
        'role' => [],
      ],
      'include_anonymous' => TRUE,
    ] + parent::defaultConfiguration();
  }

The warning is not raised. At a minimum, the default configuration should be of the same type as the schema.

Proposed resolution

Simply change the default for 'role' from NULL to [].

Remaining tasks

Confirm with the community. Provide a patch.

[Meta] Bug Smash Initiative monthly triage meta commencing 2025-01-13

$
0
0

Meta for triage credit, please note: you only need to add a comment for one issue that was triaged and closed, not every one.

Remember to add the tag 'Bug Smash Initiative' to issues that are triaged.

Increase composer-stager constraint to the current stable release

Show entity information on the Top Bar

$
0
0

Problem/Motivation

to work on this when #3484564: Define the 3 areas the Top Bar will provide is done.
When accessing the edit form or the full mode of an entity, some extra context would be helpful for the user in a way that can be detached from the page title itself and serve as contextual information to help understand what it is that is being seen.

Proposed resolution

Add the Entity title and the published status into the Contextual area of the Top Bar.

If the entity title is longer than around 40 characters, it should be cropped so it doesn't take too much space.

Unpublished Pill styles:

On smaller screens the behavior will be to crop the title to a length around 20 characters.

User interface changes

Entity information will be shown to the user in the top bar from now on.

API changes

Data model changes

Release notes snippet

Installation fails if cron runs in parallel

$
0
0

Problem/Motivation

This issue was initially reported in #3501146: Installation fails if cron runs in parallel. During the Drupal/Drupal CMS installation, the process fails if an automated cron job is triggered and executed in parallel to the installation. This can occur when certain routes, like CSS/JS asset paths, are accessed during the installation batch process.

Steps to reproduce

  1. Begin the installation of the Drupal Standard profile via the installation interface.
  2. During the installation batch process, manually access any CSS/JS asset route, such as: <YOUR_DOMAIN>/sites/default/files/css/test.css
  3. This access will trigger automated_cron, potentially causing the installation to fail.

Proposed resolution

As the Cron execution was removed during the installation by #2422681: Remove the automatic cron run from the installer, if we introduce a validation step to ensure the cron job is only executed after the installation is fully completed. This can be done by modifying the run() function in Cron.php to include a check for the install_time state variable.

Proposed code snippet:

    // We can only run cron if the installation has been completed.
    if (!$this->state->get('install_time')) {
      $this->logger->warning('Attempting to run cron while the website is not fully installed.');
      return FALSE;
    }

This adjustment will prevent cron jobs from running prematurely during the installation process and help avoid failures.


Inappropriate error when updating a field schema with existing data

$
0
0

Problem/Motivation

When attempting to update a field's cardinality programmatically using the `EntityDefinitionUpdateManager`, an error occurs if the field is stored as a property in the entity table, but the update attempts to move the field to a dedicated field table.

The error message is as follows:

<strong>TypeError: array_intersect_key(): Argument #1 ($array) must be of type array, null given in array_intersect_key()</strong> (line 2479 of /core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php)

Steps to reproduce

  1. Install a fresh Drupal core with the Node module enabled.
  2. Create content using the "Node" entity type, and ensure the "Title" field has data stored as a property in the entity table.
  3. Create a custom module with the following hook or equivalent programmatic update (the code below)
  4. Run the update or execute the programmatic code to update the field storage definition.
  5. Observe the error.
<?php

   use Drupal\Core\Field\FieldStorageDefinitionInterface;

   /**
    * Implements hook_update_N().
    */
   function mymodule_update_9001() {
     // Update definitions and schema.
     /** @var \Drupal\Core\Entity\EntityDefinitionUpdateManager $manager */
     $manager = \Drupal::entityDefinitionUpdateManager();

     /** @var \Drupal\Core\Field\BaseFieldDefinition $definition */
     $definition = $manager->getFieldStorageDefinition('title', 'node');
     // Change cardinality to trigger the schema transition.
     $definition->setCardinality(FieldStorageDefinitionInterface::CARDINALITY_UNLIMITED);
     $manager->updateFieldStorageDefinition($definition);
   }

Proposed resolution

  1. Add a check in `SqlContentEntityStorageSchema::hasColumnChanges()` to identify schema transitions where a field moves from being stored as a property in the entity table to a dedicated field table.
    This check will correctly detect schema transitions and allow the system to throw a meaningful exception instead of a generic error.
  2. Ensure that when such a schema transition is detected, the system throws a `FieldStorageDefinitionUpdateForbiddenException` with a clear message, such as:
    The SQL storage cannot change the schema for an existing field (title in node entity) with data.

We get this error because in the hasColumnChanges method, the $this->getSchemaFromStorageDefinition($storage_definition) call passes a new BaseFieldDefinition object. During verification in the requiresDedicatedTableStorage method, this returns TRUE. As a result, the getDedicatedTableSchema method is invoked, which returns the schema for a dedicated table for the corresponding field when it does not have a table.

Due to this, in the following code (see screenshot Xdebug - initialized variables.png):

foreach ($this->loadFieldSchemaData($original) as $table => $table_schema) {
  foreach ($table_schema['fields'] as $name => $spec) {
    $definition_spec = array_intersect_key($definition_schema[$table]['fields'][$name], $keys);
    $stored_spec = array_intersect_key($spec, $keys);
    if ($definition_spec != $stored_spec) {
      return TRUE;
    }
  }
}

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Add mogtofu33 as a maintainer of the new theme system's Icon API

$
0
0

Problem/Motivation

A new API for Icon management has been added to Drupal 11.1: #3471494: Add an icon management API
It allows modules and themes to define icon packs using the YAML plugin discovery system (EXTENSION_NAME.icons.yml), and exposes the icons extracted from each pack, through the 'icon' render element and the 'icon()' Twig function.

However, this API doesn't have a dedicated maintainer yet. A dedicated maintainer will be an important asset to move this API out of @internal status and to collaborate with the current and future ecosystem of Icon management contrib modules.

Proposed resolution

This API was a collaborative effort led by
Jean Valverde (mogtofu33) which did most of the development work found in the merged code.

Jean is a Drupal professional for 18 years, and on drupal.org for nearly 17 years. He is also a member of UI Suite so involved in many subjects regarding design system implementation and display building. The Icon API was built with this expertise and mindset.

The proposal is to add Jean to the Theme API maintainers with responsibilities focused on the Icon API.

Jean is already OK with this, so:

  • Discuss.
  • Approval from committers.
  • Patch, review, commit.

Hardcoded User Entity

$
0
0

Problem/Motivation

Hard coded usage of the User entity in tests prevent the developer from specifying a different class to use for the User during testing or in production.

Steps to reproduce

If tests or production require a different class for the User entity and the core User entity does not match the requirements of the test or production User class an error will occur during tests. This prevents the developer from building upon the User entity.

Proposed resolution

Use the 'createUser' method to create any new User.

Remaining tasks

None

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

None

Use modals in field creation and field edit flow

$
0
0

Problem/Motivation

The high level plan in #3346539: [Plan] Improve field creation experience proposes to move all of the field creation end editing related pages from separate pages to modal dialogs. In general, this approach is preferred for pages where the UI would take the user outside the previous context (i.e. different base route than the previous page resulting in no local tasks rendered for the page).

The current approach for selecting a field was created as a workaround to a non-modal based workflow in #3356894: Make field selection less overwhelming by introducing groups. Even at the time when this was implemented, we were aware of some challenges with the designs. However, we decided to not optimize for these since we had tested a modal based workflow earlier which didn't have these challenges. Some of these challenges were also reported in #3389200: Field selection breaks conventions and increases cognitive load.

Proposed resolution

This issue focuses on the add new field flow by having the field creation/editing process open in modals (field selection form, combined field settings form).

  • Split up FieldStorageAddForm to reduce text in a single modal into FieldStorageAddController and FieldStorageAddForm.
  • Where the first [FieldStorageAddController] handles initial field selection such as [plain text, formatted text].
  • The second half [FieldStorageAddForm] handles the fieldstorage selection such as [text, text long].
  • Replace call to [FieldStorageAddForm], with a call to [FieldStorageAddController].
  • Create new routes to reset unsaved field data on hitting the 'Change field type' and one for calling the repurposed [FieldStorageAddForm] for the second step of the field creation modal.

FAQ's

  • Keeping the label on the second step of the modal flow for field creation as it accompanies the machine name which is immutable and moving it requires making it mutable which may require extra changes in \Drupal\field\Entity\FieldConfig and \Drupal\field\Entity\FieldStorageConfig
  • Creation of dialog.url.js, This is needed because there isn't a way to "redirect" the user to a new dialog after form submission. We can't simply render the new dialog from the original route because form submissions are coupled with routing.
  • core/misc/field-list-keyboard-navigation.js change is necessary here as the bug caused due to null object results in failing tests.

Out of scope

  • Using modal flow for re-using a field to keep it in sync with the field creation flow.
  • Voiceover fixes as it requires work around FormBuilder

A working prototype that was used for validating this

Remaining tasks

  1. Mark required fields (like Label) as required.
  2. Make sure that Selection lists work. Currently, every submit button goes to the previous modal. (See Comment #17.)
  3. Make sure error messages use the same terms as the field labels. (Example: "You need to select a field type." is the error message when the field labeled "Choose an option below" is empty.)
  4. Use links or radio buttons consistently so that keyboard navigation is consistent in the various modal screens.
  5. Make sure that keyboard shortcuts like Enter, ctrl-Enter, and Tab have the expected results.: #3398568: Ajax submission by (ctrl+enter) causes jquery errors
  6. Replace the "Change field type" button with one that goes to the previous step (with context of the selected type).: #3397709: [PP-1] Replace the "Change field type" button with one that goes to the previous step
  7. Avoid modals with a single form element. For example, when adding a boolean field, one of the screens has just the label.: #3397711: Move label and machine name fields to the field config edit form
  8. Change record for Drupal\Core\Ajax\OpenModalDialogWithUrl
  9. Make sure that descriptions of field groups, field types, and options are announced by screen readers.: #73
  10. Indicate where we are in the process: something like "step 3 of 5" or list all the steps with an indication of the active one. (Maybe this can be a follow-up issue.): #3397715: Indicate where user is in the process of creating fields

Some of these are probably existing problems. (For example, #3.) Either way, they can be done in follow-up issues if they are not done as part of this issue.

User interface changes

User interface changes

Before

Start on the "Manage fields" page:

  • Path: /admin/structure/types/manage/page/fields
  • Route: entity.node.field_ui_fields
  • Controller: \Drupal\field_ui\Controller\FieldConfigListController::listing

Screenshot showing the 'Manage fields' page

Before

Follow the "Create a new field" link to the "Add field" page:

  • Path: /admin/structure/types/manage/page/fields/add-field
  • Route: field_ui.field_storage_config_add_node
  • Form: \Drupal\field_ui\Form\FieldStorageAddForm

Screenshot showing the 'Add field' page

After

Follow the "Create a new field" link to the field selection modal.

  • Path: /admin/structure/types/manage/page/fields/add-field
  • Route: field_ui.field_storage_config_add_node
  • Controller : FieldStorageAddController::getFieldSelectionForm

Before

If you select a category, such as Number, then the options appear at the bottom of the page:

Screenshot showing the bottom of the 'Add field' page with Number selected

After

After selecting a category you will be redirected to the next step to choose field storage and enter the label and machine name.

  • Path: /admin/structure/types/manage/page/fields/add-field/plain_text/true?entity_type=node
  • Route: field_ui.field_storage_config_add_sub_node
  • Form: FieldStorageAddForm

Before

Submit the form to load the "[Field name] settings for [bundle]" page:

  • Path: /admin/structure/types/manage/page/add-field/node/field_decimal (with destinations query parameters)
  • Route: field_ui.field_add_node
  • Controller: \Drupal\field_ui\Controller\FieldConfigAddController::fieldConfigAddConfigureForm

Screenshot showing the 'Decimal settings for Article' page

After

Submit the form and get to config edit for the field.

  • Path: /admin/structure/types/manage/article/add-field/node/field_name (with destinations query parameters)
  • Route: field_ui.field_add_node
  • Controller: \Drupal\field_ui\Controller\FieldConfigAddController::fieldConfigAddConfigureForm

Submit this form to create the field storage and the field, and return to the "Manage fields" page.

API changes

Data model changes

Release notes snippet

The active variant of an entity in the Live workspace should be the default revision

$
0
0

Problem/Motivation

In #3045177: Entity queries for latest revisions should return the latest workspace-specific revisions we made sure that latest revision queries executed inside a workspace only return the latest workspace-specific revisions, or the default ones for untracked entities. However, we forgot that this needs to happen in Live as well, because the concept of "latest revision" doesn't really work when the same entity is changed in different workspaces.

Proposed resolution

Ensure that the active entity variant in Live is the same as the canonical one.

Remaining tasks

Review.

User interface changes

Nope.

Introduced terminology

N/A.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

N/A.

Viewing all 298511 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>