Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the button stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/button.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the entity-meta stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/entity-meta.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the form--password-confirm stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/form--password-confirm.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the form--text stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/form--text.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

Problem/Motivation

If a user with a blocked account tries to reset a password, this will fail with the error message

Sorry, %name is not recognized as a username or an email address.

But if they think - OK my account has gone I'll create a new one they will get the message

The username %name is already taken.
The email address %email is already taken.

Currently this is misleading for the user.

Proposed resolution

We need to first check if the user is actually blocked or active. Then we display a more accurate message describing the current user's status instead of making the user assume their account does not exist.

Remaining tasks

User interface changes

Message when blocked accounts cannot request a new password:
"%name is blocked or has not been activated yet"

API changes

None.

Problem/Motivation

If you have any kind of form element without a title and it's required you will not see that it's actually required on form validation.

Proposed resolution

The problem is, that form_get_error() returns an empty string which is implicitly casted to boolean in the following statement:
if (isset($element['#parents']) && form_get_error($element))
In _form_set_class(), check for !== NULL.

Remaining tasks

This is no longer an issue in D8.

User interface changes

n/a

API changes

n/a

Original report by @dawehner

If you have any kind of form element without a title and it's required for example you will not see that it's actually required.

The problem is that #required uses

        if (isset($elements['#title'])) {
          form_error($elements, $t('!name field is required.', array('!name' => $elements['#title'])));
        }
        else {
          form_error($elements);
        }

So form_error set's a error = '';

Now in _form_set_class

  if (isset($element['#parents']) && form_get_error($element)) {
    $element['#attributes']['class'][] = 'error';
  }

But '' is a boolean false so there is no error message.

Hello,
I've faced with this problem during migration from References to Entity reference fields.

The problem arises when we use db_insert with multiple values to add to the Postgres database.

For example we have such $values_to_add:

Array (
    [0] => Array
        (
            [entity_type] => node
            [bundle] => pub
            [deleted] => 0
            [entity_id] => 2350
            [revision_id] => 2862
            [language] => und
            [delta] => 0
            [field_author5_nid] => 2346
        )
    [1] => Array
        (
            [entity_type] => node
            [bundle] => pub
            [deleted] => 0
            [entity_id] => 2366
            [revision_id] => 2894
            [language] => und
            [delta] => 0
            [field_author5_nid] => 2374
        )
)
etc...

So we call something like:

$insert = db_insert();
$insert -> fileds(array_keys($values_to_add[0]), $values_to_add[0]);
$insert -> values($values_to_add[1]);
etc...

and finally get such $insert:

InsertQuery_pgsql Object
(...
    [insertFields:protected] => Array
        (
            [0] => entity_type
            [1] => bundle
            [2] => deleted
            [3] => entity_id
            [4] => revision_id
            [5] => language
            [6] => delta
            [7] => field_author5_target_id
        )
...
    [insertValues:protected] => Array
        (
            [0] => Array
                (
                    [entity_type] => node
                    [bundle] => pub
                    [deleted] => 0
                    [entity_id] => 2350
                    [revision_id] => 2862
                    [language] => und
                    [delta] => 0
                    [field_author5_target_id] => 2346
                )

            [1] => Array
                (
                    [0] => node
                    [1] => pub
                    [2] => 0
                    [3] => 2366
                    [4] => 2894
                    [5] => und
                    [6] => 0
                    [7] => 2374
                )
       )
)

The problem is in InsertQuery_pgsql::execute():

