Problem/Motivation

When I display a custom block using the block layout configuration the block prints using the block.html.twig template however if I have a custom block view each row is just the rendered fields, not the whole rendered block.
This causes problems for themers and is inconsistent with similar row formats like "Show: Content" for nodes.

This also means that contextual links don't show for blocks in a view.

Steps to reproduce:

1. Create a custom block
2. Create a view showing custom blocks
3. For the view format select Show = Custom block

Proposed resolution

For this "Show: Content block" row type the row should be the rendered block, not just the fields.
If you want individual fields you would choose "Show: Fields" instead.

Problem/Motivation

The block system in Drupal 8 supports contexts, so that configurable arguments can be passed to blocks. This system is not connected to contextual filters in views. Views with block displays can be created but will not work.

Proposed resolution

Expose the contextual filters to the block context system, so that block module but also page_manager and everything that builds on that can pass values for those contextual filters. That is for example very powerful combined with static contexts or dynamic arguments in page manager.

The primary complexity is that block context uses typed data to define the contexts, but views does not have type system, it only knows about argument plugin ids and argument validation.

The code uses a combination of those to attempt to e.g. map argument validation plugins to the corresponding typed data types but it is not possible to support any argument configuration.

Remaining tasks

* Check non-required arguments with a default value.
* Test coverage for a non-entity example,
* Possibly a follow-up to make the mapping extensible, by letting argument (validation) plugins have a say in it?

User interface changes

Blocks that have required contextual filters will no longer be shown in the block UI if the necessary context does not exist. Currently those blocks are shown but then don't work.

API changes

Problem/Motivation

So this was a doozy to track down and debug.

While working on #2710989: Create a resolver API for picking a checkout flow, I discovered configuration entities which implement \Drupal\Core\Entity\EntityWithPluginCollectionInterface cannot be run in Kernel tests, due to the fact that their __sleep methods will invoke the Drupal static class to get the container.

In TestCaseMethod.tpl.dist the code for __phpunit_run_isolated_test calls serialize on the test results, number of assertsion, the result and output.

    print serialize(
      array('testResult'    => $test->getResult(),'numAssertions' => $test->getNumAssertions(),'result'        => $result,'output'        => $output
      )
    );

This was causing an error like the following (which left me scratching my head)

There was 1 error:

1) Drupal\Tests\commerce_checkout\Kernel\ChainCheckoutFlowResolverTest::testCheckoutFlowResolution
PHPUnit_Framework_Exception: PHP Fatal error:  Uncaught Drupal\Core\DependencyInjection\ContainerNotInitializedException: \Drupal::$container is not initialized yet. \Drupal::setContainer() must be called with a real container. in /Users/mglaman/Drupal/sites/commerce2x/web/core/lib/Drupal.php:130
Stack trace:
#0 /Users/mglaman/Drupal/sites/commerce2x/web/core/lib/Drupal.php(159): Drupal::getContainer()
#1 /Users/mglaman/Drupal/sites/commerce2x/web/modules/contrib/commerce/modules/checkout/src/Entity/CheckoutFlow.php(131): Drupal::service('plugin.manager....')
#2 /Users/mglaman/Drupal/sites/commerce2x/web/modules/contrib/commerce/modules/checkout/src/Entity/CheckoutFlow.php(117): Drupal\commerce_checkout\Entity\CheckoutFlow->getPluginCollection()
#3 /Users/mglaman/Drupal/sites/commerce2x/web/core/lib/Drupal/Core/Config/Entity/ConfigEntityBase.php(357): Drupal\commerce_checkout\Entity\CheckoutFlow->getPluginCollections()
#4 /Users/mglaman/Drupal/sites/commerce2x/web/modules/contrib/commerce/modules/checkout/src/Entity/CheckoutFlow.php(139): Drupal\Core\Conf in /Users/mglaman/Drupal/sites/commerce2x/web/core/lib/Drupal.php on line 130

So I threw an exception in the CheckoutFlow entity's __sleep method and got (stack trace json-ified in exception message)

There was 1 error:

