Problem/Motivation

When flushing the cache on a site recently upgraded to Drupal 8.5, I am now getting a fatal uncaught error:

 Rebuilding cache(s), wait a moment please.
PHP Fatal error:  Uncaught Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php:368
Stack trace:
#0 /app/docroot/core/modules/views/src/EventSubscriber/RouteSubscriber.php(120): Drupal\rest\Plugin\views\display\RestExport->collectRoutes(Object(Symfony\Component\Routing\RouteCollection))
#1 [internal function]: Drupal\views\EventSubscriber\RouteSubscriber->routes()
#2 /app/docroot/core/lib/Drupal/Core/Routing/RouteBuilder.php(146): call_user_func(Array)
#3 /app/docroot/core/lib/Drupal/Core/ProxyClass/Routing/RouteBuilder.php(83): Drupal\Core\Routing\RouteBuilder->rebuild()
#4 /app/docroot/core/includes/common.inc(1156): Drupal\Core\ProxyClass\Routing\RouteBuilder->rebuild()
#5 /app/vendor/drupal/console/src/Utils/DrupalApi.php(355): drupal_flush_all_caches()
#6 /app/vendor/drupal/console/src/Command/Cache/RebuildCommand.php(103): Drupal\Console\Utils\DrupalApi->drupal_rebuild(Object(Symfony\Component\ClassLoader\ApcCl in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 368

Fatal error: Uncaught Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 368

Error: Call to undefined method Drupal\views\Plugin\views\style\DefaultStyle::getFormats() in /app/docroot/core/modules/rest/src/Plugin/views/display/RestExport.php on line 368

API changes

Upgrade to Drupal 8.5

I'm trying to uninstall "Field Layout" but I'm having errors in my terminal :

www.s1biose.com@vps000000 ~/public_html $ drush pm-uninstall field_layout
 [error]  TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in {closure}() (line 34 of /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install) #0 [internal function]: {closure}(Object(Drupal\Core\Entity\Entity\EntityViewDisplay))
#1 /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install(37): array_map(Object(Closure), Array)
#2 [internal function]: field_layout_uninstall()
#3 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('field_layout_un...', Array)
#4 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(403): Drupal\Core\Extension\ModuleHandler->invoke('field_layout', 'uninstall')
#5 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(91): Drupal\Core\Extension\ModuleInstaller->uninstall(Array, true)
#6 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Drupal/Commands/pm/PmCommands.php(106): Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array, true)
#7 [internal function]: Drush\Drupal\Commands\pm\PmCommands->uninstall(Array, Array)
#8 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(235): call_user_func_array(Array, Array)
#9 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(181): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(150): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/annotationcommand_adapter.inc(242): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#12 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/command.inc(196): annotationcommand_adapter_process_command('field_layout')
#13 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Boot/BaseBoot.php(92): drush_dispatch(Array)
#14 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/preflight.inc(80): Drush\Boot\BaseBoot->bootstrapAndDispatch()
#15 phar:///usr/local/bin/drush/bin/drush.php(159): drush_main()
#16 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#17 {main}. 
TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install on line 34 #0 [internal function]: {closure}(Object(Drupal\Core\Entity\Entity\EntityViewDisplay))
#1 /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install(37): array_map(Object(Closure), Array)
#2 [internal function]: field_layout_uninstall()
#3 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php(391): call_user_func_array('field_layout_un...', Array)
#4 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/Extension/ModuleInstaller.php(403): Drupal\Core\Extension\ModuleHandler->invoke('field_layout', 'uninstall')
#5 /home/www.s1biose.com/public_html/web/core/lib/Drupal/Core/ProxyClass/Extension/ModuleInstaller.php(91): Drupal\Core\Extension\ModuleInstaller->uninstall(Array, true)
#6 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Drupal/Commands/pm/PmCommands.php(106): Drupal\Core\ProxyClass\Extension\ModuleInstaller->uninstall(Array, true)
#7 [internal function]: Drush\Drupal\Commands\pm\PmCommands->uninstall(Array, Array)
#8 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(235): call_user_func_array(Array, Array)
#9 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(181): Consolidation\AnnotatedCommand\CommandProcessor->runCommandCallback(Array, Object(Consolidation\AnnotatedCommand\CommandData))
#10 /home/www.s1biose.com/public_html/vendor/consolidation/annotated-command/src/CommandProcessor.php(150): Consolidation\AnnotatedCommand\CommandProcessor->validateRunAndAlter(Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#11 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/annotationcommand_adapter.inc(242): Consolidation\AnnotatedCommand\CommandProcessor->process(Object(Symfony\Component\Console\Output\ConsoleOutput), Array, Array, Object(Consolidation\AnnotatedCommand\CommandData))
#12 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/command.inc(196): annotationcommand_adapter_process_command('field_layout')
#13 /home/www.s1biose.com/public_html/vendor/drush/drush/src/Boot/BaseBoot.php(92): drush_dispatch(Array)
#14 /home/www.s1biose.com/public_html/vendor/drush/drush/includes/preflight.inc(80): Drush\Boot\BaseBoot->bootstrapAndDispatch()
#15 phar:///usr/local/bin/drush/bin/drush.php(159): drush_main()
#16 /usr/local/bin/drush(10): require('phar:///usr/loc...')
#17 {main}
TypeError: Argument 1 passed to {closure}() must implement interface Drupal\field_layout\Display\EntityDisplayWithLayoutInterface, instance of Drupal\Core\Entity\Entity\EntityViewDisplay given in {closure}() (line 34 of /home/www.s1biose.com/public_html/web/core/modules/field_layout/field_layout.install).
 [error]  Drush command terminated abnormally due to an unrecoverable error. 

