Problem/Motivation

After upgrading to 8.8, our tests started throwing exceptions in various places that weren't checking if $route_match->getRouteObject() returned NULL. One of those places is in layout_builder_system_breadcrumb_alter

I'm not entirely sure what changed between 8.7 and 8.8, but it seems to be to do with rendering content controlled by layout_builder outside of a route context, for example during search indexing.

See the full stack trace below:

1) Drupal\Tests\apra_publications_search\Functional\PublicationsSearchTest::testPublicationsSearch
Error: Call to a member function hasOption() on null

/data/app/core/modules/layout_builder/layout_builder.module:336
/data/app/core/lib/Drupal/Core/Extension/ModuleHandler.php:539
/data/app/core/lib/Drupal/Core/Breadcrumb/BreadcrumbManager.php:94
/data/app/core/modules/system/src/Plugin/Block/SystemBreadcrumbBlock.php:72
/data/app/core/modules/layout_builder/src/EventSubscriber/BlockComponentRenderArray.php:104
/data/app/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php:111
/data/app/core/modules/layout_builder/src/SectionComponent.php:90
/data/app/core/modules/layout_builder/src/Section.php:86
/data/app/core/modules/layout_builder/src/Entity/LayoutBuilderEntityViewDisplay.php:317
/data/app/core/modules/layout_builder/src/Entity/LayoutBuilderEntityViewDisplay.php:276
/data/app/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:351
/data/app/core/modules/node/src/NodeViewBuilder.php:24
/data/app/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:293
/data/app/core/lib/Drupal/Core/Entity/EntityViewBuilder.php:250
/data/app/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php:100
/data/app/core/lib/Drupal/Core/Render/Renderer.php:781
/data/app/core/lib/Drupal/Core/Render/Renderer.php:372
/data/app/core/lib/Drupal/Core/Render/Renderer.php:200
/data/app/core/lib/Drupal/Core/Render/Renderer.php:156
/data/app/core/lib/Drupal/Core/Render/Renderer.php:573
/data/app/core/lib/Drupal/Core/Render/Renderer.php:157
/data/app/modules/contrib/search_api/src/Plugin/search_api/processor/RenderedItem.php:276
/data/app/modules/contrib/search_api/src/Item/Item.php:272
/data/app/modules/contrib/search_api/src/Entity/Index.php:975
/data/app/modules/contrib/search_api/src/Utility/PostRequestIndexing.php:84
/data/app/modules/custom/apra_tests/tests/src/Functional/ApraTestBase.php:90
/data/app/modules/custom/apra_publications_search/tests/src/Functional/PublicationsSearchTest.php:33

Proposed resolution

Check $route_match->getRouteObject() is not NULL.

Hi there,
when sending a post request to create a custom content type entity via JSON:API, I keep getting "500 Internal Server Error" response code with an error message like this:
"The controller result claims to be providing relevant cache metadata, but leaked metadata was detected. Please ensure you are not rendering content too early. Returned object class: Drupal\\jsonapi\\ResourceResponse.".

But the entity is still get created on the site.

