Problem/Motivation

When there is a field in a view with Broken handler then such field is still being displayed in a view.
For example when you use table as a style plugin for your view then you'll end up with an empty column having a label of that field in table header but having no values in table rows. Such a field should not be really shown in a view.

Steps to reproduce

Create a view with table style plugin with a field with Broken handler.
Look at the view.

Proposed resolution

Field with Broken handler should not be presented in a view at all.
Broken field handler class should deny access to such field.

Problem/Motivation

The existing vocabulary translation is ignored for page titles at "entity.taxonomy_vocabulary.overview_form" and "entity.taxonomy_vocabulary.reset_form" routes.

Steps to reproduce:

1. Drupal 8.6.10/8.7.x fresh install with standard profile
2. Enable the locale, config_translation and language modules.
3. As admin user, add any language at /admin/config/regional/language, for instance, Spanish
4. Add a translation for the just added language to the Tags taxonomy vocabulary at /admin/structure/taxonomy/manage/tags/translate
5. Go to the Tags vocabulary overview in the new language at /***LANGUAGE_PREFIX***/admin/structure/taxonomy/manage/tags/overview. The page title will show the vocabulary name in english, ignoring the existing translation for the current language

Proposed resolution

Enable the "with_config_overrides" option for the "taxonomy_vocabulary" parameter.

Remaining tasks

Review patch.

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

While creating a views argument handler for year+week, I discovered that the generated SQL was not correctly converting the PHP date() format 'oW' to the proper '%x%v' MySQL format.

Steps to reproduce

Proposed resolution

Add the 'o' => '%x', conversion to MysqlDateSql::$replace.

I will add a merge request shortly.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The #2999962: Unify Database/Log::findCaller and Utility/Error::getLastCaller introduced the Trying to access array offset on value of type null in Drupal\Core\Utility\Error::decodeException() on line 49.

Steps to reproduce

Try setting up an SQLite connection having the $databases array empty.

use Drupal\Core\Database\Driver\sqlite\Connection;

$config = [
  'database' => '/path/to/broken.sqlite'
];

new Connection(Connection::open($config), $config);

Proposed resolution

Check whether Database::getConnectionInfo() returns array and check the ['default']['namespace'] elements exists within it. Fall back to an empty string otherwise.

Problem/Motivation

If there is an entity storage exception thrown during module install, the watchdog_exception() is missing a replacement for the !message placeholder, so the exception message is not shown or logged.

Steps to reproduce