Problem/Motivation

Tested a large Drupal 8 project on 8.5.0-alpha1 today and started getting test fails for views that had rest exports powered by CSV serialization
The views have URLs like /some/path/to/download/content.csv
They work if I change the URLs to /some/path/to/download/content.csv?_format=csv

Proposed resolution

Is this an issue in CSV serialization or a regression in core?

Remaining tasks

User interface changes

API changes

Data model changes

How to reproduce:
Drupal 8.5 with 1 language: FR
Another language (EN) is added after many pages are created
French is the default language
In "Detection and selection""User" is selected, then "Selected language" [default language=FR]

When viewing a page, I expect to see it in french, but it is english wich is displayed.
Looking at my User profile, French is set...

The only way to solve this bug is to re-save my profile (without any change)

I think that this is because, when a language is added (EN) the existing profile doesn't have the previous language encoded...
Thus when a language is added we could have an opportunity to set the "old" language to all existing profile.

After Drupal core update from 8.4.5 to 8.5.0 block visibility setting tab for "Content types" is not showing anymore. Perhaps this is similar to https://www.drupal.org/project/drupal/issues/2952962"Block visibility setting tab for Roles not showing"?

Note: I also had issue https://www.drupal.org/project/drupal/issues/2951242"block_content_update_8400 fails" which I fixed with https://www.drupal.org/project/drupal/issues/2951242#comment-12523500 (comment #25) before attempting the Drupal 8.5.0 update.

The system was installed about one year ago based on Drupal 8.3.1, received every single update along the way, and has 5 languages configured.

To troubleshoot I uninstalled all custom modules and then some more, and also disabled many Views, all to no avail.

Tried a hack with same method as https://www.drupal.org/files/issues/2018-03-20/block_roles_visibility_ba... replacing 'user_role' with 'node_type'. That brought back the setting tab for content types, although now listed below the roles tab. However, when applying a content type setting, the block does not show anymore at all for any content type.

It seems blocks with visibility setting on content types created while still on Drupal core 8.4.5 do work after 8.5.0 update. However, I cannot change the block visibility anymore for content type.

Comparing the blobs in field data of table config for above changed block I see the dysfunctional version of the block is missing "a:1:{s:4:"node";s:29:"@node.node_route_context:node";}", but that may all be due to the crude hack I tried in BlockForm.php as mentioned above.

No errors in dblog and the webserver error log.

Edit: Here's the link to the original Composer issue report: https://github.com/composer/composer/issues/7203

Running composer update --dry-run is a very helpful tool for seeing how dependencies will resolve before actually running the update. But it doesn't work properly for project drupal/drupal. Its output doesn't match composer update, rendering it ineffective.

To reproduce the problem: Extract drupal-8.5.0.tar.gz, then run composer install and additional packages will be installed, ones listed under require-dev that weren't included in the tarball. Next, run composer update and all packages (including dev) will be up to date. Here's where it gets weird. Run composer update --dry-run and you get this:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 34 removals
  - Uninstalling symfony/phpunit-bridge (v3.4.6)
  - Uninstalling symfony/dom-crawler (v3.4.6)
  - Uninstalling symfony/css-selector (v3.4.6)
  - Uninstalling symfony/browser-kit (v3.4.6)
  - Uninstalling squizlabs/php_codesniffer (2.9.1)
  - Uninstalling sebastian/version (1.0.6)
  - Uninstalling sebastian/recursion-context (1.0.5)
  - Uninstalling sebastian/global-state (1.1.1)
  - Uninstalling sebastian/exporter (1.2.2)
  - Uninstalling sebastian/environment (1.3.8)
  - Uninstalling sebastian/diff (1.4.3)
  - Uninstalling sebastian/comparator (1.2.4)
  - Uninstalling phpunit/phpunit-mock-objects (2.3.8)
  - Uninstalling phpunit/phpunit (4.8.36)
  - Uninstalling phpunit/php-token-stream (1.4.12)
  - Uninstalling phpunit/php-timer (1.0.9)
  - Uninstalling phpunit/php-text-template (1.2.1)
  - Uninstalling phpunit/php-file-iterator (1.4.5)
  - Uninstalling phpunit/php-code-coverage (2.2.4)
  - Uninstalling phpspec/prophecy (1.7.5)
  - Uninstalling phpdocumentor/type-resolver (0.3.0)
  - Uninstalling phpdocumentor/reflection-docblock (3.2.2)
  - Uninstalling phpdocumentor/reflection-common (1.0.1)
  - Uninstalling mikey179/vfsStream (v1.6.5)
  - Uninstalling jcalderonzumba/mink-phantomjs-driver (v0.3.3)
  - Uninstalling jcalderonzumba/gastonjs (v1.2.0)
  - Uninstalling instaclick/php-webdriver (1.4.5)
  - Uninstalling fabpot/goutte (v3.2.2)
  - Uninstalling drupal/coder (8.2.12)
  - Uninstalling doctrine/instantiator (1.0.5)
  - Uninstalling behat/mink-selenium2-driver (dev-master 93474c6)
  - Uninstalling behat/mink-goutte-driver (v1.2.1)
  - Uninstalling behat/mink-browserkit-driver (v1.3.2)
  - Uninstalling behat/mink (dev-master 04ab7af)

It seems to want to uninstall a bunch of dev packages, many of which it just installed. But when you actually run composer update without the --dry-run tag, you get:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
> Drupal\Core\Composer\Composer::ensureHtaccess