1) Drupal\Tests\commerce_checkout\Kernel\ChainCheckoutFlowResolverTest::testCheckoutFlowResolution
PHPUnit_Framework_Exception: PHP Fatal error:  Uncaught Exception: [{"function":"__sleep","class":"Drupal\\commerce_checkout\\Entity\\CheckoutFlow","object":{},"type":"->","args":[]},{"file":"-","line":68,"function":"serialize","args":[{"testResult":null,"numAssertions":5,"result":{},"output":""}]},{"file":"-","line":1354,"function":"__phpunit_run_isolated_test","args":[]}] in /Users/mglaman/Drupal/sites/commerce2x/web/modules/contrib/commerce/modules/checkout/src/Entity/CheckoutFlow.php:139
Stack trace:
#0 [internal function]: Drupal\commerce_checkout\Entity\CheckoutFlow->__sleep()
#1 -(68): serialize(Array)
#2 -(1354): __phpunit_run_isolated_test()
#3 {main}
  thrown in /Users/mglaman/Drupal/sites/commerce2x/web/modules/contrib/commerce/modules/checkout/src/Entity/CheckoutFlow.php on line 139

The \Drupal\Core\Config\Entity\ConfigEntityBase::__sleep method invokes ::getPluginCollections which ends up touching \Drupal::service in some way or form. In core we have: FilterFormat, ImageStyle, RestResourceConfig, SearchPage, and Action. All of these will throw the same errors if run in a kernel test.

Proposed resolution

No idea.

Remaining tasks

• Investigate how to prevent ConfigEntity objects from being serialize at the end of a test method life cycle
• See how to mitigate needing \Drupal::service in these entity classes?

Problem/Motivation

While using the Book navigation block in "book page" mode, it would be nice to be able to override the block title by the book title.

Proposed resolution

Add a block setting to override block title by the book title.

Remaining tasks

User interface changes

A new setting is available on Book navigation block settings form.

API changes

None.

Data model changes

A new setting on block.settings.book_navigation

Problem/Motivation

When you create a file field, you can enable the description field for each file. This field description is supposed to override the file name on display.
It is working properly with the "Generic file" formatter but not with the "Table of files" formatter.

More than just fixing this bug (it was working in 7.x) we decided to add a setting on the concerned formatters to let the site builder choose if she wants the file name to be overriden by the description.

Proposed resolution

- pass the file description to the theme so it can be used instead of the file name
- add a setting to the "Generic file" formatter to use the description when available
- add a setting to the "Table of files" formatter to use the description when available
- add an upgrade path to disable the new settings for existing "Table of files" formatters (Backward Compatibility)
- increase test coverage to ensure these new settings are working

Remaining tasks

User interface changes

A new setting allows the site builder to define if she want the file name to be overriden by the description when it's available.
The file description is shown, when available and when the formatter allows it, instead of the file name when using the "Table of files" or "Generic files" formatter.

API changes

None.

Data model changes

A new setting on the file_table and file_default formatters.

Problem/Motivation

Drupal\locale\Tests\LocaleUpdateTest->testUpdateImportSourceRemote() at line 150 with assertion message "Updates for Contrib module one".

The test asserts using the wrong timestamp. If the timestamps timestampNow and timestampNew set in \Drupal\locale\Tests\LocaleUpdateBase::setUp() the assert will fail. To reproduce the fail change your system clock to whatever time it would be exactly midnight in UTC+10 (for me that was 14:00:00). This is because in WebTestBase::setup() we do...

    // Set an explicit time zone to not rely on the system one, which may vary
    // from setup to setup. The Australia/Sydney time zone is chosen so all
    // tests are run using an edge case scenario (UTC+10 and DST). This choice
    // is made to prevent time zone related regressions and reduce the
    // fragility of the testing system in general. This is also set in config in
    // \Drupal\simpletest\WebTestBase::initConfig().
    date_default_timezone_set('Australia/Sydney');

Proposed resolution

Use correct timestamp in assert.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Hey guys!

The situation: I have a multilingual Drupal 8 setup.
If I add a comment on a node which is in the default language, everything is okay.
But if I add a comment on a node which is not in the default language, I get redirected to the default language translation of my node.

I believe this is very confusing for the end user and they should stay in the same node language after submitting a comment.

This is very easy to replicate on simplytest.me (choose multilingual setup).

Thank you for looking into this!

Problem/Motivation

The tracker module currently depends on the comment module even if some of it's functions are not related to comments at all (eg. see if a node has been created/updated since our last visit). Sites that does not have comments or that's using another comment module than the core's one (eg. Disqus) cannot use the abilities of Tracker on nodes.

Proposed resolution

Remove comment module dependency and use a condition wherever it's needed to keep existing functionnalities active if the comment module is installed.

Remaining tasks

User interface changes

Comment module is no longer required to enable tracker module.