The custom entity has some basic fields plus two required entity reference fields to taxonomy terms. Here is an example code of the post request:{

POST /api/node/cnjws_post HTTP/1.1
Host: local.test
Accept: application/vnd.api+json
Content-Type: application/vnd.api+json
Authorization: Basic c25vd2FwaTpzTmFwMjAhOQ==
User-Agent: PostmanRuntime/7.19.0
Cache-Control: no-cache
Postman-Token: 66a6b568-a7ca-43dd-aabd-c2ab54d6c839,65e3c3ad-f66d-447c-91a8-c70b4ab0216a
Host: local.test
Accept-Encoding: gzip, deflate
Content-Length: 777
Connection: keep-alive
cache-control: no-cache

{
  "data": {
    "type": "node--cnjws_post",
    "attributes": {
      "title": "646443536 from json api",
      "field_cnjws_post_contact": "s57575tetone",
      "field_cnjws_post_contact_method": "rt463t5564",
      "field_cnjws_post_content": {
        "value": "e547474ue",
        "format": "plain_text"
      }
     
    },
    "relationships": {
      "field_cnjws_post_category": {
        "data": {
          "type": "taxonomy_term--information_post_category",
          "id": "b28c9d88-d7de-4279-84ab-4940df39c733"
        }
      },
      "field_cnjws_post_location": {
        "data": {
          "type": "taxonomy_term--information_post_location",
          "id": "0af63f2b-cfe0-4a46-9a43-2dc8b397e3fa"
        }
      }
    }
  }
}

The drupal version is 8.7.8 and json:api is enabled as part of core. Any ideas what might go wrong? Thanks.

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.

Problem/Motivation

See parent issue, #3104922: Guard against changes to Scaffold Plugin that might cause upgrade problems .

The plugin class is always instantiated by Composer before any part of the plugin runs (activate in the plugin class is the first thing that runs). Once the plugin class is loaded, it won't change, even if the rest of the plugin code is updated. Because of this dynamic, sometimes the solution is to move more responsibilities into the plugin class.

The main weakness is going to be the contract between the plugin class any any other class that it instantiates before a "post" event (e.g. post-update). Any method of any such class called by the plugin class must be frozen forever. If it is not, users will have to know to run composer update --no-plugins when they upgrade that plugin from the older version to any new version with a new API.

When we analyze the other plugins by this criteria, we see that:

The ProjectMessage plugin only has "post" events, and does not instantiate any objects in its activate method. Unless this changes, this plugin is going to be safe to update. This is also a simple plugin, so it should not have a great need to change in a way that would make future updates dangerous.

The VendorHardening plugin has both "pre" and "post" events. It would be really difficult to avoid instantiating any objects until the "post" events are called. However, the VendorHardening plugin also has very few classes: just a file security class, and a config class. As long as the API for these classes never change, the VendorHardening plugin should also be safe to update moving forward.

Proposed resolution

Convert the test from the parent issue to a build test so that we can have upgrade tests for all of the plugins, to avoid the possibility that someone might unwittingly make an unsafe change to some plugin.

Remaining tasks

tbd

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

tbd

Problem/Motivation

From #2664830-150: Add search capability to help topics (ambermatz): It is jarring [i.e., a usability bug] to enter a help search query at admin/help in the Seven (or administrative theme), then have the search results show up in the default theme (e.g. Bartik), then click on a help topics result going back to Seven (admin theme). (This is when you have the experimental Help Topics module enabled.)

For the same reason, user and node searches should continue to display in the default theme, because you usually initiate a search from that theme, and if you click through to a content item or user profile in the search results, you will be in the default theme.

So, search page plugins need the ability to specify that their results should show in the admin theme, or not.

Proposed resolution

Add annotation to search page plugins to make them display in the admin theme or (if omitted, the default) the regular theme.

Remaining tasks

[Done] Make a patch, including an automated test.
[Done] Test manually.
[Done] Create a follow-up issue to use this new annotation for the Help Search plugin that is part of the experimental Help Topics module (patch has already been verified to work with this issue's patch)
#3087879: Use admin theme annotation for help topics search

User interface changes

Some search page plugins (namely the Help search provided by the experimental Help Topics module) will have display their results in the admin theme, while all others will continue to display in the regular theme.

API changes

Nothing changes for existing plugins, as the default is still to display in the default theme. Search page plugins that want their results to display in the admin theme can add the "use_admin_theme" annotation to the annotation header in the plugin class (a follow-up issue will make this one-line change to the Help Topics module).

Data model changes

None.

Release notes snippet

New feature added for Search Page plugins: They can add "use_admin_theme = TRUE" to their plugin annotation and their results will be displayed in the admin theme instead of the default theme. Existing plugins (without this annotation) will default to FALSE, so their results will be displayed in the default site theme.

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

#size is currently representing the vertical number of lines.

The following is false:
#size: The size of the input element in characters.

Problem/Motivation

\Drupal\system\Entity\Action::setPlugin() is not actually part of any interface, despite that its docblock uses {@inheritdoc}.

  /**
   * {@inheritdoc}
   */
  public function setPlugin($plugin_id) {
    $this->plugin = $plugin_id;
    $this->getPluginCollection()->addInstanceId($plugin_id);
  }

Proposed resolution

Add this method to ActionConfigEntityInterface

API changes

Because there is a 1-1 relationship between \Drupal\system\Entity\Action and \Drupal\system\ActionConfigEntityInterface this is permissible in 8.x due to the Interfaces within non-experimental, non-test modules not tagged with either @api or @internal section of https://www.drupal.org/core/d8-bc-policy.

However, we should add a change notice.

Release notes snippet

What needs to be done is there should be "setplugin()" method availabe in ActionConfigEntityInterface for mapping 1-1 with
\Drupal\system\Entity\Action.

GDToolkit::save() calls the methods implemented from the file_system services without checking they return a failure value. FileSystem::tempnam() and FileSystem::realpath() return a Boolean value in case of error.

Problem/Motivation

Proposed resolution

Now that infrastructure supports JavaScript deprecated methods and properties (#3070521: Trigger deprecation notifications on JavaScript deprecations to notify developers that deprecated code is being used).. See #3070521-39: Trigger deprecation notifications on JavaScript deprecations to notify developers that deprecated code is being used for a similar task.

Remaining tasks

• Update the issue summary to document the API change and why the API change is necessary.
• Write a patch
• Review the patch
• Write a change record describing what JavaScript developers should do instead

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

I've been tracking down a bug that happen on a custom page that set some session variables but ended up being cached.

The result was that later users then mananged to get to that page (it's part of a multi-step process) without the session being initialized, leading to errors on the next page.

Pretty sure this is the same in 7.x.

Proposed resolution

Do not treat a page with session data as cacheable?

Remaining tasks

User interface changes

API changes

Data model changes

There is a @todo note about this.

@todo When \Drupal\Core\Config\TypedConfigManager has been fixed to use
class-based definitions, type-hint $definition to
DataDefinitionInterface. https://www.drupal.org/node/1928868

We can go ahead now as #1928868: Typed config incorrectly implements Typed Data interfaces is resolved.

After updating to Drupal 8.8.0, the Status Report (/admin/reports/status) throws a 500 error with the exception --

Uncaught PHP Exception Symfony\Component\Routing\Exception\RouteNotFoundException: "Route "entity.view.edit_form" does not exist."

This will happen if the Views UI module is not installed and a view is found to be a using the deprecated moderation_state value in content_moderation_requirements because it attempts to create a route provided by the Views UI module (entity.view.edit_form).

Workaround for now is to enable Views UI.

Type hint "\Drupal\Core\Database\Query\SelectInterface" missing for $select_query
Type hint "\Drupal\views\Plugin\views\query\QueryPluginBase" missing for $view_query

When we install minifyjs module and minify all the js files , the Autocomplete search not working . When we type something in autocomplete field , it displays js error in autocomplete.js file . please see the attached screenshot .
File path : misc/autocomplete.js

After updading a Drupal site from 8.6.16 to 8.7.1 (PostgreSQL 9.6.13 , Nginx) I get this error in almost every operation (creating a view , installing a module, importing feeds, ....) with diferent plugins

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "{whatever}" plugin does not exist.
Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan,[...]
in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 de /"
"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I use the drupal-project composer template so my update process was:

composer update --with-dependencies webflo/drupal-core-require-dev drupal/* "symfony/*" -d /<path/to/site> --no-interaction ;
cd /<path/to/site>
drush updb
drush cron
drush cr

It was not successfull, so I do this:

rm -rf vendor/*
composer update

and run again previous commands which It worked.

I though that I could be a problem with PHP version so I update from PHP 7.0 to PHP 7.3, but the error still remains.
I also thought that it could be related with a feeds module installation so delete all feeds content, feeds types, etc .. and unistall and reinstall the module several times (also run drush devel-entity-updates because drupal status report warned of a feeds field that needed to be deleted)

After see that the problem was related with multiples plugins I start looking for a more generic issue (config?, permissions?, ...) but I don't find cause/solution.

EDIT 1

Looking for a stack trace I try using drupal console:

drupal site:mode dev -v

and get this:

In DiscoveryTrait.php line 53:

  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                                                                                                                                               
  The "system.performance" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, language_reference, language, map  
  , binary, timestamp, list, datetime_iso8601, uri, integer, duration_iso8601, email, field_item:comment, field_item:datetime, field_item:daterange, field_item:file_uri, field_item:file, field_item:font  
  awesome_icon, field_item:image, field_item:link, field_item:list_integer, field_item:list_float, field_item:list_string, field_item:path, field_item:telephone, field_item:text, field_item:text_long, f  
  ield_item:text_with_summary, field_item:time_range, field_item:time, field_item:webform, field_item:email, field_item:uri, field_item:entity_reference, field_item:uuid, field_item:timestamp, field_ite  
  m:string_long, field_item:language, field_item:password, field_item:changed, field_item:float, field_item:decimal, field_item:map, field_item:boolean, field_item:integer, field_item:created, field_ite  
  m:string, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment, entity:comment:comment_forum, entity:comment_type, en  
  tity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter  
  _format, entity:image_style, entity:imce_profile, entity:language_content_settings, entity:configurable_language, entity:media_type, entity:media, entity:media:audio, entity:media:file, entity:media:i  
  mage, entity:media:remote_video, entity:media:video, entity:node_type, entity:node,[...], entity:node:page, entity:node:position, entity:rdf_mapping, entity:responsive_image_style, entity:rest_resource_config, entity:rules_reaction_rule, entity:rules_component, entity:s  
  earch_page, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:badge_type, entity:taxonom  
  y_term:categories, entity:taxonomy_term:forums, entity:taxonomy_term:materials, entity:taxonomy_term:nivel, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user, entity:use  
  r_role, entity:webform_options, entity:webform, entity:webform_submission, [..], entity:menu_link_content, entity:pathauto_pattern, entity  
  :view, entity:base_field_override, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity:entity_form_display, entity:date_format, entity_reference

Exception trace:
 () at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53
 Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php:25
 Drupal\Core\Plugin\DefaultPluginManager->getDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/DataDefinition.php:195
 Drupal\Core\TypedData\DataDefinition->getClass() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:86
 Drupal\Core\TypedData\TypedDataManager->createInstance() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:103
 Drupal\Core\TypedData\TypedDataManager->create() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/TypedConfigManager.php:394
 Drupal\Core\Config\TypedConfigManager->createFromNameAndData() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:134
 Drupal\Core\Config\StorableConfigBase->getSchemaWrapper() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:179
 Drupal\Core\Config\StorableConfigBase->castValue() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/Config.php:212
 Drupal\Core\Config\Config->save() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:150
 Drupal\Console\Command\Site\ModeCommand->overrideConfigurations() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:87
 Drupal\Console\Command\Site\ModeCommand->execute() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:987
 Symfony\Component\Console\Application->doRunCommand() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /home/"<user>"/www/"<site>"/vendor/drupal/console-core/src/Application.php:184

EDIT 2

looking at the database I found two tables from feeds module (supposed to be uninstalled)

feeds_feed feeds_subscription

running drupal console commnand drupal debug:module feeds appears as the only module uninstalled with a schema version defined

ID     Name   Package  version      schema version  status      origin
...
feeds  Feeds  Feeds  8.x-3.0-alpha5    8001         Uninstalled no core
...

EDIT 3

After enable debugging (https://drupal.stackexchange.com/questions/127182/how-do-i-enable-develo...)

I got new clues about the error ( trying to create a view) but my lack of drupal core knowledge stops me from understanding where final cause is:

</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;views.view.*&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, [...], entity:entity_form_display, entity:date_format, entity_reference in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;views.view.*&#039;) (Line: 195)
Drupal\Core\TypedData\DataDefinition-&gt;getClass() (Line: 86)
Drupal\Core\TypedData\TypedDataManager-&gt;createInstance(&#039;views.view.*&#039;, Array) (Line: 103)
Drupal\Core\TypedData\TypedDataManager-&gt;create(Object, Array) (Line: 394)
Drupal\Core\Config\TypedConfigManager-&gt;createFromNameAndData(&#039;views.view.test2&#039;, Array) (Line: 134)
Drupal\Core\Config\StorableConfigBase-&gt;getSchemaWrapper() (Line: 179)
Drupal\Core\Config\StorableConfigBase-&gt;castValue(&#039;uuid&#039;, &#039;c2f6326b-a77f-4f1e-9698-cb96154252cb&#039;) (Line: 212)
Drupal\Core\Config\Config-&gt;save() (Line: 284)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;doSave(&#039;test2&#039;, Object) (Line: 449)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 993)
Drupal\views_ui\ViewUI-&gt;save() (Line: 191)
Drupal\views_ui\ViewAddForm-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;view_add_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

Add a view.

View setting is below:
Show:paragraph
of type: choose a particular paragraph.

Block settings is below:
Create block is checked.
Block display settings is
Display format is Unformatted list of fields.
Item per block is 5.

Relationships setting is below:
Content using referred fields machine name.
Require this relationship is checked.

Field add is below:
Add Content:ID

Relationship is selected.

Result is...
No paragraph is displayed.

It is displayed in the case of normal entity reference such as media, but it seems that it is not displayed in case of paragraph entity reference revision.
It is the same result on a page, not a block.

I want to display the paragraph and the field of the content referring to the paragraph. If the field is valid, hide the field and display it as a block with the context filter.

I feel that it is a bug.

Thanks.

when visiting content page following error occurs,

TypeError: Argument 1 passed to Drupal\views\Plugin\views\field\EntityOperations::getEntityTranslation() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in /Applications/MAMP/htdocs/drupal-8.9/core/modules/views/src/Plugin/views/field/EntityOperations.php on line 142 in Drupal\views\Plugin\views\field\EntityOperations->getEntityTranslation() (line 69 of /Applications/MAMP/htdocs/drupal-8.9/core/modules/views/src/Entity/Render/EntityTranslationRenderTrait.php)

Additional People to Credit

There were several issues that had patches that were combined into this one. Additional people to credit, who worked on the other issues:
#3043460: Convert automated_cron module hook_help() to topic(s)
vadim.hirbu
BramDriesen
shwetaneelsharma

#3047585: Convert ban module hook_help() to topic(s)
lisagodare@gmail.com

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the automated_cron, ban, dblog, syslog, system, update, and user modules

Exception: Functionality in the System module that is related to themes should go in #3055055: Convert appearance-related modules: breakpoint, color, layout_builder, layout_discovery, field_layout module hook_help() to topic(s) instead.

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.

Problem/Motivation

We unified the uid base field definitions and deprecated various default value callbacks in #2949964: Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface.

On a site today, we noticed a bug with some media types because the default value callback in their uid base field override still referenced media_entity. That made me think and investigate and I also found several sites where the default value callback still uses Drupal\node\Entity\Node::getCurrentUserId, Drupal\media_entity\Entity\Media::getCurrentUserId and so on, which would fail on Drupal 9 (no default value which causes an SQL exception).

Proposed resolution

Update all possibly existing base field overrides for known entity types, fix their default value callbacks.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Step to Reproduce

1. Add media as reference field in Basic Page content type.(Allow unlimited)
2. Add basic page content.
3. While adding basic page in media section click Add Media
4. Then select Table as format.
5. In 1st column select all checkbox is missing.

My idea is that it's good to provide select all option to end user when media entity is more than 1.