Using drush, install Drupal using a profile (such as Lighting https://www.drupal.org/project/lightning) that installs Contact Storage 8.x-1.1.
Note error messages:

[error]  An error occurred while notifying the creation of the id field storage definition: "!message" in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1615 of /vagrant/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
 [error]  An error occurred while notifying the creation of the created field storage definition: "!message" in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1615 of /vagrant/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
 [error]  An error occurred while notifying the creation of the uid field storage definition: "!message" in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1615 of /vagrant/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
 [error]  An error occurred while notifying the creation of the ip_address field storage definition: "!message" in Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() (line 1615 of /vagrant/docroot/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

Proposed resolution

Set exception message $e->getMessage() as replacement for !message placeholder.

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Problem/Motivation

Users with the administer workspaces permission have the ability to do various actions that could be considered disruptive on a site, for example the ability to publish any workspace to the Live site, merge any workspace into its parent, or to delete work-in-progress content by deleting a workspace created by another user.

Proposed resolution

Mark the administer workspaces as a restricted access permission.

Remaining tasks

Review.

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

Release notes snippet

Nope.

Problem/Motivation

Coming from #2677574: All Blocks removed from regions after checking "Show Global blocks".

If an admin submits a block layout form that is empty (has no blocks), all blocks in all themes are left in a broken state (they do not appear through the admin UI).

Steps to reproduce

• Install Drupal core with the "Standard" install profile.
• Enable the "Stark" theme, setting it as default.
• At Admin > Structure > Block layout (admin/structure/block), delete all blocks for the Stark theme. After deleting the blocks, click the "Save blocks" button.
• Navigate to Admin > Structure > Block layout > Bartik (admin/structure/block/list/bartik). Note that all blocks have disappeared. The following screenshot illustrates the resulting page.

Source of bug

In BlockListBuilder::submitForm() we pass a form state value directly to a ::loadMultiple() call and then iterate through the resulting entities, making changes to each:

  $entities = $this->storage->loadMultiple(array_keys($form_state->getValue('blocks')));
  /** @var \Drupal\block\BlockInterface[] $entities */
  foreach ($entities as $entity_id => $entity) {

In the case that there are no blocks present on the form:

• An empty string is returned from $form_state->getValue('blocks'), and so all items in the storage are loaded, iterated, modified (including weight and region properties set to NULL), and saved.
• Without a region value, blocks don't show up in the UI.

Mitigating factors

Because of the block cloning that occurs when a theme is initially installed (see block_theme_initialize(), it's uncommon to have a theme enabled with no blocks; and, if there are no blocks, there is no reason to submit the form.

However, the bug can easily be triggered by contrib modules modifying the block management form. Specifically, the Block Visibility Groups module provides an enhancement that includes filtering blocks to show only those in a given visibility group (initially, none). See #2677574: All Blocks removed from regions after checking "Show Global blocks".

Proposed resolution

Examine the value returned by $form_state->getValue('blocks') and pass to ::loadMultiple() only if not empty.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

This took a while to track down and may not seem like that big of a bug at first, but it's a fairly major one if your site relies heavily on dialogs/modals.

The easiest way to explain the issue is to use the closeOnEscape boolean value as an example.

When this option is passed via AJAX, it passes the actual value of false. This value is subsequently converted into a string representation due to how PHP works when it reaches DialogRenderer or ModalRenderer and becomes "false".

Thus, when it's actually passed back to JavaScript as AJAX commands in a response to actually open said dialog/modal, its actual value (a string) is treated as a positive value. This is because most code, if not all, expects this to be a boolean and treats it as such with statements like if (options.closeOnEscape).

For more details, see #2978392: Mapped option closeOnEscape doesn't work as expected.

Proposed resolution

Filter, sanitize and cast passed dialogOptions to proper values.

Remaining tasks

• Create patch
• Create test(s)

User interface changes

None

API changes

None

Data model changes

None

I added a file field to the user entity and followed the instructions here by enabling and configuring the new file_upload REST resource plugin to use simple_oauth for authentication. I then attempted to POST a new file at /file/upload/user/user/field_headshot_file?_format=json, but am getting a 403 indicating that the `administer users` permission is required. If I give the role belonging to the user in question the `administer users` permission I am able to upload the file successfully. This is contrary to how things work through the UI, however, as the user is able to login and edit their own user account without the `administer users` permission.

After talking with @wim-leers on this, he pointed me to the line in code in core/modules/file/src/Plugin/rest/resource/FileUploadResource.php that is throwing the access denied:

    $access_result = $entity_access_control_handler->createAccess($bundle, NULL, [], TRUE)
      ->andIf($entity_access_control_handler->fieldAccess('edit', $field_definition, NULL, NULL, TRUE));

It’s looking like the issue is that the FileUploadResource is checking for create access for the entity the file is being uploaded to. That *might* make sense when a user is editing a blog post (there's probably a scenario where a user can edit blogs, but not create new ones), but is seemingly overly restrictive when a user is editing their own account, since in reality, they don't need to have the ability to create new users to perform this action through the UI.

Problem/Motivation

In #2936365: Migrate UI - allow modules to declare the state of their migrations the noUpgradePath arrays were removed and replaced with entries in migrate_drupal/migrations/state/migrate_drupal.migrate_drupal.yml. There entries need to be reviewed to decide if any can be moved to a more appropriate module and then move them.

At least the i18m ones need a closer look and so do any modules that provide fields.
In #3175729: Mark i18n migrations as finished all the i18n properties were moved out of migrate_drupal.migrate_drupal.yml.

Proposed resolution

Review each migration state entry in migrate_drupal and move any that can be moved.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Creating an issue from item #1 in the parent, #2578483: [meta] Keep dumps up-to-date and improve DX.

The dumps omit uid 0. Find a way to include uid 0 so that this doesn't need to be done manually. It should be possible to import the db and use it straight away without making changes to the fixture.

Proposed resolution

TBD

Remaining tasks

Decide how to do it
Do it

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

This issue originally surfaced in Entity Browser where, in certain configurations used with Inline Entity Form or Layout Builder, there can be unexpected results:

#2764889: Entity Browser widget loses selected images in inline entity form
#3046416: Remove button conflict wrong triggering element
#3104901: Entity Browser used in a entity referenced field of a layout builder custom block is not working

But it seems the underlying issue may actually be a core FormBuilder bug.

Comment #7 in #2764889: Entity Browser widget loses selected images in inline entity form documents what's happening:

I have investigated further what makes inconsistent form state -> and I have ended in IEF module.

So what is going on (in "short"): for example when remove button is pressed without IEF

1. in processing of action (FormBuilder::processForm()), rebuild is triggered -> FormBuilder::rebuildForm() and then FormBuilder::retrieveForm() -> that will execute EntityReferenceBrowserWidget::formElement()
2. setting of new state is done in EntityReferenceBrowserWidget::formElement()
3. and after FormBuilder::retrieveForm() in FormBuilder::rebuildForm() form state will be saved (cached)
4. so we end with correct form state (when I say form state I mean form state relevant for Entity Browser)

Other case: for example when remove button is pressed within IEF

1. in processing of action (FormBuilder::processForm()), rebuild is triggered -> FormBuilder::rebuildForm() and then FormBuilder::retrieveForm() -> that will execute creating of IEF form and -> it will generate #process callback for inner form
2. and after FormBuilder::retrieveForm() in FormBuilder::rebuildForm() form state will be saved (cached)
3. after saving of form state inside FormBuilder::rebuildForm() -> FormBuilder::doBuildForm() will be triggered. That will pick up all defined #process callbacks and execute them
4. execution of defined #process callback will execute EntityReferenceBrowserWidget::formElement() and new form state will be set
5. But!!! Problem is that form state is already saved (cached) and form state set during execution of #process callback will not be saved and actions after that will have wrong form state

Inline block forms in Layout Builder work similarly to IEF, in that the entity form is built in a #process callback (see \Drupal\layout_builder\Plugin\Block\InlineBlock::blockForm()

The root issue seems to be that in \Drupal\Core\Form\FormBuilder::rebuildForm(), the form and form state is cached before the call to doBuildForm, where the #process callbacks are run. If we compare how the form cache is set in rebuildform() to processForm, we can see that in the latter method, caching is done after the doBuildForm() call, using a copy of the form array created before the doBuildForm().

While the identified issues are specific to Entity Browser, this could affect any code where form state storage is updated in #process callbacks.

Steps to reproduce

For an example with Entity Browser and Layout Builder, see #3104901: Entity Browser used in a entity referenced field of a layout builder custom block is not working

Steps to reproduce:

1. Create a custom block type with two referenced entity fields and select an entity browser to select the referenced entities for each field
2. Create a content with layout builder manage display
3. In the layout view of the content, add a custom block of the previous custom block type, select entities with the entity browser modal display for the two fields and save de block
4. Edit the custom block and try to remove the selected entites of the two fields and select new entities
5. At some point it is not possible to add or remove entities and the entity browser modal display is not showing any more

Proposed resolution

Use similar form caching code in rebuildForm() to what is done in processForm():

1. Save a copy of the form array before doBuildForm() call
2. Call doBuildForm()
3. Cache if necessary with unprocessed copy of form array saved before doBuildForm()
4. return built and processed form array

Remaining tasks

Write patch and tests.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The createInstance() interface documents that it will return an object. If it cannot create an object, it will throw an exception. The code in MigratePluginManager is very clever but if it fails to create an instance, reset() will return false because the array is empty instead of throwing an exception violating the interface.

  /**
   * Create pre-configured instance of plugin derivatives.
   *
   * @param array $id
   *   Either the plugin ID or the base plugin ID of the plugins being
   *   instantiated. Also accepts an array of plugin IDs and an empty array to
   *   load all plugins.
   * @param array $configuration
   *   An array of configuration relevant to the plugin instances. Keyed by the
   *   plugin ID.
   *
   * @return \Drupal\migrate\Plugin\MigrationInterface[]
   *   Fully configured plugin instances.
   *
   * @throws \Drupal\Component\Plugin\Exception\PluginException
   *   If an instance cannot be created, such as if the ID is invalid.
   */
  public function createInstances($id, array $configuration = []);

Proposed resolution

In #45 mikelutz pointed that createInstances is to create an array of derived migration and there are reasons why derivatives may not exist and returning an empty array is more useful for the caller to manage.

Throw a PluginNotFoundException in createInstance() if createInstances() returns an empty array
Improve createInstances() documentation.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

When a D7 site has a long text field that uses the "text_plain" format, migration errors occur.

The "text_plain" plugin does not exist

The same problem was fixed for normal textfields in #3042223: Map text_plain field formatter to string.

Proposal: implement the same fix for long text fields.

Hi All,

I am getting an issue when we create a node and mark published then published checkbox is not working properly as after deselect and click save button it is again reset as selected.

Problem/Motivation

Both EntityConverter and AdminPathConfigEntityConverter call getDefinition()/getStorage on a dynamic $entity_type_id without verifying that it does exist.

Somehow a bot visited URL's like this: /editor/jscripts/tiny_mce/plugins/advimage/image.asp, resulting in a bunch of errors and a monitoring alert for us over the holidays ;)

Proposed resolution

Check that the entity type is valid with hasDefinition(), possibly in \Drupal\Core\ParamConverter\DynamicEntityTypeParamConverterTrait::getEntityTypeFromDefaults(), display a 404 instead.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Limit this to one line easy fixes, avoid any possible controversy, or any change that would better fit with other words, such as doing chien and chiens in the same patch.

The list of words beginning with q -> s, inclusive, that are used once in one file and the name of the file.

Proposed resolution

Exclude words covered in #3210125: Fix spelling in core.* yml files

Remove the following from dictionary.txt
26 words
-querystrings
-rawurlencoding
-rbaz
-reimplementing
-reinitializes
-rescan
-reuploading
-robo
-routename
-rowtest
-rrggbb
-rxpq
-safed
-sapere
-scaffol
-screenreader
-searchpages
-serializer's
-shortnames
-someclass
-somefile
-sometext
-soofy
-startpunt
-stringis
-subpatterns

Remaining tasks

Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Whilst I am aware that if I delete fields that are referenced in a view, the view is deleted (see numerous other reports), if I remove the fields from the view prior to deleting the fields the view is still deleted. This is because the config still references the deleted fields.

I removed the following fields from my view :

- field.storage.group.field_bid_closure_date
- field.storage.group.field_bid_length
- field.storage.group.field_bid_open
- field.storage.group.field_bid_start_day
- field.storage.group.field_current_bid_period
- field.storage.group.field_earliest
- field.storage.group.field_latest_bid_date

However, if I export the view the config still references them, meaning the view would be deleted if I deleted the fields:

dependencies:
  config:
    - field.storage.group.field_bid_closure_date
    - field.storage.group.field_bid_length
    - field.storage.group.field_bid_open
    - field.storage.group.field_bid_start_day
    - field.storage.group.field_current_bid_period
    - field.storage.group.field_earliest
    - field.storage.group.field_latest_bid_date

Problem/Motivation

Currenttly, Remove Section button has a cross icon assigned, wich is closer to a "Close" action than a "Delete" action in visual language. While it can be clear for experienced users or solved with documentation, changing the Icon to a waste basket might improve the "Delete" visual meaning for the button.

I'd also suggest to change the "Configure section" button to an icon button with a pencil instead of using a text label, improving consistency to elements for this Configure/Remove toolbar on each section. To preserve the section name visible, I'd suggest adding an always visible non interactive label with the section name.

Last, I'd suggest to add a div wrapping the Section Label, Configure Button and Remove Button, and sort these elements in that order inside of it. Improving accesibility and readability for these elements. So screen readers could read the label first, and then list the options available for interaction.

Steps to reproduce

These buttons and elements are present in the Layout Builder Editor form screen at the top left corner of every section in the layout.

Proposed resolution

To write a patch (I'm working o it) altering the elements mentioned and their styles. So it can be evaluated for core integration.

Problem/Motivation

MimeTypeGuesser::guessMimeType() is typed to return "?string" (string or null) but it returns void if no guesser can find a matching value.

This leads to a TypeError when using PHP 8:

The website encountered an unexpected error. Please try again later.
TypeError: Drupal\Core\File\MimeType\MimeTypeGuesser::guessMimeType(): Return value must be of type ?string, none returned in Drupal\Core\File\MimeType\MimeTypeGuesser->guessMimeType() (line 76 of core/lib/Drupal/Core/File/MimeType/MimeTypeGuesser.php).

That method should return NULL (or a default MimeType) if nothing found.