API changes

None.

Problem/Motivation

A D8 install can easily generate extremely lengthy file/directory names when caching Twig templates.

On some scenarios, the maximum length for a path might be limited by the OS:

• Windows has a maximum path length of 260 characters. Can read more here.
• If you are in Linux and have the filesystem where you have the site mounted using eCryptfs and its configured to encrypt filenames as well as the file content you will experience this same issue. You can read a little about this limitation here.

To reproduce this issue on Windows, add the following to settings.php.

$settings['file_public_path'] = 'sites/default/files/0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-0123456789-01'; // That's a 255-char dir name.

Proposed resolution

Update as of #144 going with option #3

Option #3: Trigger a requirement error on windows if the Drupal root is deeper than 100 characters. Use our existing base64 hash and hmac functions so the hashes are half as long to start. Truncate the human-readable template name portion and hash portion of the to a maximum length so the directory names can never be longer than 51 characters. The cache file name itself has already been shortened to 47 characters using the bas64 hmac in the split-off child issue #2830596: MTimeProtectedFastFileStorage::getFullPath() creates really long filenames unnecessarily

Update: as of #39, options #2 is the preferred solution.

Option #1: Use the Unicode path prefix (\\?\) on Windows to avoid the 260 character limit (pushes the limit to around 32k which is well above Linux's limit of 4k characters). Unfortunately, PHP's support of these pathnames is limited. (see #16) which would require a much more disruptive fix.

Option #2: Use shorter hashes while retaining the "uniqueness" of these directory and file names. However, the filename hash contains the filemtime() of the containing directory. If, for example, file uploads were compromised and malicious code added to a cached Twig template, the containing directory's filemtime would change and the hash would not match. Using shorter hashes could potentially increase the risk of a compromised file still passing the hash test. (Security review requested).

Also, option #2 does not solve the underlying problem, but hopefully gives us some breathing room. Currently, there are two 64-character hashes in each cached Twig template.

Remaining tasks

As of #12:

1. not needed since we're using option #2: FileStorage::unlink does not work with the Unicode prefix
2. Needs security review to ensure that shortened hashs still give enough "uniqueness" for MTimeProtectedFastFileStorage
3. Needs tests to assert that generated files do no exceed a (somewhat arbitrary) limit
4. Done: Add hook_requirements to warn users when installing Drupal on Windows with a long path name.

User interface changes

Adds a new warning when installing Drupal on Windows at a path > 100 characters.

API changes

With option #2, none.

Data model changes

None.

Problem/Motivation

If you have some safe strings and you want to safe_join them in a template and pass that as a @placeholder for translation, they get escaped even though they are safe. safe_join actually breaks the Markup object wrapper.

Why this should be an RC target

Without this patch any Markup instance passed to the |safe_join() Twig filter will be unintentionally escaped.

Disruptions: None, the intended result of this is to concatenate strings safely and return them joined by a separator and each item escaped if an item is not already a Markup instance.

Proposed resolution

Make the safe_join filter return a Markup object.

Remaining tasks

1. Patch
2. Tests
3. Review

User interface changes

Less things getting accidentally escaped.

API changes

safe_join will return a TwigMarkup/Markup object rather than a string.

Data model changes

None

Why this should be an RC target

Expectations of how safe_join works with MarkupInterface will be way off and this is not disruptive.

Problem/Motivation

logger.dblog is backend overrideable but it's pointless to override it because the module is littered with database queries.

Proposed resolution

Extend Psr\Log\LoggerInterface and add a method as necessary for every query.

Remaining tasks

Code it.

User interface changes

None.

API changes

It's all just additional. No code breaks.

Problem/Motivation

Currently, outside_in_contextual_links_view_alter() hardcodes a single contextual link as using offcanvas.
Any other links to be added will need the same logic.

Proposed resolution

Make it easier for contextual links to opt-in to being displayed in a dialog.
In #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it, make this available for all contextual links and all dialog/modal options.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Currently all the CSS in the Settings Tray module is in the drupal.outside_in library.

Presumably in #2784443: Move off-canvas functionality from Settings tray module into drupal.dialog.ajax library so that other modules can use it the off-canvas tray will need some of this CSS to look and behave correctly.

Proposed resolution

Move all needed CSS needed for the off-canvas tray to drupal.off_canvas.

Remaining tasks

Determine which CSS that is.
Also there is a lot of CSS to format form elements. Should that CSS be available to other modules that would like to put forms in the tray when Settings Tray is disabled?