I brought this to the Composer developers, thinking there may be a composer bug that causes --dry-run to have a different output than a real update. But it appears the issue is with a Drupal script. Running composer update --no-scripts gives you this:

Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 0 installs, 0 updates, 35 removals
  - Removing webmozart/assert (1.3.0)
  - Removing symfony/phpunit-bridge (v3.4.6)
  - Removing symfony/dom-crawler (v3.4.6)
  - Removing symfony/css-selector (v3.4.6)
  - Removing symfony/browser-kit (v3.4.6)
  - Removing squizlabs/php_codesniffer (2.9.1)
  - Removing sebastian/version (1.0.6)
  - Removing sebastian/recursion-context (1.0.5)
  - Removing sebastian/global-state (1.1.1)
  - Removing sebastian/exporter (1.2.2)
  - Removing sebastian/environment (1.3.8)
  - Removing sebastian/diff (1.4.3)
  - Removing sebastian/comparator (1.2.4)
  - Removing phpunit/phpunit-mock-objects (2.3.8)
  - Removing phpunit/phpunit (4.8.36)
  - Removing phpunit/php-token-stream (1.4.12)
  - Removing phpunit/php-timer (1.0.9)
  - Removing phpunit/php-text-template (1.2.1)
  - Removing phpunit/php-file-iterator (1.4.5)
  - Removing phpunit/php-code-coverage (2.2.4)
  - Removing phpspec/prophecy (1.7.5)
  - Removing phpdocumentor/type-resolver (0.3.0)
  - Removing phpdocumentor/reflection-docblock (3.2.2)
  - Removing phpdocumentor/reflection-common (1.0.1)
  - Removing mikey179/vfsstream (v1.6.5)
  - Removing jcalderonzumba/mink-phantomjs-driver (v0.3.3)
  - Removing jcalderonzumba/gastonjs (v1.2.0)
  - Removing instaclick/php-webdriver (1.4.5)
  - Removing fabpot/goutte (v3.2.2)
  - Removing drupal/coder (8.2.12)
    The package has modified files:
    D coder_sniffer/Drupal/Test/Array/ArrayUnitTest.inc
    D coder_sniffer/Drupal/Test/Array/ArrayUnitTest.inc.fixed
    D coder_sniffer/Drupal/Test/Array/ArrayUnitTest.php
    D coder_sniffer/Drupal/Test/Array/DisallowLongArraySyntaxUnitTest.php
    D coder_sniffer/Drupal/Test/Array/disallow_long_array_d7/DisallowLongArraySyntaxUnitTest.1.inc
    D coder_sniffer/Drupal/Test/Array/disallow_long_array_d7/disallow_long_array_d7.info
    D coder_sniffer/Drupal/Test/Array/disallow_long_array_d8/DisallowLongArraySyntaxUnitTest.2.inc
    D coder_sniffer/Drupal/Test/Array/disallow_long_array_d8/DisallowLongArraySyntaxUnitTest.2.inc.fixed
    D coder_sniffer/Drupal/Test/Array/disallow_long_array_d8/disallow_long_array_d8.info.yml
    D coder_sniffer/Drupal/Test/Classes/ClassCreateInstanceUnitTest.inc
    237 more files modified, choose "v" to view the full list
    Discard changes [y,n,v,d,?]? y
  - Removing doctrine/instantiator (1.0.5)
  - Removing behat/mink-selenium2-driver (dev-master 93474c6)
  - Removing behat/mink-goutte-driver (v1.2.1)
  - Removing behat/mink-browserkit-driver (v1.3.2)
  - Removing behat/mink (dev-master 04ab7af)
Writing lock file
Generating autoload files

This may work as designed, but the inability to use --dry-run is certainly a hamper on assessing module versions and dependencies with our web developer and his clients. I appreciate any and all help in solving this!

Problem/Motivation

While looking at Migration::findMigrationDependencies, I saw that migration dependencies are supposed to be automatically set when using the now deprecated 'migration' process plugin. This method has not been updated for the new 'migration_lookup' process plugin.

  /** 
   * Find migration dependencies from the migration and the iterator plugins.
   *
   * @param $process
   * @return array
   */
  protected function findMigrationDependencies($process) {
    $return = []; 
    foreach ($this->getProcessNormalized($process) as $process_pipeline) {
      foreach ($process_pipeline as $plugin_configuration) {
        if ($plugin_configuration['plugin'] == 'migration') {
          $return = array_merge($return, (array) $plugin_configuration['migration']);
        }
        if ($plugin_configuration['plugin'] == 'sub_process') {
          $return = array_merge($return, $this->findMigrationDependencies($plugin_configuration['process']));
        }
      }   
    }   
    return $return;
  }

Also, we should still support the deprecated iterator process plugin.

Proposed resolution

Add a check for the 'migration_lookup'& iterator process plugins so their dependencies are set correctly.

Remaining tasks

• Add a failing test
• Fix it
• Review

User interface changes

None.

API changes

None.

Data model changes

None.

Hello. I don't know if this the right place to create this issue, but I solved it by modifying this specific file (EntityViewBuilder.php).

Problem

When using EntityViewBuilder to display an entity reference field, the output does not respect the current language.

How to reproduce

1. Create a new Drupal 8 installation
2. Add a user entity reference field to content type basic page
3. Add a second language. Enable translation for User and Basic Page
4. Enable tranlation for the entity reference field created in step 2
5. In Basic Page manage display, select rendered entity for the entity reference field
6. Add a text field to User, e.g. field_surname
7. Translate user 1
8. Create a basic page with a reference to user 1 and translate this page
9. Visit the basic page. The rendered user will be in the correct language.
10. Now install Fieldblock. You will also need to install this patch. I choose this example because Fieldblock uses EntityViewBuilder.
    • Fieldblock.php line 342 calls FieldItemList::view()
    • FieldItemList.php line 255 calls EntityViewBuilder::viewField()
