Problem/Motivation

The recent 8.6.16 security update added a dependency on PHP's fileinfo extension.

Error: Class 'finfo' not found in TYPO3\PharStreamWrapper\Phar\Reader->determineFileType() (line 155 of /home/xxxx/public_html/vendor/typo3/phar-stream-wrapper/src/Phar/Reader.php).
Drush command terminated abnormally due to an unrecoverable error.                                                                                                            [error]
The external command could not be executed due to an application error.                                                                                                       [error]
The command could not be executed successfully (returned: Error: Class 'finfo' not found in TYPO3\PharStreamWrapper\Phar\Reader->determineFileType() (line 155 of   [error]
/home/xxxx/public_html/vendor/typo3/phar-stream-wrapper/src/Phar/Reader.php).
, code: 255)

After that Drush stops working.

I had to restore a backup with the insecure 8.6.15 version.

Proposed resolution

• Fix upstream in https://github.com/TYPO3/phar-stream-wrapper/pull/33
• Bump typo3/phar-stream-wrapper library version to v2.1.2 to remove fileinfo extension dependency

The changes upstream are: https://github.com/TYPO3/phar-stream-wrapper/compare/v2.1.1...v2.1.2

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

Problem/Motivation

When a language is removed the content that was created in that language loses it's field content.

Steps to reproduce

1. Install Drupal in English
2. Create an English article with some body text.
3. Enable the Language module
4. Add a language, make it the default language (admin/config/regional/language).
5. Remove the English language.
6. Go to the English article and notice that the body text is gone.
7. Edit the English article and notice that the body field is empty.

A quick investigation showed that the language code in the field__body and the node tables are, after deleting English, still at 'en'. The confirmation message in step 5 says "Deleting a language will ... and content in this language will be set to be language neutral." But apparently this does not happen.

The English content can be restored by adding English as language (admin/config/regional/language) and rebuilding the cache (drush cr).

Proposed resolution

• Set the content language to Neutral when removing a language.

Remaining tasks

t.b.d.

User interface changes

None

API changes

t.b.d.

Data model changes

None

Problem/Motivation

Currently, Drupal\ckeditor\Plugin\Editor\CKEditor::getJSSettings() uses a + operator to combine the configuration arrays provided by plugins. In the event there are identical keys, the first instance is honored, not the last. Drupal's Internal plugin sets some config by default:

  /**
   * {@inheritdoc}
   */
  public function getConfig(Editor $editor) {
    // Reasonable defaults that provide expected basic behavior.
    $config = [
      // Don't load CKEditor's config.js file.
      'customConfig' => '',
      'pasteFromWordPromptCleanup' => TRUE,
      'resize_dir' => 'vertical',
      'justifyClasses' => ['text-align-left', 'text-align-center', 'text-align-right', 'text-align-justify'],
      'entities' => FALSE,
      'disableNativeSpellChecker' => FALSE,
    ];

    ...

    return $config;
  }

This means that another plugin, such as the one provided by CKEditor custom config, cannot override the 'pasteFromWordPromptCleanup' config option.

I'm filing this as a bug report, because of the following comment in Drupal\ckeditor\Plugin\CKEditorPlugin\Internal::getConfig():

// Reasonable defaults that provide expected basic behavior.

The language shows a clear intent to provide defaults, not to hard-code these values.

Proposed resolution

Use array_merge() to combine the arrays instead.

Remaining tasks

Submit patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

In versions of Drupal prior to 8.8.0, it was not possible to override CKEditor default configuration provided by the Internal plugin. In the event multiple plugins provided configuration with the same key, the first instance was honored. Beginning in Drupal 8.8.0, the last instance is now honored.

When you use Layout Builder and embed an inline custom block type that contains a Media entity reference field (form display configured with the Media Library widget) you will end up with an additional empty block being placed on the page.

So this issue occurs with the following setup - tested with a fresh install of Drupal 8.7.1 with no contributed modules, just core ones enabled.

Follow these steps to recreate the issue:

1. Enable the following modules:

• Layout Builder
• Layout Discovery
• Media
• Media Library

2. Create a Custom Block type in the interface that contains a Media entity reference field.

3. Configure a content type to use Layout Builder for its display settings.

4. Create a new node instance using that content type, switch to the Layout view and start editing the layout of the node.

