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

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

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

followed by the following error:

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

I noticed MenuLinkContentStorage.php was newly introduced.

Problem/Motivation

Recent security releases have shown that the render system needs to be stricter about what it allow to be called by a callback. See:

• https://www.drupal.org/sa-core-2018-002
• https://www.drupal.org/sa-core-2018-004
• #2860607: Code execution via Twig templates (including inline)

Render list of callbacks to target:

• #access_callback
• #lazy_builder
• #post_render
• #pre_render

Because render callbacks use \Drupal\Core\Controller\ControllerResolverInterface::getControllerFromDefinition this allows them to instantiate any service and call public methods on them. Therefore for non-ElementInterface objects we need an additional RenderCallbackInterface object to declare with objects contain a callback and which methods can be called on said object.

Procedural function support is removed.

Form callbacks will be handled in #2966711: Limit what can be called by a callback in form arrays

Proposed resolution

1. In 8.7.x deprecate the ability to call any function using call_user_func*() and limit to object implementing TrustedCallbackInterface, ElementInterface or a closure. For non-ElementInterface objects also limit to specific methods to further narrow the surface area.
2. Try and provide a PHPCS fix that can auto-update code?
3. In 8.8.x or 8.9.x remove the ability? Definitely for 9.0.0

Remaining tasks

Review.

User interface changes

None

API changes

• Add \Drupal\Core\Security\TrustedCallbackInterface.
• Add \Drupal\Core\Security\TrustedCallbackTrait to make doing a trusted callback simple
• Trigger a deprecation error if a render callback is a procedural function or an object that does not implement TrustedCallbackInterface or RenderElementInterface or a closure.
• drupal_pre_render_links() replaced with \Drupal\Core\Render\Element\Link::preRenderLinks()
• color_block_view_pre_render() replaced with \Drupal\color\ColorBlock::preRender()
• filter_form_access_denied() replaced with \Drupal\filter\Element\TextFormat::accessDeniedCallback()
• history_attach_timestamp() replaced with \Drupal\history\HistoryRenderCallback::lazyBuilder()
• _toolbar_do_get_rendered_subtrees() replaced with \Drupal\toolbar\Controller\ToolbarController::preRenderGetRenderedSubtrees()
• toolbar_prerender_toolbar_administration_tray() replaced with \Drupal\toolbar\Controller\ToolbarController::preRenderAdministrationTray()
• views_pre_render_views_form_views_form() replaced with \Drupal\views\Form\ViewsFormMainForm::preRenderViewsForm()

Data model changes

None.

Problem/Motivation

Drupal.Ajax.success attempts to set focus to the element that triggered the ajax request.

You can stop by adding the attribute data-disable-refocus to the element if another InvokeCommand is returned that sets focus.

This functionality is not actually tested anywhere and it does not work if the element is inside a dialog.
In #2995689: Allow reordering blocks without a pointer device it would be great if this worked because we are using an ajax element in dialog.

Proposed resolution

Make it work!

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I managed all of my sites with composer's drupal-project, but when it comes to contributing modules/patches I use the git version of mostly everything, however, adding composer dependencies that module's require means that I always end up with a modified composer.json and composer.lock files, so each time I want to git pull drupal I have to clean this files, update, install and re-add everything else.

I wonder if there's anything better to be done around that.

As a simple solution, I thought of having a composer.local.json file included in the composer.json file of drupal. With this we can add our own requires and a simple

composer update --lock would update those if we need to clean the lock file, pull, install and then composer update --lock again.

This is a follow-up to #2994699: [PP-1] Create a CKEditor plugin to select and embed a media item and part of #2801307: [META] Support WYSIWYG embedding of media entities.

Once it is possible for authors to use CKEditor to open their media library, select item(s) from it, and drop them into CKEditor with embed-specific metadata (e.g., alt text to be used for just that particular instance), we'll need some way for users to re-open and edit the embedded metadata.

Depending on how #2994699: [PP-1] Create a CKEditor plugin to select and embed a media item ends up, this issue might not be needed, but the functionality is definitely needed in order for Media's CKEditor integration to be considered feature-complete.

Problem/Motivation

An issue occurs when more than 100 items exist in the root of the menu or under a single parent item, or items exist with a weight outside of -50..50 (causing overflow when trying to fit that weight into the select form element).

Proposed resolution

A patch was drafted using the parameter ($delta) to the recursive helper function
_menu_overview_tree_form() to build the menu tree form. $delta first gets set in menu_overview_form() to the total number of links in the menu

The book and taxonomy modules address this issue in these ways.

A possible solution includes a generic procedural function that takes a minimum value and a maximum value and returns the recommended FAPI delta based on that.

The interdiff file is available.

The last patch failed testing with these results.

Remaining tasks

Remaining tasks might include a more integrated solution across the implementation of menu instances, partly described by Dries, D7 backport, and testing.

Unit testing any new procedural function would be a need.

User interface changes

Row weights is described as being criticial in this issue.