11. Go to Manage Blocks and add a Fieldblock for the field of step 2. Once again, choose rendered entity display mode.
12. Again, visit the translated basic page. The rendered user in the block will be in the original language, untranslated.

Suggested resolution

I don't know if this is a general correct solution. In my case, I solved the issue by modifying EntityViewBuilder::viewField() (line 397 of EntityViewBuilder.php) from this:

  public function viewField(FieldItemListInterface $items, $display_options = []) {
    $entity = $items->getEntity();
    $field_name = $items->getFieldDefinition()->getName();
    $display = $this->getSingleFieldDisplay($entity, $field_name, $display_options);

    $output = [];
    $build = $display->build($entity);
    if (isset($build[$field_name])) {
      $output = $build[$field_name];
    }

    return $output;
  }

to this:

  public function viewField(FieldItemListInterface $items, $display_options = []) {
    $entity = $items->getEntity();
    if ($entity instanceof TranslatableInterface && $entity->isTranslatable()) {
      $entity = \Drupal::service('entity.repository')->getTranslationFromContext($entity);
    }
    $field_name = $items->getFieldDefinition()->getName();
    $display = $this->getSingleFieldDisplay($entity, $field_name, $display_options);

    $output = [];
    $build = $display->build($entity);
    if (isset($build[$field_name])) {
      $output = $build[$field_name];
    }

    return $output;
  }

I will also create a patch and post it here.
Any comments welcome, thanks in advance.

Problem/Motivation

There is ENTITY_TYPE_list cache tag and it is being invalidated very often. For example if we have 20 different content types and created views page to display list of content for each type, then whenever editor add/edit/delete one of the content - all 20 views pages will be invalidated BUT only related should be invalidated, others still have no changes. So, it means that on current sites if somebody change something then Drupal will clear cache for almost entire website.

Proposed resolution

Add bundle specific cache tags - ENTITY_TYPE_list:BUNDLE

Remaining tasks

• add cache tag
• make sure that views and other modules will use it whenever it possible
• make sure that it is the best solution :)

Original report by [effulgentsia]

Follow up from #1712456: How to leverage cache tags in Views.

Two problems:

1. That issue changed EntityViewBuilder::resetCache() from just clearing the TYPE:ID tag to also clearing the TYPE_view_BUNDLE tag. However, what is the meaning of this tag? What does it mean to "view" a bundle? #1712456-50: How to leverage cache tags in Views says "Say you save settings for one node type, it would invalidate caches for every node on the system?!", so ok, if the intent of this tag is to clear caches upon a change to the settings of a bundle, then why is it being cleared upon the saving of a single entity, which is when EntityViewBuilder::resetCache() is called? OTOH, the same comment also says We need a way like this to invalidate 'lists' containing this entity type. This and 'view' could be similar though I guess.. Hm, if the 'view' here refers to lists (where Views module is the most common list generator) rather than to the 'view' in the sense of EntityViewBuilder, then let's rename this tag to 'list' instead. If we then also want a per-bundle 'view' tag for clearing when bundle settings change in a way that would affect their display, then that's what we should use 'view_BUNDLE' for, but then clear it only where bundle settings are managed (e.g., EntityDisplay) rather than in EntityViewBuilder::resetCache().
2. If we do rename this to TYPE_list_BUNDLE, then how should we handle Views that are cross-bundle? For example, currently in HEAD, if I enable tag-based caching on the front page View, then visit the front page at a time when only Article nodes are promoted to the front page, then I add a Page node and promote it, it doesn't show up on my front page until I manually clear caches. Perhaps we need a non-bundle-specific TYPE_list tag as well, and add that to all cross-bundle Views, but not to Views and EFQ listings that we know are bundle-specific?

Problem/Motivation

https://tools.ietf.org/html/rfc7231#section-6.5.6 says

6.5.6.  406 Not Acceptable

   The 406 (Not Acceptable) status code indicates that the target
   resource does not have a current representation that would be
   acceptable to the user agent, according to the proactive negotiation
   header fields received in the request (Section 5.3), and the server
   is unwilling to supply a default representation.

   The server SHOULD generate a payload containing a list of available
   representation characteristics and corresponding resource identifiers
   from which the user or user agent can choose the one most
   appropriate.  A user agent MAY automatically select the most
   appropriate choice from that list.  However, this specification does
   not define any standard for such automatic selection, as described in
   Section 6.4.1.

