Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the forum module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

The original issue #5688: Resend welcome message from admin user/edit is 13 years old and 11 years ago was advanced to Drupal 7. Then 7 years ago a patch for Drupal 7 in comment #5688-27: Resend welcome message from admin user/edit passed tests and that patch still applies and works with the current drupal 7.69 version. This has been held back for 7 years while work on a drupal 8 version has been underway and that is now RTBC.

Maybe it is time to revisit the "backport to Drupal 7" before drupal 7 is declared EOL.

This issue is created to draw attention to the work already done and ready to be committed. The rationale is provided in the original issue and the patch has not been copied to this issue thread but can be added here if that helps.

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Generalize the taxonomy module's TaxonomyIndexTid plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration
• ☐ fix select option (#208, #215)
• ☑ tests

Post tasks

• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

Problem/Motivation

SectionStorage objects that were serialized in tempstore (i.e. any layouts that have uncommitted edits) will be broken when upgrading from 8.6.x to 8.7.x. The front and centre reason that I can see being as a result of #3016473: Allow a single SectionStorage plugin to be returned for a set of available contexts which changed SectionStorage plugins to implement ContextAwarePluginInterface. Since the tempstored objects would have been serialized in their old 8.6.x state, they end up being some frankensteined version of the plugin instance when they are unserialized. This will usually result in a ContextException being thrown and WSOD when attempting to edit a layout that had a tempstore entry. It also breaks one of the post update functions layout_builder_post_update_fix_tempstore_keys() as reported in #3042849: Update fix_tempstore_keys failed with lightning 4.x and Drupal 8.7.0-alpha1.

Additionally the old serialized plugin instances are missing any newly added dependency injections which can result in other errors even if you can get around the missing contexts.

Proposed resolution

It seems like the tempstored objects are malformed beyond repair after being unserialized. I couldn't figure out a way to keep any of the original data intact so for now my proposed resolution is to just remove any tempstore entries that don't have any contexts. The issue with this fix being, of course, the potential for lost work that hadn't been saved yet. If anyone has any ideas on how to keep the original tempstored section data intact I'd love to hear it!

Remaining tasks

• Post patch
• Review patch

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

Files core/modules/system/templates/checkboxes.html.twig and core/modules/system/templates/radios.html.twig are inconsistent which is inconvenient for themers. The checkboxes.html.twig file adds a 'form-checkboxes' class, but the radios.html.twig file does not add a 'form-radios' class as would be expected.

Proposed resolution

Add 'form-radios' class for consistency.

Problem/Motivation

The Drupal template projects (drupal/recommended-project and drupal/legacy-project) include dev dependencies in their composer.json file in the repository. Drupal infrastructure automatically removes these when running the subtree split for any tag (e.g. 8.9.0-alpha1), but allows them to remain for branches (e.g. 8.9.x-dev).

Proposed resolution

This behavior may be good enough. We could also consider removing the dev dependencies from the repository for 9.x.

Remaining tasks

We should update the documentation to clearly describe the situation.

User interface changes

None.

API changes

None.

Data model changes

None.

Old Summary

On the production server, and as a site builder, you shouldn't need the development libraries. So I suggest that development libraries are not included by default in Drupal core. Also, in that way the --no-dev and --update-no-dev parameters are no longer necessary for everyday-site-building.

How to create and manage a project without development libraries in the new version 8.8, where -n equals --no-interaction:

$ composer create-project drupal/recommended-project:^8.8@dev -n --no-dev mysite
$ composer update --with-dependencies --no-dev
$ composer require --update-no-dev drupal/admin_toolbar

On one hand, adding the developer tools project with for example a command like composer require drupal/devtools will be an extra step for Drupal developers, who are deep in the code. On the other hand, the benefits for those who mostly don't need these tools, like new Drupal users, site builders and dev ops people, there will be benefits. For example for dev ops people, the reduced complexity will mean less risk of unforeseen Composer events during a security update situation, like a lingering git commit blocking everything, which can grind the process down to a halt.

If the composer update --with-dependencies process breaks down, while applying late night security updates, having to debug why it happens, while under the the pressure of rolling out updates is not optimal, and might make dev ops people a little less fond of Drupal in the long run. Running composer update should be as boring a non-event as possible, and the chances of a smooth process should be maximized, by getting potential obstacles out of the way.

While there "shouldn't" be a problem, stuff happens, like with .git repository should not be included with composer package, where rfay comments:

This seems to break every composer update I do, have to remove the coder directory in vendor to fix.

Changing to a default installation, without dev dependencies

Pros

• For new Drupal users there will be less moving parts and reduced complexity
• No need to remember to use --no-dev and --update-no-dev
• You don't get a screen load of updates, and changed composer.json if you forget to add --update-no-dev
• Composer can calculate dependencies faster during composer update
• Less risk of unforeseen Composer events, like a lingering git commit blocking composer update
• Less changes in composer.lock, giving less results running git diff and better overview

Cons

• The work involved in containing the developer tools in its own drupal/devtools project
• Developers have to run composer require drupal/devtools

Statistics

Result with --no-dev, 53 packages

$ composer create-project drupal/recommended-project:^8.8@dev -n --no-dev mysite
Installing drupal/recommended-project (8.8.x-dev 995d694d3cf9c0863bb170e7c62c8f1aa6d35437)
  - Installing drupal/recommended-project (8.8.x-dev 995d694): Cloning 995d694d3c from cache
Created project in mysite
Loading composer repositories with package information
Updating dependencies
Package operations: 53 installs, 0 updates, 0 removals
  - Installing composer/installers (v1.6.0): Loading from cache
...

Stats: 24.534 items (and 91 hidden), totalling 391,2 MB

Result without --no-dev, 106 packages

$ composer create-project drupal/recommended-project:^8.8@dev -n mysiteDEV
Installing drupal/recommended-project (8.8.x-dev 995d694d3cf9c0863bb170e7c62c8f1aa6d35437)
  - Installing drupal/recommended-project (8.8.x-dev 995d694): Cloning 995d694d3c from cache
Created project in mysiteDEV
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 106 installs, 0 updates, 0 removals
  - Installing composer/installers (v1.6.0): Loading from cache
...

Stats: 29.914 items (and 208 hidden), totalling 414,8 MB

Release notes snippet

Development dependencies have been removed from the Composer Template Projects. See the change record for information on how to add development dependencies. It is recommended to only install development dependencies in development environments.

The dynamic $contexts property of \Drupal\Component\Plugin\ContextAwarePluginBase was deprecated in #3080631: Context values passed in configuration to ContextAwarePluginBase are disregarded. This issue is the one in which we will remove it.

Removes the BC layers in the extension system.

Meeting will happen in #d9readiness on drupal.slack.com.

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 9 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/node/3104659`
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

:zero: Who is here today? Comment in the thread below to introduce yourself.

:one: Do you have suggested topics you are looking to discuss? Post in this thread and we'll open threads for them as appropriate.

:two: TBD

Removes various simple BC layers in various places in Drupal\Core. More or less covering everything that doesn't have a dedicated issue yet although a few still need an issue as they seemed a bit too tricky to touch. Likely makes sense to keep this until the others are done.

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the menu_link_content, menu_ui module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
   

     switch ($route_name) {
       case 'help.page.contact':
   

   And ends either at the end of the function, or where you find another case 'something': line.

3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

1. Apply the patch.
2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
4. Review the topic text that you can see on the page, making sure of the following aspects:
   • The text is written in clear, simple, straightforward language
   • No grammar/punctuation errors
   • Valid HTML -- you can use http://validator.w3.org/ to check
   • Links within the text work
   • Instructions for tasks work
   • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

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

The documentation comment for LoggerChannelFactoryInterface::addLogger() references a non-existent Drupal class. This patch fixes that to point to the correct Symfony class:

-   * @see \Drupal\Core\DependencyInjection\Compiler\RegisterLoggersPass
+   * @see \Symfony\Component\HttpKernel\DependencyInjection\LoggerPass

This mistake was added in the original commit #1289536: Switch Watchdog to a PSR-3 logging framework - the class RegisterLoggersPass has never been a part of Drupal as far as I can tell.

Problem/Motivation

Views integration works for config fields created in the UI, but not for base fields added to the entity types in code.

As an example, consider Date module. That diligently implements datetime_range_field_views_data() to declare its custom Views filters and arguments. But if I add a date field to my entity's base fields, the Views integration is completely missing.

Proposed resolution

Add the views handler to the field annotation as with the entity annotation. Provide the default base class for standard views data. Allow custom fields to have specific classes for views data.

Remaining tasks

Write a patch for the above proposed resolution.

User interface changes

None

API changes

API completion

Data model changes

None

Release notes snippet

TBC

Problem/Motivation

Some dependencies need updating, some need to be reconsidered and removed or replaced.

Proposed resolution

The following are to be updated before Drupal 9.0.0 is released:

1. #3088369: Update Drupal 9 to Symfony 4.4-dev
2. #3041076: Update Drupal 9 to Twig 2
3. #2950132: Support PHPUnit 7 optionally in Drupal 8, while keeping support for ^6.5
4. #3091418: Update composer dependencies on 9.0.x (and followups)
5. #3078671: Pin behat/mink and behat/mink-selenium2-driver to use resolvable release
6. #3020296: [meta] Replace Symfony's classloader as it does not exist in Symfony 4
7. #3104265: Update Composer dependencies on Doctrine components in 9.0.x
8. #3104354: Update Doctrine to 2.1
9. #3104353: Test Guzzle 7.0.0-beta1
10. #3094468: [plan] Update core JavaScript (and CSS) dependencies prior to 9.0.0-beta1
11. #3104265: Update Composer dependencies on Doctrine components in 9.0.x

There is also an ongoing issue at #2864037: [META] Update core PHP dependencies which is not Drupal-9-specific.

The following will happen later after Drupal 9.0.0 sometime in Drupal 9's lifetime:

1. #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10

The following are considered for removal or replacement: #3080837: [meta] PHP (and JS) dependencies to consider decoupling or removing

The following are already not used by Drupal 8 and will be removed in Drupal 9: #3032686: Remove references to unused packages in Drupal 9's vendor hardening

Remaining tasks

See above.

User interface changes

Likely none, depends on updates with UIs.

API changes

Depend on updated dependencies that Drupal is exposing as-is.

Data model changes

Depend on updates.

Problem/Motivation

When pasting code using the source button, there is an inconsistency between DrupalLink and the way CKeditor handles anchors without href.

CKEDITOR version

This is how CKeditor handles this types of links.

Drupal version

And this is how Drupal works

The main problem is that the second image shows that this type of links cannot be removed. The unlink button is grayed.

Proposed resolution

Remove link html if they don't include any href.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

As we learned in #3087531: Use Diactoros LTS version 1.7, not 1.8 which is out of security coverage and from the maintainers, the information documented on their Support and LTS support policy is somewhat misleading, but the 2.x major version will eventually include some LTS minor that should be supported throughout D9's lifetime.

Doctrine 2.1 is currently available and requires PHP 7.1, so should potentially be compatible with Drupal 9.0.

Proposed resolution

• Update Drupal 9 to Doctrine 2.1.

Remaining tasks

• Update the requirement in composer.json.
• Resolve any compatibility issues with the update.

User interface changes

API changes

Data model changes

Release notes snippet

After upgrading to 8.8 i keep getting errors related to path_alias

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.path_alias' doesn't exist: SELECT 1 AS expression FROM {path_alias} base_table WHERE (base_table.status = :db_condition_placeholder_0) AND (base_table.path LIKE :db_condition_placeholder_1 ESCAPE '\\') LIMIT 1 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => /node% ) in Drupal\Core\Path\AliasRepository->pathHasMatchingAlias() (line 111 of core/lib/Drupal/Core/Path/AliasRepository.php).

I'm running pathauto 1.6 so that should be ok according to the release notes.

Am I missing anything?
---
Others are getting errors when attempting database updates;
[error] Update aborted by: system_update_8803
[error] Update aborted by: system_update_8804

Problem/Motivation

When Content Moderation is enabled and a user with 'view own unpublished content' creates a new piece of content and saves it in the 'draft' state they cannot see that content in either the Content Overview (Node) /admin/contentor the Managed Content (Content Moderation) admin/content/moderatedViews.

This occurs because if (a) any module implements hook_node_grants then access to the node is conditional based on if a record exists in the node_access table which (b) doesn't occur unless a node is published or another module sets access records for draft content, which Content Moderation does not do.

a) node_access_view_all_nodes docroot/core/modules/node/node.module:1014

  // If no modules implement the node access system, access is always TRUE.
  if (!\Drupal::moduleHandler()->getImplementations('node_grants')) {
    $access[$account->id()] = TRUE;
  }
  else {
    $access[$account->id()] = \Drupal::entityManager()->getAccessControlHandler('node')->checkAllGrants($account);
  }

b) \Drupal\node\NodeAccessControlHandler::acquireGrants called from \Drupal\node\Entity\Node::postSave

/**
   * {@inheritdoc}
   */
  public function acquireGrants(NodeInterface $node) {
    $grants = $this->moduleHandler->invokeAll('node_access_records', [$node]);
    // Let modules alter the grants.
    $this->moduleHandler->alter('node_access_records', $grants, $node);
    // If no grants are set and the node is published, then use the default grant.
    if (empty($grants) && $node->isPublished()) {
      $grants[] = ['realm' => 'all', 'gid' => 0, 'grant_view' => 1, 'grant_update' => 0, 'grant_delete' => 0];
    }
    return $grants;
  }

However if a module does implement hook_node_grants, the only way the content will appear in the Content Overview View (for non-admin users) is if it published.

Steps to reproduce

• Install Drupal 8.5.3
• Install a module that implements hook_node_grants i.e Content Access or Permissions by Term
• Enable Content Moderation (and it's dependency Workflows)
• Edit 'Editorial' workflow to apply to all content types
• Create a new use role 'Editor' with the following permissions:

• 'access content''access content overview''create article content''delete all revisions''delete any article content''delete article revisions''delete own article content''edit any article content''edit own article content''grant content access''grant own content access''revert all revisions''revert article revisions''use editorial transition archive''use editorial transition archived_draft''use editorial transition archived_published''use editorial transition create_new_draft''use editorial transition publish''view all revisions''view any unpublished content''view article revisions''view latest version''view own unpublished content'

• Create a new user 'editor'
• Log in as the new user
• Create a new 'article' with the title "[TEST] Title" with the "Save As" value "Draft" selected
• Go to the Content Overview View (/admin/content)
• No content is shown
• Go to Moderated Content View (admin/content/moderated)
• No content is shown
• Edit the "[TEST] Title" node (/node/1)
• Set the "Change to" field value to "Published"
• save
• Go to the Content Overview View (/admin/content)
• You should see [TEST] Title with the Status Published
• Go to Moderated Content View (admin/content/moderated)
• You should not see [TEST] Title
• Edit the "[TEST] Title" node (/node/1)
• Set the "Change to" field value to "Draft"
• Go to Moderated Content View (admin/content/moderated)
• You should see [TEST] Title with the status

Proposed resolution

I'm not sure where the solution for this needs to occur but I feel like the implications of getting it wrong could have wide reaching consequences.

Does an extra conditional need to be added to \Drupal\node\NodeAccessControlHandler::acquireGrants to check for Content Moderation and set the same defaults, if none are set, or should Content Moderation implement hook_node_access_records?

Considering Content Moderation is now part of core I think adding a check for it and setting similar defaults as published content isn't a bad thing. Of course the 'gid' would need to be set using the users role, but would this allow other roles with more perms to access the content? This approach would also mean a test could be added in Content Moderation for the Content Overview View checking for draft visibility

I'm leaning more towards Content Moderation implementing hook_node_grants and hook_access_records - but that is where I wanted to find some validation from the community that this approach is going to be acceptable.

Remaining tasks

• Determine the best approach for handling this.
• Add/update tests in Content Moderation

1. so that the Views being tested against exactly match the default views.view.moderated_content, currently none of the test Views in content_moderation_test_viewshave the same access setting as content_moderation
2. add test coverage for draft content in Content Overview

We are migrating youtube links from D6 link fields to D8 remote video media entities. Prior to that, we successfully migrated a D6 image node-type to image media entities without any issues. The video migration looks like this:

field_media_oembed_video: field_record_source/0/url

The migration fails with this error:

Error: Call to a member function mainPropertyName() on null in Drupal\media\MediaSourceBase->getSourceFieldValue() (line 336 of /var/www/docroot/core/modules/media/src/MediaSourceBase.php).

The underlying problem is that, in MediaSourceBase::getSourceFieldValue() the fields mainPropertyName() method is called even if the field is empty. I am not sure if the problem is really the MediaSourceBase::getSourceFieldValue() method or that the field itself returns the wrong value when it is empty, but I wrote a patch that checks if the field is empty before trying to call the fields mainPropertyName() method.