foreach ($this->insertValues as $insert_values) {
    foreach ($this->insertFields as $idx => $field) {
      if (isset($table_information->blob_fields[$field])) {
...
      }
      else {
        $stmt->bindParam(':db_insert_placeholder_' . $max_placeholder++, $insert_values[$idx]);
      }
    }

On the first step it binds $insert_values[$idx] to the $stmt while $idx is integer for $this->insertFields but symbolic for $this->insertValues[0].
So it binds NULL values to the statement and we could get Not-null violation.

However InsertQuery_mysql::execute() doesn't use any $idx:

foreach ($this->insertValues as $insert_values) {
      foreach ($insert_values as $value) {
        $values[':db_insert_placeholder_' . $max_placeholder++] = $value;
      }
    }

Problem/Motivation

Views contextual filters break when values contain forward slashes or when they contain hyphens and the "Transform spaces to dashes in URL" option is enabled. If a view is configured to display a summary if the filter value is not in the URL in one of these two cases, Views will print links that lead to broken pages. See #29 for a detailed description of the symptoms.

Proposed resolution

The solution may be to specially encode hyphens and forward slashes. (There are some workarounds detailed in #16 that may help folks who need a solution now.)

Remaining tasks

• Code the changes
• Write regression tests

User interface changes

Probably none.

API changes

None, per se. Encoding and decoding rules for contextual filters may change slightly.

Original report by @TravisCarden

A View with an argument set to display a summary if the argument is not present will create non-functioning links (or, more precisely, links to paths with arguments that don't work) if the terms (I've only tested with taxonomy arguments) contain any pound signs, plus signs, dashes, or backslashes (#+-/). The following special characters work just fine: !"$%&'()*,.:;<=>?@[\]^_`{|}~. I didn't test anything crazier than that. I realize this may be somewhat expected behavior, but I'm going to argue it's a bug because the broken links themselves are being generated by Views.

Problem/Motivation

After updating from 9.2 to 9.3.2, no user (including UID 1) is able to view paths like this.

/node/942/revisions/3750/view

UID 1, and a custom Role used to be able to see this page, showing the LATEST revision, that you can view by going here : /admin/content/moderated and clicking any of the titles in the left column.

As of now, this returns an access denied message, with this in the error logs.

Path: /node/942/revisions/3750/view. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 118 of /app/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

If we go to /node/942 directly, or /node/942/edit we are able to see the page as expected.

These are on brand new nodes that are created by users. The nodes have to go through a review step by editors before they are published.

I've run drush node-access-rebuild-progressive to rebuild permissions, with no effect.

In addition, the "revisions" tab isn't visible on the tool bar, and if I go to /node/942/revisions I get the same error screen.

Steps to reproduce

Core 9.3.2
See attached TXT file for list of enabled modules (and disabled).

file_move() should only be called on managed files. The problem is that the file and image fields call file_move() on a managed file object that has yet to be saved. This causes problems with contrib modules that implement hook_file_delete() because they expect $file->id() to exist. This was fixed in Devel Generate in 7.x-1.x with #2429787: File generation should use file_unmanaged_move() instead of file_move() before the file object is saved

Problem/Motivation

locale_string_is_safe() is used to check that a string is safe to be added or imported as a translation. It check if html tags contained in the string are white listed or not. It uses Xss::filter which returns well-formed HTML entities. Due to this HTML correction, non-well formed html tags are refused by locale_string_is_safe(). If a translated string contains, for example <br/>, the string is rejected. While strings with <br /> are accepted.

Proposed resolution

Make locale_string_is_safe() ignore white space in html tags.

Remaining tasks

t.b.d.

User interface changes

none

API changes

none

Data model changes

none

Problem/Motivation

In NodeViewsData::getViewsData(), $data['node_field_revision']['langcode']['help'] is set twice.

  $data['node_field_revision']['langcode']['help'] = $this->t('The language the original content is in.');
  $data['node_field_revision']['table']['wizard_id'] = 'node_field_revision';
  $data['node_field_revision']['status']['filter']['label'] = $this->t('Published');

  $data['node_field_revision']['langcode']['help'] = $this->t('The language of the content or translation.');
  $data['node_field_revision']['link_to_revision'] = [
    'field' => [
      'title' => $this->t('Link to revision'),
      'help' => $this->t('Provide a simple link to the revision.'),
      'id' => 'node_revision_link',
      'click sortable' => FALSE,
    ],
  ];

Proposed resolution

Remove one of the lines setting $data['node_field_revision']['langcode']['help'] .

Problem/Motivation

When you are creating a views page click to the menu entry settings. No menu entry is the default value, the Show as expanded checkbox is not needed.
Check attached image where I marked red.

Problem/Motivation

There are several @todo items referencing closed issues. We should remove/update them as needed.

Steps to reproduce

Proposed resolution

Remaining tasks

The MR includes several straight forward changes, but some are a little less clear:

• drupalmediaediting.js references a closed issue #3246380: [drupalMedia] Media previews do not update after alt text was modified
  

        // @todo ensure that this doesn't cause flickering after
              //   https://www.drupal.org/i/3246380 has been addressed.

• Two @todos referencing the now-closed #3231336: Add validation for HTML restrictor filters that only set forbidden_tags

• \Drupal\ckeditor5\SmartDefaultSettings::computeSmartDefaultSettings
  

  has a todo pointing to #3218985: CKEditor 5 admin UI's AJAX logic and form alterations are too complex and brittle that I'm not sure is "fixed", but at the very least the todo is outdated

• \Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testDialogAccess is an empty test with @todo to port it in a closed issue: #3245720: [drupalMedia] Support choosing a view mode for <drupal-media>.
• \Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest::testAlt has a todo to a closed
  issue asking to uncomment after #3206522: Add FunctionalJavascript test coverage for media library, but that results in a failing test.
• \Drupal\ckeditor5\Plugin\Validation\Constraint\FundamentalCompatibilityConstraintValidator::findHtmlRestrictorFilterForbiddingTags has a reference to #3231331: [PP-1] Generate test data compatible with interface in Drupal\filter_test\Plugin\Filter\FilterTestRestrictTagsAndAttributes::getHTMLRestrictions which I'm unsure will ever be un-postponed, might be better to switch this @todo to the issue that removes forbidden tag functionality altogether ?

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When Drupal in installed in a non-standard installation structure, DRUPAL_ROOT is defined incorrectly and various parts of Drupal don't work.

This is important because the standard way of developing a Composer package, by defining a path repository in a project to symlink a git clone of the package, isn't currently possible with Drupal core.

Definitions

- project root: the folder where the root composer.json is
- app root (also drupal root): The folder where Drupal's entry-point index.php is. This is where the HTTP request to Drupal is made. Typically PROJECT_ROOT/web.
- scaffolding: The process which copies files into the app root when Drupal is installed with Composer. This is done by a Composer plugin within Drupal.
- Composer symlinking: The technique of using a 'path' repository for a package which points to a local git clone of the package. This causes Composer to symlink the package from the git clone into its location in the project. This is a method used to develop a package which needs to be used in the context of a Composer project -- such as Drupal core.

There are various kinds of installation structures for Drupal, depending on where and how Drupal core is installed:

- drupal/recommended-project: drupal scaffolded into the web/ folder.
- plain git clone of Drupal core, with `composer install` run at its root.
- drupal/legacy-project: drupal scaffolded into the project root.
- drupal core symlinked in by Composer, such as with the joachim-n/drupal-core-development-project Composer template. (This is the best way to develop a Composer package within a project -- see https://medium.com/pvtl/local-composer-package-development-47ac5c0e5bb4.)
- drupal installed in vendor/ - this is not possible because of other issues, and will not be fixed here, but this issue should aim to make DRUPAL_ROOT correct for this structure.

What causes the problem

We use Composer to install Drupal into the app root rather than /vendor, and Drupal
expects to find files like settings.php and extensions in the app root. Because of this, code in a Drupal project falls into several 'zones':

- Composer autoloader
- Composer vendor code
- Drupal core
- Drupal scaffolded files such as index.php and update.php
- Drupal settings, files, and extensions

These different zones don't all know how to get hold of code in the other zones:

- The autoloader always knows how to load Composer vendor code, and Drupal core code, because Composer installed it.
- Composer vendor code, e.g. Drush, knows the location of the Composer autoloader relative to itself, because it knows it's in vendor/foo/bar. But it has to make assumptions for the location of Drupal core or scaffolded files.
- Drupal core doesn't know the location of anything, because where it was installed is defined in composer.json. It has to make assumptions about how to get to the autoloader. It does that with a special autoload.php file at the root of the Drupal repository. (For the drupal/recommended-project template, an autoload.php is scaffolded into web/ so that it can go one level up and find the vendor folder. In drupal/legacy-project Drupal's include() loads the repository's autoload.php, and in drupal/recommended-project the same include() loads the scaffolded autoload.php.)
- Drupal core has to make assumptions about how to find its settings.
- Composer vendor code has to make assumptions about how to find Drupal settings. This affects things like Drush and Drupal Console.
- Drupal's scaffolded files can know about all code locations, since they are written by the scaffold plugin during Composer installation. During this process we can get the location of anything from Composer, and write it into the scaffolded files.
- Drupal settings.php file: knows the location of scaffolded index.php, as that is fixed relative to itself.

These assumptions all break in non-standard installation structures. In particular, the use of __DIR__ in these assumptions breaks when Drupal is symlinked into a project.

Fixing this is difficult because Drupal has MANY different entry points:

- HTTP request to the index.php file which is scaffolded into the app root
- HTTP request to scaffolded install.php
- HTTP request to scaffolded update.php
- HTTP request to core/rebuild.php, which is not scaffolded.
- tests run with phpunit
- tests run with run-tests.sh (this case doesn't really count, as run-tests.sh is only meant for Drupal CI, whose installation structure is a known quantity: see #3228531: document run-tests.sh as not intended for public consumption)
- code in a Composer package (e.g. Drush or Console) bookstraps Drupal
- scripts in core/scripts
- HTTP request to core/modules/statistics/statistics.php (yay! special case!)

Proposed resolution

Various approaches have been tried (see old branches in the issue fork). But ultimately, there's only one thing we can rely on: Composer knows the location of everything, because it installs everything.

Asking Composer runtime API every page load is potentially a performance hit, but it's simple to have Composer write a file containing the data we need during Composer installation.

So the plan is as follows:

1. For Composer vendor code which needs to find Drupal, add a new Composer plugin which is inside core, whose sole job is to write the locations class file into the plugin's own folder. Make the plugin required by core, so it's always present, even in projects that don't use the scaffold plugin. And nobody else needs to worry about defining it, as to change the location values you set them in composer.json.

The file is written as a class, so that it can always be loaded by Composer. (Making it a plain file registered as a Composer autoload 'file' item causes problems with package dependency hierarchy.) This class currently only defines one constant, but #3208975: split the concept of DRUPAL_ROOT/app root into app root and Drupal web root could expand on that.

This plugin should always be installed with Drupal, whether using the drupal/recommended-project or drupal/legacy-project templates, or running Composer on a git clone of core.

Deprecate the $app_root parameter to DrupalKernel, since DrupalKernel uses the plugin.

2. For code in Drupal core which needs to get to the autoloader, replace all uses of __DIR__ with code which uses the actual path of the executed file. This is to prevent PHP from resolving symlinks.

API changes

- New Composer plugin in Drupal core
- new DrupalLocations class, which 3rd party code can use to find Drupal's location
- DrupalKernel's $app_root parameter in various methods is deprecated
- DrupalKernel::guessApplicationRoot is deprecated and renamed. This is protected but Drush uses it, for instance.

Original summary

I usually link drupal inside my www directory like seen in the following ls output.
I think symlinking like that is not unusual, as it helps with version controlling of own projects.

core -> ../drupalcheckout/core
.htaccess
../drupalcheckout/index.php
../drupalcheckout/modules
profiles
robots.txt -> ../drupalcheckout/robots.txt
sites
themes -> ../drupalcheckout/themes

i've attached a script which will setup such an environment in the current directory.

With this setup BASE_ROOT in install.php will be set to the drupalcheckout directory.
Install then tries to find a settings.php in ../drupalcheckout/sites/default and not ./sites/default.

same Problem and fix should be considered for update.php and authorize.php

related discussions:
#1055856: Optimize settings.php discovery
#484554: Stop relying on Apache for determining the current path

Problem/Motivation

Uninstalling the taxonomy.module results in a Drupal\Component\Plugin\Exception\PluginNotFoundException: The "taxonomy_term" entity type does not exist. when running cron.

This seems to be coming from the field.field.node.article.field_tags config shipped with the standard.profile.

How to reproduce

1. Install Drupal with the Standard profile.
2. Head over to /admin/modules/uninstall.
3. Uninstall the Taxonomy module.
4. Run cron.
5. Visit /admin/reports/dblog.
6. entity_reference logs: "The Tags bundle (entity type: taxonomy_term) was deleted. As a result, the field_tags entity reference field (entity_type: node, bundle: article) no longer has any valid bundle it can reference. The field is not working correctly anymore and has to be adjusted."
7. You should see a Drupal\Component\Plugin\Exception\PluginNotFoundException error log.

Proposed resolution

Remaining tasks

1. Write a test to confirm this.
2. Patch.

User interface changes

API changes

Data model changes

Having this field:

langcode: cs
status: true
dependencies:
  config:
    - commerce_order.commerce_order_type.default
    - field.storage.commerce_order.field_testfield
id: commerce_order.default.field_testfield
field_name: field_testfield
entity_type: commerce_order
bundle: default
label: testfield
description: ''
required: false
translatable: false
default_value: {  }
default_value_callback: ''
settings:
  min: null
  max: null
  prefix: ''
  suffix: ''
field_type: integer

langcode: cs
status: true
dependencies:
  module:
    - commerce_order
id: commerce_order.field_testfield
field_name: field_testfield
entity_type: commerce_order
type: integer
settings:
  unsigned: false
  size: normal
module: core
locked: false
cardinality: 1
translatable: true
indexes: {  }
persist_with_no_fields: false
custom_storage: false

When filled by "1" it will accept value. When filled by "01" it will fire "This value should be of the correct primitive type."

I would expect it will accept values leading with 0 because it is correct number.

I'm using config_installer to install. Almost at the end of the installation, I get the following fatal error. I previously applied patch 1356276-302, but I don't think this is related. It started happening after upgrading core to 8.3.0. The install does not finish correctly (the site has no admin user set). Any help or workaround is appreciated.

~/p/n/n/d/bin (master ⚡☡=) ./drush site-install config_installer config_installer_sync_configure_form.sync_directory=/var/www/drupal/config/sync --verbose --db-url=mysql://root:xxx@db/drupal --account-name=admin --account-pass=xxx -y
Executing: mysql --defaults-extra-file=/tmp/drush_IucryR --database=drupal --host=db --silent  < /tmp/drush_4Sag50 > /dev/null
You are about to DROP all tables in your 'drupal' database. Do you want to continue? (y/n): y
Sites directory /var/www/drupal/web/sites/default already exists -      [notice]
proceeding.
Executing: mysql --defaults-extra-file=/tmp/drush_mYQQIy --database=drupal --host=db --silent  < /tmp/drush_nu5C8H > /dev/null
Executing: mysql --defaults-extra-file=/tmp/drush_hGpyVf --database=drupal --host=db --silent  < /tmp/drush_vyJbkp
Executing: mysql --defaults-extra-file=/tmp/drush_YotAaX --database=drupal --host=db --silent  < /tmp/drush_S0z3x6
Starting Drupal installation. This takes a while. Consider using the        [ok]
--notify global option.
Error: Call to a member function getThirdPartySetting() on null in /var/www/drupal/web/core/modules/content_translation/src/ContentTranslationManager.php on line 98 #0 /var/www/drupal/web/core/modules/content_translation/content_translation.module(166): Drupal\content_translation\ContentTranslationManager->isEnabled('media', '')
#1 /var/www/drupal/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(501): content_translation_entity_bundle_info_alter(Array, NULL, NULL)
#2 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityTypeBundleInfo.php(110): Drupal\Core\Extension\ModuleHandler->alter('entity_bundle_i...', Array)
#3 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityTypeBundleInfo.php(80): Drupal\Core\Entity\EntityTypeBundleInfo->getAllBundleInfo()
#4 /var/www/drupal/web/core/lib/Drupal/Core/Entity/Plugin/DataType/Deriver/EntityDeriver.php(95): Drupal\Core\Entity\EntityTypeBundleInfo->getBundleInfo('block')
#5 /var/www/drupal/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\Core\Entity\Plugin\DataType\Deriver\EntityDeriver->getDerivativeDefinitions(Array)
#6 /var/www/drupal/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array)
#7 /var/www/drupal/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(283): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions()
#8 /var/www/drupal/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(174): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions()
#9 /var/www/drupal/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions()
#10 /var/www/drupal/web/core/lib/Drupal/Core/TypedData/DataDefinition.php(193): Drupal\Core\Plugin\DefaultPluginManager->getDefinition('field_item:stri...')
#11 /var/www/drupal/web/core/lib/Drupal/Core/Field/BaseFieldDefinition.php(566): Drupal\Core\TypedData\DataDefinition->getClass()
#12 /var/www/drupal/web/core/lib/Drupal/Core/Field/BaseFieldDefinition.php(555): Drupal\Core\Field\BaseFieldDefinition->getFieldItemClass()
#13 /var/www/drupal/web/core/lib/Drupal/Core/Field/BaseFieldDefinition.php(485): Drupal\Core\Field\BaseFieldDefinition->getMainPropertyName()
#14 /var/www/drupal/web/modules/contrib/media_entity/src/Entity/Media.php(309): Drupal\Core\Field\BaseFieldDefinition->setDefaultValue('')
#15 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php(204): Drupal\media_entity\Entity\Media::baseFieldDefinitions(Object(Drupal\Core\Entity\ContentEntityType))
#16 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php(171): Drupal\Core\Entity\EntityFieldManager->buildBaseFieldDefinitions('media')
#17 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityFieldManager.php(394): Drupal\Core\Entity\EntityFieldManager->getBaseFieldDefinitions('media')
#18 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityManager.php(154): Drupal\Core\Entity\EntityFieldManager->getFieldStorageDefinitions('media')
#19 /var/www/drupal/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(282): Drupal\Core\Entity\EntityManager->getFieldStorageDefinitions('media')
#20 /var/www/drupal/web/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php(1411): Drupal\Core\Entity\Sql\SqlContentEntityStorage->getTableMapping()
#21 /var/www/drupal/web/core/lib/Drupal/Core/Field/FieldStorageDefinitionListener.php(74): Drupal\Core\Entity\Sql\SqlContentEntityStorage->onFieldStorageDefinitionCreate(Object(Drupal\Core\Field\BaseFieldDefinition))
#22 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityManager.php(411): Drupal\Core\Field\FieldStorageDefinitionListener->onFieldStorageDefinitionCreate(Object(Drupal\Core\Field\BaseFieldDefinition))
#23 /var/www/drupal/web/core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php(169): Drupal\Core\Entity\EntityManager->onFieldStorageDefinitionCreate(Object(Drupal\Core\Field\BaseFieldDefinition))
#24 /var/www/drupal/web/core/modules/content_translation/src/ContentTranslationUpdatesManager.php(63): Drupal\Core\Entity\EntityDefinitionUpdateManager->installFieldStorageDefinition('content_transla...', 'media', 'content_transla...', Object(Drupal\Core\Field\BaseFieldDefinition))
#25 /var/www/drupal/web/core/modules/content_translation/src/ContentTranslationUpdatesManager.php(77): Drupal\content_translation\ContentTranslationUpdatesManager->updateDefinitions(Array)
#26 /var/www/drupal/web/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): Drupal\content_translation\ContentTranslationUpdatesManager->onConfigImporterImport(Object(Drupal\Core\Config\ConfigImporterEvent), 'config.importer...', Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))
#27 /var/www/drupal/web/core/lib/Drupal/Core/Config/ConfigImporter.php(644): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('config.importer...', Object(Drupal\Core\Config\ConfigImporterEvent))
#28 /var/www/drupal/web/core/lib/Drupal/Core/Config/ConfigImporter.php(488): Drupal\Core\Config\ConfigImporter->finish(Array)
#29 /var/www/drupal/web/profiles/contrib/config_installer/config_installer.profile(139): Drupal\Core\Config\ConfigImporter->doSyncStep('finish', Array)
#30 /var/www/drupal/web/core/includes/batch.inc(252): config_install_batch_process(Object(Drupal\Core\Config\ConfigImporter), 'finish', Array)
#31 /var/www/drupal/web/core/includes/form.inc(874): _batch_process()
#32 /var/www/drupal/web/core/includes/install.core.inc(625): batch_process(Object(Drupal\Core\Url), Object(Drupal\Core\Url))
#33 /var/www/drupal/web/core/includes/install.core.inc(546): install_run_task(Array, Array)
#34 /var/www/drupal/web/core/includes/install.core.inc(117): install_run_tasks(Array)
#35 /var/www/drupal/vendor/drush/drush/includes/drush.inc(726): install_drupal(Object(Composer\Autoload\ClassLoader), Array)
#36 /var/www/drupal/vendor/drush/drush/includes/drush.inc(711): drush_call_user_func_array('install_drupal', Array)
#37 /var/www/drupal/vendor/drush/drush/commands/core/drupal/site_install.inc(84): drush_op('install_drupal', Object(Composer\Autoload\ClassLoader), Array)
#38 /var/www/drupal/vendor/drush/drush/commands/core/site_install.drush.inc(254): drush_core_site_install_version('config_installe...', Array)
#39 /var/www/drupal/vendor/drush/drush/includes/command.inc(422): drush_core_site_install('config_installe...', 'config_installe...')
#40 /var/www/drupal/vendor/drush/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)
#41 /var/www/drupal/vendor/drush/drush/includes/command.inc(199): drush_command('config_installe...', 'config_installe...')
#42 /var/www/drupal/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)
#43 /var/www/drupal/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()
#44 /var/www/drupal/vendor/drush/drush/drush.php(12): drush_main()
#45 {main}
Drush command terminated abnormally due to an unrecoverable error.       [error]
Error: Call to a member function getThirdPartySetting() on null in Drupal\content_translation\ContentTranslationManager->isEnabled() (line 98 of /var/www/drupal/web/core/modules/content_translation/src/ContentTranslationManager.php).

Problem/Motivation

In #3045216: Asset paths pointing to core/misc folder assume Claro is installed in core/themes the images/core directory was created for containing copies of core icons used by Claro. These copies existed because Claro was a contrib module and it's location relative to /core was not consistent.
images/core has a readme that states

Icons in this folder are copied from Drupal core. This folder with its content
should be removed before moving Claro to Drupal core

Claro is now in Drupal core, so this change can happen.

Proposed resolution

1. In Claro's CSS Change all references to icons images/core to use the ones in core/misc/icons
2. Remove Claro's images/core directory

Remaining tasks

Problem/Motivation

#3033686: Saving Layout override will revert other field values to their values when the Layout was started. fixes the actual data loss, this issue is about how the UI *implies* there is data loss.
Steps to reproduce

1. Allow custom layout overrides on articles
2. Create an article with body value "original"
3. Save article
4. Open article /layout page
5. update article at /edit page. set body to "updated"
6. Open article /layout page
7. Article body is still "original"
8. Save layout
9. Article body is "updated"

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet