Problem/Motivation

Currently layout_builder is very limited when it comes to more complex layouts. The issue is lack of nesting or wrapping ability. See:

• #3053145: Allow layout builder sections to be nested.
• #2960384: Allow Concept of Section Wrappers

I believe that all use cases bringing people towards these issues could be solved if we would simply allow people to create layouts with configurable regions. These could be a "second class citizens", yet would allow devs or contrib modules to develop custom complex rules of layout building, and store them in layouts configurations.

Proposed resolution

The simplest way of supporting this would be to add a new method to the Drupal\Core\Layout\LayoutInterface: getDynamicRegions. Other parts of the system could decide themselves if they want to support dynamic layout regions or not, as this information is not always available, but where it is available, it is very useful.

Remaining tasks

• Patch review
• Discuss and agree on the solution

API changes

Drupal\Core\Layout\LayoutInterface modified with additional method. It would be implemented by default in the Drupal\Core\Layout\LayoutDefault though.

Problem/Motivation

See #3042745: Remove group @legacy from jsonapi tests and fix deprecation messages and [#32450793], I don't fully understand yet how this all works together but I assume by overwriting the user name *field* with the label/display name can result in overwriting the actual username if that data is saved back.

I'll see if I can create a failing test to show the problem.

Proposed resolution

Not sure, but maybe the display name could be exposed as a separate thing that is explicitly read-only?

Would need to be BC somehow, of course unless we define that the current behavior is simply a bug that must be fixed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

After the completion of the new Extension system API's in #2208429: Extension System, Part III: ExtensionList, ModuleExtensionList and ProfileExtensionList and #2659940: Extension System, Part III: ThemeExtensionList and ThemeEngineExtensionList, drupal_get_path() has been replaced with the theme, module and profile extension listing services. This issue will deprecate the usage of drupal_get_path() in core and replace with the relevant extension listing service calls (Module|Profile|Theme)ExtensionList::getPath().

Proposed resolution

Replace all dynamic uses drupal_get_path() with (Module|Profile|Theme)ExtensionList::getPath(). The earlier issue #2351919: Replace uses of drupal_get_path() with __DIR__ where possible had taken care of static includes where relative location of the files were fixed.

Remaining tasks

Reviews
Commit

User interface changes

None

API changes

drupal_get_path() is deprecated.

Problem/Motivation

While working toward #2982680: Add composer-ready project templates to Drupal core., we discovered that the Vendor Hardening Plugin sometimes fails to work, throwing an error:

Fatal error: Uncaught Error: Class 'Drupal\Component\FileSecurity\FileSecurity' not found in phar:///Users/ganderson/bin/composer/src/Composer/Plugin/PluginManager.php(196) : eval()'d code:245

The problem is that the drupal/core-file-security component is only available as a replaced component in drupal/core; it is not recognized as a standalone Composer package during the autoload dump phase.

Proposed resolution

Removing drupal/core-file-security from the replace section of drupal/core's composer.json file clears up this problem. We can instead add it as a "path' repository, so that it will be discovered and used when doing core Drupal development on the drupal/drupal project.

Remaining tasks

Under this configuration, Composer-managed Drupal sites build on drupal/core rather than drupal/drupal (like tarball releases) will have two copies of drupal/core-file-security: one in the core directory, and one in vendor/drupal/core-file-security. The copy in vendor is the one that will be used.

To avoid confusion, we could relocate the drupal/core-file-security component out of the core directory, and put it somewhere else. Perhaps the path composer/Component would work (next to the existing composer/Plugin path, which exists for a similar reason).

Follow-on Tasks

• #3076600: Create drupal/core-recommended metapackage
• #2982680: Add composer-ready project templates to Drupal core.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Convert drupal/core-file-security from 'replace' to 'require' so that it will work correctly when required from a Composer plugin.

API page: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Date...

See for instance https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Component%21Date.... The '@see __construct()' is not forming a link.

When I create a link via the core WYSIWYG, I see an advanced menu where I can set custom class, ID, and Rel values. There should also be an option for aria-label so that we can satisfy WCAG 2.4.4 and 2.4.9 (when we have two links with the same link text, we must distinguish them by unique aria-label values).

The ChromeDriver used by the test bot does not support HTML5 Drag and Drop.
https://github.com/SeleniumHQ/selenium/issues/3269#issuecomment-406378953

Because of this the automated tests in layout_builder were failing when the jquery.ui.sortable library was replaced with a more modern alternative #3064049: Switch core dependencies of jquery.ui.sortable to a replacement implementation.

The dragTo method in vendor/behat/mink-selenium2-driver/src/Selenium2Driver.php fires custom javascript events and simulates a mouse drag, however this did not work with the Sortable.js replacement in testLayoutBuilderUi or testContentPreviewToggle

To work around this, some new methods for "simulating" a drag event were added in core/tests/Drupal/FunctionalJavascriptTests/SortableTestTrait.php and the layout builder callback implemented in core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderSortTrait.php.

When/if the ChromeDriver is updated to support HTML5 Drag and Drop events these traits should be deprecated and the two layout_builder tests should be reverted to using the dragTo method.

• https://bugs.chromium.org/p/chromium/issues/detail?id=850071
• https://bugs.chromium.org/p/chromedriver/issues/detail?id=2695

Problem/Motivation

We should add a dedicated field storage definition class which allows modules to define field storage definitions in hook_entity_field_storage_info() without having a config-field easily.

Proposed resolution

Add a FieldStorageDefinition class that implements FieldStorageDefinitionInterface.

Remaining tasks

Patch.

User interface changes

None.

API changes

Additional builder class for storage definitions.

Data model changes

None.

Out of scope

Any changes to BaseFieldDefinition, @see #3014760: [PP-1] Create an abstract composite field definition/storage definition and update BaseFieldDefinition to use it.

I have encountered an issue on multiple occasions since starting to build sites in D8 18 months ago. I can't find a matching issue in the Views queue that covers this, although have seen a couple of issues elsewhere that are possibly related/the same.

However, I've finally figured out how to reproduce it. I'm running Drupal 8.5.5.

The issue causes a View in development to become un-editable. The only workaround that I can find is to return to the main Views page and duplicate the view. This will give you a copy of the last saved version of the view, and you will lose any changes made since saving the view.

Steps to reproduce this:

1. Create two content types (e.g. Testimonial and Services)
2. Add an entity reference field to the Testimonial content type that references the Services content type.
3. Create a view
4. Add a block to the view
5. Add fields from the Testimonial content type
6. Add a Filter for the Testimonial content type, Content: Content type (= Testimonial)
7. Add a Relationship to Services via the entity reference, Content referenced from field_related_services
8. Edit the content type filter and specify the relationship you just created.
9. Click the Relationship, then click Remove.

At this point, the Relationship box will flicker but will not disappear. You can close the box with the X, but if you refresh the screen, it will return the ever-helpful error:

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

If you review the server log, you'll see something like this:

[Mon Jul 30 13:01:57.185616 2018] [:error] [pid 364:tid 140679086855936] [client 192.168.1.24.202:53768] Uncaught PHP Exception Exception: "No entity type for field type on view testimonials" at /var/www/html/drupal/web/core/modules/views/src/Plugin/views/HandlerBase.php line 711, referer: http://site.com/admin/structure/views

Using multiple moderation states forms (list of nodes with moderation state display on a view), when i change the moderation state of any node always update the state of the first node.

I debug the EntityModerationForm on buildForm and and submitForm on $form_state->get('entity'); always get the first entity.

It seems related to:
https://www.drupal.org/project/drupal/issues/2821852

Problem/Motivation

In #3036210: Add justinrainbow/json-schema as a composer dependency so JSON:API can use it to validate its responses, we noticed that phpunit-mock-objects (or at least our current version of it) is being marked as "abandoned" when composer.lock is rebuilt for an unrelated dependency addition.

This is likely due to us using an old version of PHPUnit which has old dependencies.

Proposed resolution

?

Per @larowlan, this probably won't actually break anything, but will probably result in Composer warnings and such that will concern users and lead to bug reports.

The version of phpunit-mock-objects that we use currently is impressively out of date -- 2.3.8, when the current release is 5.0.10. The latest version requires PHP 7.1 (as do the supported versions of PHPUnit itself), but we need to maintain compatibility with PHP 7.0 until #2917655: [policy] Decide on PHP 7.x support status is finalized. We also use PHPUnit 4 for testing PHP 5.5 and 5.6, which will be tested once per day on Drupal 8.7.x and 8.6.x following 8.7.0 as per the plan outlined in #2842431: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7.

Remaining tasks

TBD

User interface changes

N/A

API changes

TBD

Data model changes

N/A

Release notes snippet

TBD

Problem/Motivation

Text editor select drop down has ajax error due to new DrupalMediaLibrary button's getConfig() code.

Proposed resolution

The getConfig() method should return an empty array in the context of this form, or basically if the prerequisites for the MediaLibraryState are missing.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Hi,

Our site is getting the below warning. PHP display startup errors were switched on couple of days ago, so not too sure if this was coming up before that.

Warning: stream_wrapper_register(): class '\TYPO3\PharStreamWrapper\PharStreamWrapper' is undefined in file_register_phar_wrapper() (line 40 of C:\intetpub\wwwroot\mysite\includes\file.phar.inc).

Sorry if this is a repost of a similar bug.

Our spec is Windows OS, PHP 7.1, Drupal 7.65

Thanks

I have D7 website and I'm trying to migrate it to D8. I have these modules installed:
- migrate_drupal
- migrate_drupal_ui
- migrate_drupal_multilingual
- migrate_upgrade
- migrate_tools (8.x-4.x-dev)
- migrate_plus

On 'process' page (admin/structure/migrate/manage/migrate_drupal_7/migrations/upgrade_d7_comment_type/process) the source value of 'label' is duplicated when I check d7_comment_type plugin (path: ./core/modules/comment/migrations/d7_comment_type.yml).

