I don't really know if this is a core issue or block cache alter issue... even I don't know if it there is any solution...
I have a website with both "User login" block and "Search" block, cached with "Globally cached" option. But when using cache on that blocks, I get duplicated ID's (i.e., #edit-submit and #edit-actions). I think it's because admins don't see "User login" block, so "Search" block HTML gets cached with #edit-submit ID. Then, when first anonymous visitor comes to the site, "Search" block HTML gets loaded from cache, and "User login" block it's dinamically generated with #edit-submit ID (because it wasn't generated dinamically before). So, the HTML generated can't be validated by automatic tools.
This also can generate bugs in javascript, and stylesheet problems (luckily for me, it's not my case).
Is there any way to avoid this? Storing somewhere IDs cached used when caching or something...
As I said, I don't know if this is a core issue or not.

I am currently running drupal 8.6.15 site. I tried to upgrade my site to the drupal version 8.7.1 using drush commands. But could not upgrade, instead it get terminated due to an unrecoverable error. Any solution to this?

My PHP version is 7.2.14.

In the terminal where drush commands are running, the following error is shown :

PHP Fatal error: Uncaught TypeError: Argument 3 passed to Drupal\views\EntityViewsData::mapFieldDefinition() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /opt/web/core/modules/views/src/EntityViewsData.php on line 290 and defined in /opt/web/core/modules/views/src/EntityViewsData.php:387
Stack trace:
#0 /opt/web/core/modules/views/src/EntityViewsData.php(290): Drupal\views\EntityViewsData->mapFieldDefinition('file_managed', 'type', NULL, Object(Drupal\Core\Entity\Sql\DefaultTableMapping), Array)
#1 /opt/web/core/modules/file/src/FileViewsData.php(16): Drupal\views\EntityViewsData->getViewsData()
#2 /opt/web/core/modules/views/views.views.inc(178): Drupal\file\FileViewsData->getViewsData()
#3 [internal function]: views_views_data()
#4 /opt/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(392): call_user_func_array('views_views_dat...', Array)
#5 /opt/web/core/modules/views/src/ViewsData.php(243): Drupal\Core\Extension\ModuleHandler->invoke('views', 'views_data')
#6 /opt/web/cor in /opt/web/core/modules/views/src/EntityViewsData.php on line 387
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Uncaught TypeError: Argument 3 passed to
Drupal\views\EntityViewsData::mapFieldDefinition() must implement
interface Drupal\Core\Field\FieldDefinitionInterface, null given,
called in /opt/web/core/modules/views/src/EntityViewsData.php on line
290 and defined in
/opt/web/core/modules/views/src/EntityViewsData.php:387
Stack trace:
#0 /opt/web/core/modules/views/src/EntityViewsData.php(290):
Drupal\views\EntityViewsData->mapFieldDefinition('file_managed',
'type', NULL, Object(Drupal\Core\Entity\Sql\DefaultTableMapping),
Array)
#1 /opt/web/core/modules/file/src/FileViewsData.php(16):
Drupal\views\EntityViewsData->getViewsData()
#2 /opt/web/core/modules/views/views.views.inc(178):
Drupal\file\FileViewsData->getViewsData()
#3 [internal function]: views_views_data()
#4 /opt/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(392):
call_user_func_array('views_views_dat...', Array)
#5 /opt/web/core/modules/views/src/ViewsData.php(243):
Drupal\Core\Extension\ModuleHandler->invoke('views', 'views_data')
#6 /opt/web/cor in
/opt/web/core/modules/views/src/EntityViewsData.php, line 387
The external command could not be executed due to an application [error]
error.
You have pending database updates. Run `drush updatedb` or visit [warning]
update.php in your browser.
Backups were restored successfully. [ok]

Got the following error notice in Recent log messages :

Notice: Undefined index: type in Drupal\views\EntityViewsData->getViewsData() (line 290 of /opt/web/core/modules/views/src/EntityViewsData.php) #0 /opt/web/core/includes/bootstrap.inc(587): _drupal_error_handler_real(8, 'Undefined index...', '/opt/web/core/m...', 290, Array) #1 /opt/web/core/modules/views/src/EntityViewsData.php(290): _drupal_error_handler(8, 'Undefined index...', '/opt/web/core/m...', 290, Array) #2 /opt/web/core/modules/file/src/FileViewsData.php(16): Drupal\views\EntityViewsData->getViewsData() #3 /opt/web/core/modules/views/views.views.inc(178): Drupal\file\FileViewsData->getViewsData() #4 [internal function]: views_views_data() #5 /opt/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(392): call_user_func_array('views_views_dat...', Array) #6 /opt/web/core/modules/views/src/ViewsData.php(243): Drupal\Core\Extension\ModuleHandler->invoke('views', 'views_data') #7 /opt/web/core/modules/views/src/ViewsData.php(160): Drupal\views\ViewsData->getData() #8 /opt/web/modules/contrib/ds/src/Plugin/Derivative/DsEntityRow.php(91): Drupal\views\ViewsData->get('block_content') #9 /opt/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(101): Drupal\ds\Plugin\Derivative\DsEntityRow->getDerivativeDefinitions(Array) #10 /opt/web/core/lib/Drupal/Component/Plugin/Discovery/DerivativeDiscoveryDecorator.php(87): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDerivatives(Array) #11 /opt/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(284): Drupal\Component\Plugin\Discovery\DerivativeDiscoveryDecorator->getDefinitions() #12 /opt/web/core/lib/Drupal/Core/Plugin/DefaultPluginManager.php(175): Drupal\Core\Plugin\DefaultPluginManager->findDefinitions() #13 /opt/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php(22): Drupal\Core\Plugin\DefaultPluginManager->getDefinitions() #14 /opt/web/core/lib/Drupal/Core/Plugin/Factory/ContainerFactory.php(16): Drupal\Core\Plugin\DefaultPluginManager->getDefinition('search_view') #15 /opt/web/core/lib/Drupal/Component/Plugin/PluginManagerBase.php(83): Drupal\Core\Plugin\Factory\ContainerFactory->createInstance('search_view', Array) #16 /opt/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(817): Drupal\Component\Plugin\PluginManagerBase->createInstance('search_view') #17 /opt/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(122): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('row') #18 /opt/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(820): Drupal\views\Plugin\views\style\StylePluginBase->init(Object(Drupal\views\ViewExecutable), Object(Drupal\views\Plugin\views\display\Page), Array) #19 /opt/web/core/modules/views/src/ViewExecutable.php(882): Drupal\views\Plugin\views\display\DisplayPluginBase->getPlugin('style') #20 /opt/web/core/modules/views/src/ViewExecutable.php(1842): Drupal\views\ViewExecutable->initStyle() #21 /opt/web/core/modules/views/src/Plugin/views/display/PathPluginBase.php(132): Drupal\views\ViewExecutable->getTitle() #22 /opt/web/core/modules/views/src/Plugin/views/display/Page.php(91): Drupal\views\Plugin\views\display\PathPluginBase->getRoute('dashboard', 'page_1') #23 /opt/web/core/modules/views/src/Plugin/views/display/PathPluginBase.php(220): Drupal\views\Plugin\views\display\Page->getRoute('dashboard', 'page_1') #24 /opt/web/core/modules/views/src/EventSubscriber/RouteSubscriber.php(120): Drupal\views\Plugin\views\display\PathPluginBase->collectRoutes(Object(Symfony\Component\Routing\RouteCollection)) #25 [internal function]: Drupal\views\EventSubscriber\RouteSubscriber->routes() #26 /opt/web/core/lib/Drupal/Core/Routing/RouteBuilder.php(146): call_user_func(Array) #27 /opt/web/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild() #28 /opt/web/core/includes/common.inc(1170): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild() #29 /opt/web/core/includes/utility.inc(52): drupal_flush_all_caches() #30 phar:///usr/bin/drush/commands/core/cache.drush.inc(302): drupal_rebuild(Object(Composer\Autoload\ClassLoader), Object(Symfony\Component\HttpFoundation\Request)) #31 phar:///usr/bin/drush/includes/command.inc(422): drush_cache_rebuild() #32 phar:///usr/bin/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array) #33 phar:///usr/bin/drush/includes/command.inc(199): drush_command() #34 phar:///usr/bin/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array) #35 phar:///usr/bin/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch() #36 phar:///usr/bin/drush/includes/startup.inc(465): drush_main() #37 phar:///usr/bin/drush/includes/startup.inc(369): drush_run_main(false, '/', 'Phar detected. ...') #38 phar:///usr/bin/drush/drush(114): drush_startup(Array) #39 /usr/bin/drush(10): require('phar:///usr/bin...') #40 {main}.

Following upgrade from 8.6.13 to 8.7, any attempt to maintain a menu from /admin/structure/menu results in a crash.

There are three 'Undefined index:' notice messages in the log like this

Notice: Undefined index: value in Drupal\menu_link_content\MenuLinkContentStorage->getMenuLinkIdsWithPendingRevisions() (Zeile 18 in [Drupal]/core/modules/menu_link_content/src/MenuLinkContentStorage.php)

followed by the following error:

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AS expression FROM pkJmv_ mlfr INNER JOIN pkJmv_ mlr ON mlfr. = mlr. AND mlr. ' at line 1: SELECT mlfr.id AS id, MAX(mlfr.) AS expression FROM {} mlfr INNER JOIN {} mlr ON mlfr. = mlr. AND mlr. = 0 INNER JOIN (SELECT t.id AS id, t.langcode AS langcode, MAX(t.) AS expression FROM {} t WHERE t. = :db_condition_placeholder_0 GROUP BY t.id, t.langcode) mr ON mlfr. = mr. AND mlfr.langcode = mr.langcode GROUP BY mlfr.id; Array ( [:db_condition_placeholder_0] => 1 ) in Drupal\menu_link_content\MenuLinkContentStorage->getMenuLinkIdsWithPendingRevisions() (Zeile 41 in [Drupal]/core/modules/menu_link_content/src/MenuLinkContentStorage.php).

I noticed MenuLinkContentStorage.php was newly introduced.

Hello,

On a fresh Drupal 8.6.13 standard install with basic_auth and jsonapi enabled.

Between jsonapi 8.x-2.0 and 8.x-2.1 with the same request, There error message is no more in the response body.

For example:

POST /jsonapi/node/page HTTP/1.1
Host: default.web.entity-share.docker.localhost
Content-Type: application/vnd.api+json
Accept: application/vnd.api+json
Authorization: Basic YWRtaW46YWRtaW4=
cache-control: no-cache
Postman-Token: a76e2355-77f5-4f53-a108-2d890ccd12ae
{
  "data": {
    "type": "node--page",
    "id": "11111111-1111-1111-1111-111111111111",
    "attributes": {
      "title": ""
    }
  }
}

There is a 422 error because there is no title.

On 8.x-2.0, I obtain the body:

{
    "errors": [
        {
            "title": "Unprocessable Entity",
            "status": 422,
            "detail": "title: This value should not be null.",
            "source": {
                "file": "/project/www/modules/contrib/jsonapi/src/Controller/EntityResource.php",
                "line": 188,
                "pointer": "/data/attributes/title"
            },
            "meta": {
                "exception": "Drupal\\jsonapi\\Exception\\UnprocessableHttpEntityException: Unprocessable Entity: validation failed. in /project/www/modules/contrib/jsonapi/src/Controller/EntityResource.php:188\nStack trace:\n#0 /project/www/module
...

And nothing on 8.x-2.1.

I can't see anything in the release notes and I am also confused because I see automated tests on the 422 error code and testing the error message.

Is there a new requirement/header I missed between those two versions?

Also there is no error message on the last dev version.

I have been able to isolate the commit. It is from a45056a Issue #3022584 by gabesullice, Wim Leers, e0ipso: Consolidate and simplify NormalizerValue objects: introduce CacheableNormalization. On this commit there is no more error message.

Thanks for any help.

Problem/Motivation

The issue is fairly straight forward...

Whenever people need to update D8 instructions are the following:
https://www.drupal.org/docs/8/update/update-core-via-composer

... Stuff
Site into maintenance.
... Stuff
Site out of maintenance.

In decoupled context there is no correct way to handle the event -

site is in maintenance mode

.
So there will be public clients hitting the website, as well as jsonapi endpoints fetching data.

The issue with the maintenance mode is easily reproducible:
1. Have public read access against jsonapi endpoints.
2. Enable site maintenance mode.
3. You get a non-valid jsonapi response and broken clients. Note that from the headers of the response clients can not distinguish that it's a maintenance mode response or some reverse proxy interrupted the request.

This is preventing safe deploys on systems running jsonapi or other modules used in decoupled context. In production environment when the system is a fully decoupled one, once the site is in maintenance mode - all public clients are down.

Proposed resolution

I know this is based on middle-ware, so either:
1. JSON:API should add it's own maintenance mode middle-ware before the core's existing one.
2. Tweak / extend the maintenance mode that core already has.

I suggest to go with option 2.
The aim is to keep existing behavior as is and just add new functionality on top.
My idea proposed in #8-11 and has a PoC implemented in #12.

Remaining tasks

Direction, patch, etc...

User interface changes

None.

API changes

Api addition - new response header (implemented in #12).

Data model changes

None.

Release notes snippet

Describe the new header.

Overview

We have a very nice translation system in place that is based on translating fields on entities. For many cases this work very well, but in some cases we need to special care. One of these places are menu items. Right now, when you display menu items, fx with the menu block from core, all menu items are displayed regardless of it being translated or not. This is bad for a few reasons.

• Having a menu with mixed languages is never desired for site builders / end users
• It's not possible to hide menu items on certain languages (where they might not be relevant)

The ideal solution would only display menu items either without a specific language or in the current language.

Reproduce

1. Install Drupal with several langauge and enable menu translation
2. Display the main menu with the core menu block
3. Create some pages with links in the main menu
4. Translate some of the menu items

Expected result:
Only the translated menu items are displayed in the menu

Actual result:
All the menu items are displayed in the menu, untranslated in the original (or another) language.

Item 4 from here needs attention
https://www.drupal.org/project/drupal/issues/2904243#comment-12405231

+++ b/core/themes/umami/css/components/blocks/footer-promo/footer-promo.css
@@ -0,0 +1,47 @@
+.footer-promo__text a {
...
+.footer-promo__text a:after {

+++ b/core/themes/umami/css/components/navigation/tabs/tabs.css
@@ -0,0 +1,35 @@
+.tabs li {
...
+.tabs a {
...
+.tabs a.is-active {
...
+.tabs a:focus,
+.tabs a:hover {

Please go through the CSS selectors using elements. We should try convert as many of them to classes as we can since it will make future changes easier for us.

Problem/Motivation

The uninstall box for Layout Builder is grayed out with the message

The Layout Section field type is used in the following field: node.layout_builder__layout

The "Manage Fields" page shows the Layout field as locked.
The "Manage Display" page says

You must revert all customized layouts of this display before you can disable this option.

Without individually checking each node, there is no way to determine which must be reverted

Proposed resolution

Several options:
1) A page under /admin/reports (linked from Manage Display?) similar to the Field List that shows all overridden layouts, with a revert option (or bulk operation?)

2) A "Revert All" button on Manage Display that works for only that single bundle (probably behind a confirmation form?)

3) ???

Remaining tasks

Decide on an approach

User interface changes

Yes, but TBD

API changes

N/A

Data model changes

N/A

Problem/Motivation

Some modals could really use a tour (e.g. contextual filters or arguments can be daunting for new developers).
Atm however it's not possible to initiate Tour from within a (modal) dialog because the dialog is modal an Tour appears in the admin menu.

This is a follow up issue for Tour tip display under toolbar. In there the question was raised if we should show Tour tips above or below dialogs. If we want to support tour for dialogs it should be above.

Proposed resolution

We could add the tour icon near the close icon in the modal.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

how can i use the UI to migrate from csv file to eck entity?

thanks

I'm getting the following runtime error in my PHP's error_log:

[Thu Jul 31 20:54:59 2014] [error] [client 98.176.242.59] PHP Fatal error: Cannot create references to/from string offsets nor overloaded objects in /var/www/drupal-7.27/includes/common.inc on line 6606, referer: http://myserver/mypath/summary?field_log_time_value%5Bvalue%5D%5Byear%5D...

and that URL results in a blank (white) screen.

I searched for this PHP error and saw a posting where someone said they upgraded their PHP and it fixed their problem. So I upgraded from 5.3.3 to 5.5.14 but the error and problem persist.

Please help!

(Note, I tried to search for the above title in the 7.27 core issues but got a blank page instead so please excuse this posting if it is duplicate or answered elsewhere. If it is answered elsewhere, I would appreciate a link to that page, thanks!)

Problem/Motivation

This is a side issue spun off from

https://www.drupal.org/node/2834982#comment-12074099

EntityForm::buildForm() has a overcomplicated and undeclared dependency on the renderer service.

Via a call to

 \Drupal::service('renderer')->addCacheableDependency($form, $this->entity);

the renderer service is being used incorrectly as a helperClass, as a pass through service, to access CacheableMetadata methods.

The same argument can be made for

RendererInterface::mergeBubbleableMetadata() it is just a helper class for BubbleableMetadata helper calls

Proposed resolution

1) Deprecate ( for removal in Drupal9 )

RendererInterface::mergeBubbleableMetadata()
RendererInterface::addCacheableDependency()

2) Create replacements RendererHelper::addCacheableDependencyToRenderArray() and RendererHelper::mergeBubbleableMetadata()

3) isolate tests, for Renderer tests. ( see RendererHelperTest )

4) Replace method calls in FieldPluginBase.php and EntityForm.php HtmlRenderer.php to calls of the new replacement methods.

Problem/Motivation

There are some related issues (I found these: #2893737: Move meta details element from NodeForm to ContentEntityForm, #2893740: Allow the seven sidebar for the node form to be used on other entity forms as well) that suggest that the entity_meta sidebar on the node add/edit form should be re-usable.

Proposed resolution

Provide a new render element 'Accordion list' that can replace nodeentity_meta and can be re-used elsewhere.

@todo

Remaining tasks

@todo

User interface changes

@todo
Expected: nothing.

API changes

New render element.

Data model changes

@todo

Release notes snippet

@todo

Problem/Motivation

Ran into a problem where migration_lookup was failing when the lookup was being done on a derivation of a configured migration.

id: d7_commerce_product_variation
  product_id:
    plugin: migration_lookup 
    migration: d7_commerce_product
    source: entity_id

d7_commerce_product has a deriver and after configuration, one of the derivations is 'd7_commerce_product_hats'. When I ran drush mim d7_commerce_product_variation_hats it was always failing because the migration_lookup shown above was failing. Debugged that and found that it was using the wrong name for the map table. Instead of migrate_map_d7_commerce_product_hats (the table name in the db) it was using migrate-map_d7_commerce_product__hats (extra underscore). I didn't investigate any further.

Just noting it here in case someone encounters something like this.

Proposed resolution

TBD

Remaining tasks

Reproduce the error

User interface changes

API changes

Data model changes

In Views on D7 there's an option to build a "jump menu". This appears to be gone in the version of Views bundled into D8. Was it renamed or moved to an external module?

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

Is there a way currently to "tell" Migrate what to stub as an entity label instead of randomly generating a string?

When running large migrations (from disparate sources, not just one-and-done Drupal x.x to 8), stubs can be created and often times have very long string titles (which break the layout of the content admin), and for editors of the system, don't make sense at a glance. Larger migrations may have quite a gap time between when a stub is created and when it gets filled in later.

To get around this for what I am working on, I had to create a destination plugin that extends EntityContentBase and tell it what to do for nodes:

 protected function processStubRow(Row $row) {
    parent::processStubRow($row);

    // Check the entity is Node/NodeInterface.
    $entity_type = $this->storage->getEntityTypeId();

    if ($entity_type === 'node') {
      $bundle_key = $this->getKey('bundle');
      $type = $row->getDestinationProperty($bundle_key);
      $content_type = $this->entityManager->getStorage('node_type')->load($type);
      $label = $content_type->label();
      $title = $label . '' . $row->getDestinationProperty('field_id') . ' (stub)';
      $row->setDestinationProperty('title', $title);
    }
  }

It would be great to be able to provide a pattern from the definition without needing to implement your own destination plugin (or perhaps I am not looking in the right place).

Problem/Motivation

In #2912353: Handle menu_items related to Drupal 6 and 7 node translations with different IDs we added a new configuration option validate_route to ignore route validation but there is no documentation in the plugin's annotation to document it.

Proposed resolution

Let's document this plugin.

Also, we should figure out and document (or fix) why the plugin expects an array and then only use the first item:

  public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property) {
    list($path) = $value;
    [...]
  }

Remaining tasks

• Write documentation
• Figure out why the plugin expects an array and only use the first item
• Review

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

\Drupal::entityManager() is deprecated, but still used in core.

Proposed resolution

Replace most usages with \Drupal::entityTypeManager() or the correct service.
We can likely script chunks of this, for example the pattern \Drupal::entityManager()->getStorage() can be globally changed to entityTypeManager. script what we can and manually manage the rest.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

There's an issue to support adding third party settings to sections: #2942661: Sections should have third-party settings, but it would be great to also support third party settings for individual components (blocks) within a section.

For example, modules like Block Class and Field Formatter Class use third party settings on block config entities to allow the user to add arbitrary CSS classes to a block. It seems that the only way to do this with a Layout Builder block is to modify the settings form for the individual block plugin you want to modify and store the configuration along with the other configuration for that block.