Select boxes/widget in text fields are related.

Drop down menus and node forms were also orginially discussed in the issue posting.

API changes

Entity form controllers now appear in core.

I found that it's possible to upload SVG images to Drupal 7 (7.38) and they can even be rendered as the original image, but any image styles don't work (obviously since gd doesn't support SVG). Of course there is the imagemagick module that one could try to use and possibly patch, but it didn't seem to work out of box either. I thought that it would be great to add basic SVG support to Drupal core since many browsers support them and they are great for todays world with different screen sizes etc. By basic support I mean that the SVG images would work with styles, not applying the ones that can't be done without gd or similar image manipulation tool, but simply bypassing the styles and applying for example width and height to the img tag directly when theming the images.

Problem/Motivation

Steps to reproduce:

1. Install Media Library module
2. Create a media reference field selecting the Reference > Media option in the field type list
3. Submit the field storage settings form

Expected result:
The field settings form is shown without errors

Actual result:
The following notice is shown:

Notice: Undefined index: target_bundles in Drupal\media_library\Plugin\Field\FieldWidget\MediaLibraryWidget->getAllowedMediaTypeIdsSorted() (line 155...

Proposed resolution

Add check if the variable is exist.

I am trying to update drupal core from 8.2.8 to 8.3.1 alongwith lightning from 2.0.1 to 2.1.0. I've created the sub profile for lightning and executed all the manual steps mentioned here - https://github.com/acquia/lightning/blob/2.1.0/UPDATE.md. When running travis, I'm getting the below error

Error: Call to a member function getColumns() on boolean in /docroot/core/lib/Drupal/Core/Entity/Query/Sql/Tables.php, line 228

After a bit of debugging I found that the error is coming from the below line and the reason for the error is that $field_storage is setting to FALSE here

$columns = $field_storage->getColumns();

System information before update:

• Drupal Version: 8.2.8
• Lightning Version: 2.0.1

System information after updating:

• Drupal Version: 8.3.1
• Lightning Version: 2.1.0

Problem/Motivation

@plach has been performing his role as provisional framework manager for the past one year and half and has agreed to be promoted to full committer. Dries has provided his sign-off at https://groups.drupal.org/node/535121.

Proposed resolution

Update MAINTAINERS.txt!

Remaining tasks

• Create a patch
• Reviews

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

None

Problem/Motivation

In NodeTypeForm:actions the
$actions['delete']['#value'] = t('Delete content type');
code line has no effect.

Before:

Proposed resolution

Update the actions override, so the code applies correctly:

Remaining tasks

1. Write a patch
2. Review
3. Commit

User interface changes

The link 'Delete' now displays the text 'Delete content type' on the node type edit form.

API changes

None.

Data model changes

None.

Problem/Motivation

In certain cases we want to disable duplicate messages (on top - summary - and inline).
We currently have the #error_no_message property which allowed us to disable errors messages for individual elements.

There may be some field that does not display the inline error, so the message is only visible in the summary. As an example, the Captcha field.
We should then keep the messages in the summary - even when the new property to disable the summary is requested - for fields that contain errors but can't display them inline (Eg. invisible elements, missing elements, ...).

Proposed resolution

Add a form property which can be used to disable IFE summary$form['#disable_inline_form_errors_summary'] = TRUE.
Keep the message in the summary for fields which can't show inline-error (Eg. invisible elements, missing elements, ...).

Completed tasks

• Write a patch.
• Update the patch as requested in #17 (numbered points). (Done by #20, #24, #26).
• Issue summary update requested in #17.
• Write tests. (Done by #20, #24).
• Write a inline_form_errors.api.php where we can document how both of these works. See #17
• Write a patch for #3027318: Improve test coverage for Inline Form Errors Improve test coverage for Inline Form Errors

Remaining tasks

• Once #3027318: Improve test coverage for Inline Form Errors merged, address issue #29
• Review and commit.

User interface changes

• Developers will be able to remove the Summary message when IFE is enable.
• The summary should still be visible for an element which can't show inline-error (invisible element, missing element, ...).

API changes

The form element will have an optional #disable_inline_form_errors_summary boolean, that if TRUE, disables the duplicate messages from summary & inline-error elements. If one or more elements with errors can't show inline-error (Eg. invisible elements, missing elements, ...) , the summary will remain visible with those messages only.

Problem/Motivation

If "Interface text language detection" sets "Account administration pages" as the primary, a field title isn't translated.

Steps to reproduce:

1. Install Drupal with the standard profile in English.
2. After installation, login as an administrator (uid 1).
3. Enable the following modules: Configuration Translation, Interface Translation, Language.
4. Add Japanese language.
5. On the "Detection and selection" page, enable "Account administration pages" and disable others except the grayed-out "Selected language".
6. Check if a Japanese translation is shown on the "Edit Japanese translation for Picture" page.
7. Change the "Administration pages language" settings from "- No preference -" to "Japanese" on the logged-in user edit page.
8. Go to the logged-in user edit page.
9. Picture field title isn't changed to the Japanese translation. Any other field titles such as "Current Password" and "Roles" are changed to Japanese translation.

I installed Drupal 8.8.x-dev and followed the steps above.
If "Selected language" is set as the primary instead of the "Account administration pages" and Site language settings are changed to the same as the step 7 above, Picture field title is changed to the Japanese translation.

Problem/Motivation

While discussing the design for the Media Library, we noticed that the naming of the standard Media types is not very clear out-of-the-box. It is not automatically clear which file types can be added in the "File" media type. The supported filed extensions are "txt, rtf, doc, docx, ppt, pptx, xls, xlsx, pdf, odf, odg, odp, ods, odt, fodt, fods, fodp, fodg, key, numbers, pages". Media types should be as specific as possible to manage user expectations. The media type "File" seems to be too broad of a term for the limited list of file extensions.

Proposed resolution

Looking at the supported file extensions, "Document" seems to be a better fit for the "File" media type. This will only be done for new installs, existing sites should not be changed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While discussing the design for the Media Library, we noticed that the naming of the standard Media types is not very clear out-of-the-box. It is not automatically clear what "Remote video" means and which providers are supported.

Proposed resolution

Some options that came up, but there might be better alternatives:

1. Keep the label and provide clear feedback which providers are supported. Similar to the list of extensions below an file/image field.
2. Rename 'Remote video' to 'Youtube/Vimeo'.
3. Other options?

Remaining tasks

• Discuss the best way to improve the UX and make clear what a remote video is (and which providers are supported) in the media library.
• Create a patch.

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Spin-off from #2988431: [Meta] Accessibility plan for Media Library Widget:

The grid view contains a link you can't click.

Currently, when using the media library widget, the grid display of the media item contains a link to the canonical URL of the media item. This is the case for:

• The grid display in the media library view.
• The previews of the media items when you have selected them in the widget.
• The 'Additional selected media' element shown below the added items (from #3023797: Let users choose what to do after selecting and/or adding items in the media library).

This currently has 2 issues:

1. Media does not necessarily have a canonical route, see #3017935: Media items should not be available at /media/{id} to users with 'view media' permission by default
2. For at least the links in the modal, we don't want them to be active because they take the user away from their current task, without being able to go back. This has been "solved" by adding pointer-events:none on and a click handler, but users can still tab to the link.

Proposed resolution

I don't think we really need this link. Let's just remove it.

Remaining tasks

Write patch
Code review
A11Y review
UX Review
Commit

User interface changes

Remove the link from the grid display of media items in the media library widget.

Current HTML

Current tabbability

As you can see, we can still tab to it, despite pointer-events: none;:

API changes

None

Data model changes

None

Release notes snippet

I have a few blocks that have more links that point to URL's other than View pages. I've previously used the Footer section to provide these links, but thought it might be easier if I could enter a custom URL in the Link Display section for a block...

What do you think?

after updated a dev (IP only) box from 8.7.1 to 8.7.2, I get a persistent error on any page "The provided host name is not valid for this server," basically taking the whole site down. reboots/service restarts have no effect. I have not set trusted_host_patterns in settings.php because it's a dev box. Setting the trusted_host_patterns to include a full wildcard has no effect:

$settings['trusted_host_patterns'] = array(
'.*',
);

I hope I selected the right component in the bug report.

I understand how to configure the $database['default']['replica'][] settings so that I can point to 1..N replica servers.

I do not understand how to get anything but my custom-written queries to leverage the Replica servers.

This seems to me like a core feature to supporting multiple databases in core, but I see no clear path to handling this logic, nor do I see a clear place to override this

I've even tried

 if (!isset($options['target']) && stripos($query, 'SELECT') === 0) {
        $options['target'] = 'replica';
      }
      return parent::query($query, $args, $options);

in
Drupal\Core\Database\Driver\mysql\Connection function query(
but whatever other processes are involved with loading any page in Drupal appear to mark the replica as invalid, so I never actually have any queries that execute against the replica in this scenario.

This seems to me like a core scaling issue for Drupal, so I'm not clear on if I'm just misunderstanding how this is supposed to work, or if the only recommendation is to use an external process such as proxySQL or other mechanism to split read/write queries across master/slave (primary/replica)

Problem/Motivation

In #2842431: [policy] Remove PHP 5.5, 5.6 support in Drupal 8.7 and #2927344: Specifically warn about end dates for PHP support for old versions, we decided to end PHP 5.5 and 5.6 support after determining that most hosting providers had PHP 7.0+ available. However, to better support the community for this upgrade, we wanted to track which hosts do not yet support PHP 7.0+. Tracking the availability of PHP 7.1+ will also help us make informed decisions about how long that version is supported, which is what we need now for #2917655: [policy] Decide on PHP 7.x support status.

Proposed resolution

Track which hosting providers do and don't support PHP 7.1, PHP 7.2, PHP 7.3, etc.

PHP 7 already supported

Unclear or unknown

(None ATM)