… i.e. there's no standardized way to communicate the list of acceptable formats. Also see https://httpstatuses.com/300. See https://github.com/Respect/Rest/issues/39 for an example discussion of a project attempting to implement this … and getting sucked into an endless discussion. That being said, I think we should do something until it's standardized.

Proposed resolution

Update \Drupal\Core\Routing\RequestFormatRouteFilter

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

None.

Problem/Motivation

It's more useful to show the user what they are typing instead of asking them to type it twice:
http://www.lukew.com/ff/entry.asp?1653= (2012)
http://www.lukew.com/ff/entry.asp?1941 (2015)

Proposed resolution

Add a password field with show/hide functionality and make it an option to use this instead of the password_confirm field
Image may be NSFW.
Clik here to view.

Remaining tasks

1. Agree the usability reasons are the correct course of action
2. Write a patch
3. Rewrite all the tests

User interface changes

The password confirmation field can be removed and replaced with a show/hide link

API changes

1. Programmatic password submits for user create/update now require one value instead of 'pass1' and 'pass2' depending on config

Beta phase evaluation

After upgrading Drupal from 8.4.4 to 8.5.0, the Roles tab in the block visibility configuration is not available (see screenshot).
I have different user roles using different navigation menus based on this, so the issue is critical for me.

URL: /admin/structure/block/block-content

PHP 7.2.0alpha2

The website encountered an unexpected error. Please try again later.

Twig_Error_Syntax: The text to be translated with "trans" can only contain references to simple variables in Twig_Extensions_TokenParser_Trans->checkTransString() (line 26 of core/themes/classy/templates/views/views-mini-pager.html.twig).
Twig_Extensions_TokenParser_Trans->parse(Object) (Line: 190)
Twig_Parser->subparse(Array) (Line: 36)
Twig_TokenParser_If->parse(Object) (Line: 190)
Twig_Parser->subparse(Array) (Line: 36)
Twig_TokenParser_If->parse(Object) (Line: 190)
Twig_Parser->subparse(NULL, ) (Line: 103)
Twig_Parser->parse(Object) (Line: 692)
Twig_Environment->parse(Object) (Line: 750)
Twig_Environment->compileSource(Object) (Line: 447)
Twig_Environment->loadTemplate('core/themes/classy/templates/views/views-mini-pager.html.twig') (Line: 64)
twig_render_template('core/themes/classy/templates/views/views-mini-pager.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('views_mini_pager', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array) (Line: 490)
Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 136)
__TwigTemplate_0b39505df84b691c5a3640573ee0790767231d2654971965753660bef51abd95->doDisplay(Array, Array) (Line: 432)
Twig_Template->displayWithErrorHandling(Array, Array) (Line: 403)
Twig_Template->display(Array) (Line: 411)
Twig_Template->render(Array) (Line: 64)
twig_render_template('core/themes/classy/templates/views/views-view.html.twig', Array) (Line: 384)
Drupal\Core\Theme\ThemeManager->render('views_view', Array) (Line: 435)
Drupal\Core\Render\Renderer->doRender(Array) (Line: 448)
Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 195)
Drupal\Core\Render\Renderer->render(Array, ) (Line: 226)
Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 574)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 227)
Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 117)
Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.view', Object) (Line: 149)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

Twig code:

<li class="pager__item is-active">
          {% trans %}
            Page {{ items.current }}
          {% endtrans %}
        </li>

Problem/Motivation

On drupal 8.5 attempting to run a drush cim - all configuration loads but fails at the Finalizing configuration synchronization step. This includes failures on views related to core modules:

Unexpected error during import with operation create for views.view.watchdog: No entity type for field name_1 on view ve
Unexpected error during import with operation create for views.view.who_s_new: No entity type for field name_1 on view ve
Unexpected error during import with operation create for views.view.who_s_online: No entity type for field name_1 on view ve

API changes

Unknown

I use update.php to upgrade.

But issue happened:

1. /update.php > Work
2. /update.php/selection > Not found