If we do want to move the form CSS from Setting Tray should it be an option to use it in the tray or not. We could make loading the CSS for forms an option in data-dialog-options.

User interface changes

API changes

Data model changes

The drupal.outside_in library contains all the CSS in the module.

Right now the offcanvas tray displaces the "main canvas" which under a certain width look weird.

Should we really use displace() and try to show the main canvas when the tray is open at widths < 400 px?

The migrate_upgrade UI is now providing a confirmation page, showing the administrator performing the upgrade what modules are being upgraded from their legacy sites (and what modules are not). There is not currently an automated way to get this information - the closest thing is the source_provider annotation on the source plugin, but this doesn't help us with configuration-only migrations. My suggestion is adding a module key to the source plugin config for the Drupal migrations.

Problem/Motivation

On a D6 site with the upload module enabled, file attachments are considered enabled by default if the upload_[node_type] is not set. Ran into an issue with a custom D6 to D8 migration, where one content type had file attachments enabled on the D6 instance, but the upload field was missing after migration on the D8 site (two other content types with file attachments enabled did have the upload-field on D8 after migration.)

Relevant code snippet in D6's upload module:

function upload_form_alter(&$form, $form_state, $form_id) {
  if ($form_id == 'node_type_form'&& isset($form['identity']['type'])) {
    $form['workflow']['upload'] = array('#type' => 'radios','#title' => t('Attachments'),'#default_value' => variable_get('upload_'. $form['#node_type']->type, 1),'#options' => array(t('Disabled'), t('Enabled')),
    );
  }

  if (isset($form['type']) && isset($form['#node'])) {
    $node = $form['#node'];
    if ($form['type']['#value'] .'_node_form' == $form_id && variable_get("upload_$node->type", TRUE)) {
      // Attachments fieldset
      $form['attachments'] = array(
...

Proposed resolution

Since the "File attachments" field(set) is showing up on the original D6 site when the "upload_[type]" variable is not explicitly set, that content type should be considered as having file attachments enabled. Migrate the upload-field for all content types where it is either explicitly enabled, or where the variable is not set.

Remaining tasks

- Review
- Commit

User interface changes

None

API changes

None

Data model changes

None

Problem/Motivation

When using the option Exposed Grouped on a views filter, there is a limitation of 20 items to sort. This is because the delta of the form is set to 10.

Proposed resolution

Make the #delta value dynamic based on the amount of items of the grouped filter.

Remaining tasks

None

User interface changes

None

API changes

None

Data model changes

Original report by YoyoS

The delta should be increased when you need to order more than 20 fields, -10 -> 10 isn't enough.

I propose to have a delta of 30 for ordering 60 fields.

Problem/Motivation

From @tim.plunkett's review in #2281691: User interface for migration-based upgrades:

1. +++ b/core/modules/drupal_upgrade/src/Form/MigrateUpgradeForm.php
   @@ -0,0 +1,1196 @@
   +    else {
   +      $table_data = [];
   +      $system_data = [];
   +      foreach ($form_state->get('migration') as $migration) {

   This is a very large else block. Can this function be rewritten to avoid that, or broken into smaller methods?

2. +++ b/core/modules/drupal_upgrade/src/MigrateUpgradeRunBatch.php
   @@ -0,0 +1,358 @@
   +  public static function run($initial_ids, $operation, &$context) {

   This is another very large method that does a lot. Any way to break it up?

Proposed resolution

Refactor the code to reduce complexity.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

If the source ceases to have data , this is never reflected in the destination. There are two problems (at least), this patch attacks the field level in the content entity base, config entities and raw config entities are also broken but probably needs to be different issue and less severe because this only comes up in reruns, the migrate_drupal path does not really support reruns. And then there is the case when a whole row / entity disappears but that is an entirely different issue.

Proposed resolution

Unset outdated data.

Remaining tasks

Test this. Think it through.

User interface changes

API changes

Data model changes

Hello,

User warning: The following theme has moved within the file system: {THEME_NAME}. In order to fix this, clear caches or put the theme back in its original location. For more information, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1128 of {SITE_PATH}/includes/bootstrap.inc).

I have done all the steps mentioned in the Documentation for at least 10 times, but the error is still there.

Due to this, Not a single theme is active on my site, all themes I can see are disabled. So whenever this error occurs, I have to manually enable the respective theme.

Please let me know if you need further info.

Thanks