5. Click "Add Block" to launch the sidebar, choose the custom block you created from the "+ create custom block" section. Fill in all the details and use the Media Library widget to add a new image (or select an existing one, this issue occurs with either). Click "Add Block" to add the block to the page.

6. The block will get added twice to the page. One will contain all the information you entered, including the image. But above it will be another instance of the block but it will be devoid of information.

The point in which the empty block gets embedded on the parent page is at the point you click "Insert selected" or "Save and insert" from within the Media Library modal widget. This is somehow triggering the submission of the block form.

Problem/Motivation

Steps to reproduce:

Install Layout Builder module
Manage Display of one content type, like "Basic Page". Under "Custom Display Settings", enable Full view mode
Manage Display of a different content type, like "Article".

Expected

Overrides can be enabled for Articles

Actual

No checkbox present, overrides cannot be enabled

Proposed resolution

Limit the query to the specific entity type and bundle.

Remaining tasks

Write tests

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Original report

I've been building a mega menu in my dev environment based on this tutorial . I updated that environment to 8.7 and everything I was working on broke due to the disappearance of the ability to customize layouts of individual menu items.

How to Reproduce

1. Update to 8.7
2. Install Layout Builder, Menu Item Extras
3. Go to /admin/structure/menu/my_menu/display to view location of missing settings

Expected Behavior

The second checkbox to allow menu items to have custom layouts should still be available.

What Happens Instead

The second checkbox is missing. Features that depend on this setting break. I can no longer manage layouts on individual menu items.

Problem/Motivation

This is a D7 follow-up to #2886609: Migrate translations for D6 i18n taxonomy 'localized' terms

Drupal 7 i18n_taxonomy provides two different multilang concepts: 'localized terms' and 'per language terms'.

The scope of this issue is to migrate the translations of the D7 'localized' terms to D8.

Proposed resolution

The scope of this issue is to migrate D7 taxonomy term translations.

D7 vocabulary translation settings are handled in #2979970: Migrate D7 vocabulary language settings

References between translated nodes and translated terms are handled in #3035392: Migrate taxonomy term references for D7 Node translations

Remaining tasks

Postponed on #2886609: Migrate translations for D6 i18n taxonomy 'localized' terms
1. Write a patch.
2. Test manually and review the patch.
3. Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Problem/Motivation

When uploading a new file using the Media Library module, the "Add File" action fails to upload the file and silently throws a console error. This error occurs every time with every media type for our site.

Steps to reproduce:

1. Choose a node that contains a media field for editing using the "Add media" button.
2. In the resulting "Add or select media" lightbox, click the "Choose File" button in the "Add File" section.
3. Choose a file of the appropriate media type.
4. At this point, a progress spinner is shown then disappears. Nothing further occurs and the file is not added to the library.
5. Check the console log to see the Ajax error:
   

   An AJAX HTTP error occurred.
   
   HTTP Result Code: 200
   
   Debugging information follows.
   
   Path: /media-library?media_library_opener_id=field%3Afield_documents_media_&media_library_allowed_types%5Bbasic_image%5D=basic_image&media_library_allowed_types%5Bdocuments%5D=documents&media_library_allowed_types%5Bicon%5D=icon&media_library_allowed_types%5Blocation_photos%5D=location_photos&media_library_allowed_types%5Bremote_video%5D=remote_video&media_library_selected_type=basic_image&media_library_remaining=1&hash=wFpjTCU6C4We9HKZWN4uK4B2cxaXeEhPCddqHR-vBKQ&media_library_content=1&_wrapper_format=drupal_ajax&ajax_form=1
   
   StatusText: parsererror
   
   ResponseText: Notice: Undefined index: #parents in /app/web/core/modules/media_library/src/Form/AddFormBase.php on line 250
   
   [...]

OS: nginx/1.14.2
Database: 5.5.5-10.1.38-MariaDB
PHP 7.2.15
Drupal 8.7.0

Proposed resolution

Adding a null check to AddFormBase.php:buildEntityFormElement():250 allowed me to successfully upload files (patch file to follow in comments).

-    $parents = $form['#parents'];
+    if (array_key_exists("#parents", $form)) {
+      $parents = $form['#parents'];
+    }
+    else {
+      $parents = [];
+    }

Problem/Motivation

I enabled core modules:
- Toolbar
- Contextual Links