Problem/Motivation

Currently, there is no way for modules to respond to a Drupal site being installed. Modules can implement hook_modules_installed to check if a profile has been installed, but there are many site install tasks that happen after that - specifically optional configuration is installed and the default theme is changed. It would be nice if there was a more explicit hook that ran as the last site install task, so that modules could execute code at the very end of the install process.

Possible implementations of this hook:

1. Enable an optional module feature if a specific profile is installed.
2. Show a status message to the user once the install is finished.
3. Act on optional config installed at the end of the profile installation process (see install_install_profile). This is really hard to do without this hook.

Proposed resolution

Add a new hook, hook_site_install_finished(), which allows modules to respond to a Drupal site install. Modules are also provided the $install_state, which has useful contextual data about the install like the profile and whether or not the install was interactive.

Remaining tasks

Review the patch.

User interface changes

None.

API changes

Adds a new hook, hook_site_install_finished, which is is documented in module.api.php.

Data model changes

None.

Part of #2571965: [meta] Fix coding standards in core.

Approach

We are testing coding standards with PHP CodeSniffer, using the Drupal coding standards from the Coder module. Both of these packages are not installed in Drupal core. We need to do a couple of steps in order to download and configure them so we can run a coding standards check.

Step 1: Add the coding standard to the whitelist

Every coding standard is identified by a "sniff". For example, an imaginary coding standard that would require all llamas to be placed inside a square bracket fence would be called the "Drupal.AnimalControlStructure.BracketedFence sniff". There are dozens of such coding standards, and to make the work easier we have started by only whitelisting the sniffs that pass. For the moment all coding standards that are not yet fixed are simply skipped during the test.

Open the file core/phpcs.xml.dist and add a line for the sniff of this ticket. The sniff name is in the issue title. Make sure your patch will include the addition of this line.

Step 2: Run the test

Now you are ready to run the test! From within the core/ folder, run the following command to launch the test:

$ composer run phpcs -- -p

This takes a couple of minutes. The -p flag shows the progress, so you have a bunch of nice dots to look at while it is running.

Step 3: Fix the failures

When the test is complete it will present you a list of all the files that contain violations of your sniff, and the line numbers where the violations occur. You could fix all of these manually, but thankfully phpcbf can fix many of them. You can call phpcbf like this:

$ composer run phpcbf

This will fix the errors in place or composer will tell you that Script phpcbf --standard=core/phpcs.xml.dist --runtime-set installed_paths $($COMPOSER_BINARY config vendor-dir)/drupal/coder/coder_sniffer -- handling the phpcbf event returned with error code 1 meaning there was no files fixed and you need to fix them manually. You can then make a diff of the changes using git. You can also re-run the test with phpcs and determine if that fixed all of them.

Problem/Motivation

The make_unique_entity_field does not check if the entity is already migrated and needs to be updated; as a result, the MakeUniqueEntityField::exists() returns TRUE if existing entity is the same as one which is being migrated.

For instance, using make_unique_entity_field process for username results in user being renamed to 'name_1' and 'name' back and forwards.

Steps to reproduce:

1. Put attached users_test.yml somewhere in your Drupal migrations.
2. Install migrate_tools module (to run migration easy).
3. Run 'drush mim users_test'. You'll get a single user named 'test'.
4. Run 'drush mim --update users_test'. The user will be renamed to 'test_1'.
5. Run 'drush mim --update users_test' once again. The user will be renamed back to 'test' since there's no entity with such value anymore.
6. Repeat. The user will keep renaming back and forward.

Proposed resolution

The \Drupal\migrate\Plugin\migrate\process\MakeUniqueBase::transform() method should check if the destination already exists (i.e. the update operation is running); in this case, it should skip transform to ensure data consistency.

Problem/Motivation

#2808233: REST 403 responses don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out introduced the infrastructure to be able to surface the reason for why access is not being allowed. Over there, we used that to provide meaningful, actionable 403 responses when entity access is denied. But … we never did the same for field access!

(I noticed this while working on JSON API test coverage. See #2930028: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only.)

Proposed resolution

When generating a 403 response due to field access not being allowed, check if the access result object contains a reason, and expose it in the error response.

Remaining tasks

Implement!

User interface changes

None.

API changes

None.

Data model changes