Within the plugin the label property is configured with 'name' and 'constants/label_suffix' sources:

  label:
    plugin: concat
    source:
      - name
      - 'constants/label_suffix'
    delimiter: ''

in Migration::__construct there is the following line:

    foreach (NestedArray::mergeDeep($plugin_definition, $configuration) as $key => $value) {

NestedArray::mergeDeep() does not preserve the integer keys. As far as I can tell, the solution is to use NestedArray::mergeDeepArray().

Problem/Motivation

Follow up to #3075695: Move search_index() and related functions to a service there are a number of text processing/tokenisation functions that can be moved to a service and deprecated. This includes:

• search_index_split()
• search_simplify()
• search_expand_cjk()

Proposed resolution

Move them to a SearchTokenizer service and deprecate.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Pages are not showing up (WSOD) with the following error:

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

InvalidArgumentException: Cannot redirect to an empty URL. in Symfony\Component\HttpFoundation\RedirectResponse->setTargetUrl() (line 86 of vendor/symfony/http-foundation/RedirectResponse.php).

I also noticed that the LOGO and HOME in the main menu do not redirect to the front page but instead they redirect to the current page.

Andrew Macpherson writes:

The hidden text of the edit and remove buttons for an embedded media item should probably include the label of the item, to be more screen reader-friendly.

See #2994702-53: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`

While writing a PHPUnit functional test that installs a full install profile (Lightning, in this case), I encountered this error:

Drupal\Core\Config\Schema\SchemaIncompleteException: Schema errors for core.entity_form_display.scheduled_update.multiple_node_embargo.default with the following errors: core.entity_form_display.scheduled_update.multiple_node_embargo.default:content.entity_ids.settings.size variable type is string but applied schema class is Drupal\Core\TypedData\Plugin\DataType\IntegerData

I traced this a bit and discovered that it was due to this error in EntityReferenceAutocompleteWidget:

  public static function defaultSettings() {
    return [
      'match_operator' => 'CONTAINS',
      'size' => '60',
      'placeholder' => '',
    ] + parent::defaultSettings();
  }

Config schema says size should be an integer. The widget is defining it as a string for some reason. That's no good :) As far as I can tell, there is no reason it should be a string, and this will certainly trip up other config-aware tests. So it should be fixed in core.

Problem/Motivation

The allowed member names for JSON:API objects (i.e. JSON object property names) has an allowed character set. This includes letters, numbers, dashes, underscores, and spaces. Notably, colons are explicitly forbidden.

Unfortunately, JSON:API can serialize multiple links having the same key using a colon. This can happen if multiple resources are omitted from the response for access reasons.

Proposed resolution

Change the serialization to use a double dash (--) instead of a colon (:).

User interface changes

None.

API changes

None. See jsonapi.api.php:

 * HTTP API: URLs and JSON response structures are considered part of this
 * module's public API. However, inconsistencies with the JSON:API specification
 * will be considered bugs. Fixes which bring the module into compliance with
 * the specification are *not* guaranteed to be backwards-compatible. When
 * compliance bugs are found, clients are expected to be made compatible with
 * both the pre-fix and post-fix representations.

Data model changes

None.

Release notes snippet

JSON:API omission links are now keyed using a double-dash-separated syntax instead of a colon-separated syntax in order to be brought into compliance with the JSON:API specification on allowed member names.

Before:

{
  meta: {
    omitted: {
      detail: Some resources have been omitted because of insufficient authorization.,
      links: {
        help: {
          href: https://www.drupal.org/docs/8/modules/json-api/filtering#filters-access-control
        },
        item:llCqfLQ: {
          href: http://drupal.test/jsonapi/taxonomy_term/tags/6cf1af19-9a7f-4daf-9d70-8da5c878b603,
          meta: {
            rel: item,
            detail: The current user is not allowed to GET the selected resource. The 'access content' permission is required and the taxonomy term must be published.
          }
        }
      }
    }
  }
}

After:

{
  meta: {
    omitted: {
      detail: Some resources have been omitted because of insufficient authorization.,
      links: {
        help: {
          href: https://www.drupal.org/docs/8/modules/json-api/filtering#filters-access-control
        },
        item--llCqfLQ: {
          href: http://drupal.test/jsonapi/taxonomy_term/tags/6cf1af19-9a7f-4daf-9d70-8da5c878b603,
          meta: {
            rel: item,
            detail: The current user is not allowed to GET the selected resource. The 'access content' permission is required and the taxonomy term must be published.
          }
        }
      }
    }
  }
}

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the block, block_content, and block_place modules.

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. Existing topics could be in one of the following directories:
   

   core/modules/help_topics/help_topics
   core/modules/MODULENAME/help_topics
   core/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 one of the modules' help_topics directory (you will probably need to create that directory). Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can put it in core/help_topics. 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 Core), 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).
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 .
7. Make a patch file that adds/updates the Twig templates in Core. 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/action/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.