I generated a custom content entity with Drupal Console, added a `my_module.links.contextual.yml` file and added `{{ title_suffix }}` to the entity template.
So far so good. Then, at first page load, if toolbar icon is already active, all blocks and nodes contextual links are visible, but not the ones for my custom entity.
The button is there but not visible, because class `.visually-hidden` is still present on the element.

If I disable all links and enable again (by clicking on the toolbar icon), even the links for the custom entity are visible.
This is due to `adjustIfNestedAndOverlapping()` function called on `contextual.js`, which removes the class and hides nested contextual links anyhow, after adjusting the position.

$trigger.removeClass('visually-hidden');
height = $nestedContextual.height();
$trigger.addClass('visually-hidden');

Proposed resolution

It's necessary to remove the class only if the state of contextual links is not visible.

I am trying to add a relationship to a taxonomy term in a view based on Content (nodes). I want to be able to sort by the Taxonomy term name. I’ve gone ahead and added a relationship to the vocabulary. However, after adding the “Taxonomy term: Name (asc)” to the Sort Criteria (ensuring that it’s using the proper relationship), I get the following message “The sort criterion Taxonomy term: Name uses a relationship that has been removed”.

I’ve added a screenshot, showing that the relationship exists and views is saying that it has been removed.

Problem/Motivation

I was having a weird problem in a WebTestBase test that I am using to generate screenshots in Hungarian for the translation of the User Guide, and I traced it down to a weird bug that is either a problem in Drupal Core or localize.drupal.org, or some combination.

I was able to reproduce this bug on simplytest.me with the following steps:

a) Install Drupal Core 8.2.0-rc2 in English, with the Standard profile. Make sure that you check the "Check for updates" box, so that the Update Manager module is installed.

Note: In comment #17, this was retested in Drupal 8.6.x as of April 30, 2018, and it is still a bug.

b) Install the 4 multilingual modules from admin/modules.

c) Go to admin/config/regional/language and add Hungarian. Translations are imported from localize.drupal.org. Hungarian is 99% translated today in RC2 -- there are only 2 untranslated strings.

d) Set Hungarian as default language and delete English. (Note: this is interesting to try to do when you do not read Hungarian! Quite an adventure. Luckily, I am "slightly familiar" with the Drupal admin UI and URLs. :) ) At this point, you can verify that the Toolbar across the top of the screen is fully in Hungarian. In particular, the left-most link from the Manage menu (Content in English) says "Tartalom".

e) Go to admin/modules and install the core Activity Tracker module. Translations are imported. Note: I have no idea why translations would be imported at this time, since weren't they already imported for Core? But they are definitely being imported... I can see this in my test as well.

f) Go to admin/config/regional/translate and search for the word "Content". You will see that its translation has become "Content" (English) instead of "Tartalom". Content type is also screwed up, but some other words are still translated... Screenshot:

In my tests, after this point the Toolbar in screenshots is sprinkled with English words amongst the Hungarian. The words "Help" and "People" and "Content" are in English, while the rest is still in Hungarian. But the root cause appears to be that some translations are being overwritten.

I have no idea what the root cause of this happening is... and I think I have a way to work around it for my screenshots (on admin/config/regional/translate/settings I should be able to set it so imports do not overwrite existing translations. Hopefully.) Also note that in my tests I have verified just before installing this module that the word Content is translated to Tartalom and just after it is Content, so I am quite sure it is the translation import from this module install that is causing the problem.

Proposed resolution

1. Figure out why:

a) Translations are being imported when installing a Core module even though Core translations have already been imported when I added the language.

b) When they are imported, they are overwriting some words with English instead of Hungarian.

2. Fix the problem(s).

Remaining tasks

Make a patch with a test.

User interface changes

UI translations will not be overwritten when installing a Core module.

API changes

Probably not.

Data model changes

Probably not.

Problem/Motivation

#2976148: Layout-based entity rendering should delegate to the correct section storage instead of hardcoding to either defaults or overrides changed how Layout Builder prevents infinite recursion when rendering FieldBlocks.

Before, it prevented any of the LB rendering code from running.
Now it only prevents any infinite recursion from occurring.

However, this means that all of the LB rendering code is running for each FieldBlock, even though it will never result in any real changes to the output.

Proposed resolution

Move the code from isLayoutBuilderEnabled() to buildMultiple()

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

We have a situation where we need a summary view (done as in glossary mode using the first letter of the last name) on an embed view display that lists people. This type of glossary filtering is a relatively common request.

We don't want to use page displays for a number of reasons, so this embed view is displayed within a node entity (as part of a paragraph type but that is likely unimportant.)

The key is that we need to be able to set a base path for the summary links and not let Drupal simply use the path of the first view page display (of which there is not one.)

Attachments are allowed on embed displays: #2886613: Allow Attachments on Embed Displays so this does seem like necessary functionality.

The base path field in the contextual filter options says: "Define the base path for links in this summary view, i.e. http://example.com/your_view_path/archive. Do not include beginning and ending forward slash. If this value is empty, views will use the first path found as the base path, in page displays, or / if no path could be found."

When no base path is entered, the summary links fallback as expected to / which obviously won't work for us but doesn't throw an error.

When a base path is entered such as 'super-page' (no beginning or ending slashes), I would expect that the summary links would then use "super-page/[letter argument]". However, instead the view completely fails to load and throws the following error:

Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "node" for route "entity.node.canonical" must match "\d+" ("s" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 204 of /web/core/lib/Drupal/Core/Routing/UrlGenerator.php).

This error occurs both when using "node/[nid]" and when using the path alias of the node.

In mymodule.routing.yml it is possible to define _method in route requirements to allow access using only specified request methods. It seems that route validation, however, does not preserve request method and defaults to GET requests, which will then fail the _method requirement always.

According to stack trace, the problem seems to lie in Drupal\Core\Routing\AccessAwareRouter::match, as the Request object is created from plain path without any other context.

mymodule.vote:
  path: '/foobar/vote'
  defaults:
    _controller: '\Drupal\mymodule\Controller\FoobarViewController::vote'
  requirements:
    _entity_access: 'foobar.view'
    _method: 'POST'

Symfony\Component\Routing\Exception\MethodNotAllowedException: in Symfony\Component\Routing\Matcher\UrlMatcher->match() (line 101 of core/vendor/symfony/routing/Matcher/UrlMatcher.php).

Drupal\Core\Routing\UrlMatcher->finalMatch(Object, Object)
Symfony\Cmf\Component\Routing\NestedMatcher\NestedMatcher->matchRequest(Object)
Symfony\Cmf\Component\Routing\DynamicRouter->matchRequest(Object)
Symfony\Cmf\Component\Routing\ChainRouter->doMatch('/kysy-kirjastonhoitajalta/vote', Object)
Symfony\Cmf\Component\Routing\ChainRouter->matchRequest(Object)
Drupal\Core\Routing\AccessAwareRouter->matchRequest(Object)
Drupal\Core\Routing\AccessAwareRouter->match('/kysy-kirjastonhoitajalta/vote')
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->isAdminPath(Object)
Drupal\user\Plugin\LanguageNegotiation\LanguageNegotiationUserAdmin->getLangcode(Object)
Drupal\language\LanguageNegotiator->negotiateLanguage('language_interface', 'language-user-admin')
Drupal\language\LanguageNegotiator->initializeType('language_interface')
Drupal\language\ConfigurableLanguageManager->getCurrentLanguage()
Drupal\language\EventSubscriber\LanguageRequestSubscriber->onKernelRequestLanguage(Object, 'kernel.request', Object)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.request', Object)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)

I am trying to use a local copy of providers.json so I can add a local provider but I have to use an absolute url and not a stream wrapper like public://providers.json or module://my_module/providers.json. Does it makes sense to allow this? Or is there a better way to add a custom providers.json file?

This is sort of related to https://www.drupal.org/project/drupal/issues/2999018.

I've attached an example patch.

Updated a small, simple, brochure site from 8.6.12 to 8.7.0.

composer update drupal/core webflo/drupal-core-require-dev --with-dependencies had no complaints.

update.php produced three identical notices:

Notice: Undefined index: #include_fallback in Drupal\Core\Render\Element\StatusMessages::generatePlaceholder() (line 59 of ... Core\Render\Element\StatusMessages.php)...

The site's few pages all look good.

I confess I'm learning to theme, but I don't know much about Core. I looked up that error and found it happens in a lot of PHP code. Is this a problem?

Problem/Motivation

When adding a datetime exposed filter I cannot simply select a date - I have to manually enter a date which is very bad UX.

Proposed resolution

Use a form element with '#type' => 'datetime' so it's easy for users to select the date.

Change Record

Remaining tasks

• Investigate why the default value of the exposed filter is not picked up by the form (see #104). see #115
• Hide time element for date-only type fields
• Create a follow-up for the possibility for site builder to decide the widget type from the views management UI (see #48)

User interface changes

Exposed date filters will have input[type=date], and will leverage HTML5 handling if supported by the browser, or fall back to the polyfill if it doesn't.
For datetime w/ type date-only we should still use the datetime form element, but in date-only mode ($element['#date_time_element'] = 'none'.

API changes

None.

Data model changes

None.

Hello,

One year ago, the Drupal 8 html_tag has been updated and it's now able to render nested tags, see the CR here #2887146.

I backported the functionnality to Drupal 7 so no, we can render this render array properly, including the children.

To test the functionnality, run this code before and after applying the patch in /devel/php:

$render_array = array(
  '#type' => 'html_tag',
  '#tag' => 'h1',
  '#attributes' => array('class' => 'title'),
  'children' => array(
    array(
      '#type' => 'link',
      '#title' => 'Link title',
      '#href' => '/',
      '#attributes' => array('class' => 'inner'),
    ),
    array(
      '#theme' => 'link',
      '#text' => 'Link title',
      '#path' => '/',
      '#options' => array(
        'attributes' => array(),
        'html' => FALSE,
      )
    ),
  )
);

$html = render($render_array);

debug($html);

Without the patch: <h1 class="title" />

With the patch: <h1 class="title"><a href="/" class="inner">Link title</a><a href="/">Link title</a></h1>

Another example:

$render_array = array(
  '#type' => 'html_tag',
  '#tag' => 'h1',
  '#attributes' => array('class' => 'title'),
  '#value' => 'value',
  'children' => array(
    array(
      '#type' => 'link',
      '#title' => 'Link title',
      '#href' => '/',
      '#attributes' => array('class' => 'inner'),
    ),
    array(
      '#theme' => 'link',
      '#text' => 'Link title',
      '#path' => '/',
      '#options' => array(
        'attributes' => array(),
        'html' => FALSE,
      )
    ),
  )
);

$html = render($render_array);

debug($html);

Without the patch: <h1 class="title">value</h1>

With the patch: <h1 class="title">value<a href="/" class="inner">Link title</a><a href="/">Link title</a></h1>

Change record

Proposed change record: https://www.drupal.org/node/2982025

Follow-up to #2263569: Bypass form caching by default for forms using #ajax.

Problem/Motivation

- The added request parameters bleed into links.
- E.g. right-clicking on a newly loaded pager link, returns AJAX

Proposed resolution

- Remove internal request parameters from the Request object as soon as possible, store them somewhere else, so that later subscribers can still access them.

( Service? Request->param() *brrr*? ... )

Remaining tasks

- Stalk Crell :-D
- Discuss

User interface changes

API changes

Problem/Motivation

The Symfony 3.4 LTS will be EOL in 2021: http://symfony.com/doc/current/contributing/community/releases.html#sche...

This means we need to be ready to move to Symfony 4 before then.

Proposed resolution

We should at least do the following:

1. Identify all the deprecated Symfony code that Drupal 8 relies on and update for it, opening issues for anything not straightforward #2959269: [meta] Core should not trigger deprecated code except in tests and during updates

2. Have an issue with a patch that updates to Symfony 4 so we can see if it passes or not. This is ongoing at #2976394: Allow Symfony 4 to be installed in Drupal 8

3. Potentially, relax our composer.json requirements to allow Symfony 4 to be installed, once the above two are done, if it's feasible to do so.

Remaining tasks

Review and commit the child issues here.

User interface changes

API changes

Data model changes

Problem/Motivation

Discussing the layout builder at Drupaldelphia BoF.

When editing the layout for a view mode you get dummy content applied that may not be helpful to understand how the real content will look.

Proposed resolution

Add an EntityReference autocomplete box that allows selecting a node (or other entity) for the user to (temporarily?) use as the content to be shown while editing the layout. Ideally change the content or refresh the display when a new node is picked - allowing the site builder to check how the layout will work with different examples of the content.

Remaining tasks

Decide how it should work, build it

User interface changes

added field to the layout form + new functionality

API changes

n/a