Drupal core allows access to /admin/people/create based on the permission 'administer users'. This is correct by default, in vanilla core. However it ignores any code that has implemented hook_entity_create_access.

This issue is a blocker for contrib module Administer Users by Role.

Steps to reproduce

• Create a custom modules that implements hook_entity_create_access as below (plus XXX.permissions.yml to define the new permission).
• Create a user with permission 'create users' and log on as that user.
• Visit /admin/people/create
• Expected behaviour: can access page.
• Actual behaviour: access denied.

function XXX_entity_create_access(AccountInterface $account, array $context, $entity_bundle) {
  if ($context['entity_type_id'] != 'user') {
    return AccessResult::neutral();
  }

  return AccessResult::allowedIfHasPermission($account, 'create users');
}

Resolution

If the requirement is changed to _entity_create_access: 'user' it works perfectly. The new code is consistent with a variety of other places in Drupal Core.

Problem/Motivation

Several problems were identified in the taxonomy_update_8502() update function that can lead to a broken taxonomy after upgrading to 8.6.0. Symptoms are exceptions/errors while running taxonomy_update_8502() or missing terms in taxonomy tree UIs, even if the corresponding records are available in the taxonomy tables.

More specifically the following issues were identified:

• sorting/consistency problems when processing the update in multiple batches, which can lead to skipping taxonomy hierarchy records or processing them multiple times, which in turns leads to either missing parent records or integrity constraint violations, e.g.
  

  [notice] Update started: taxonomy_update_8502
  [error] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-0-0-en' for key 'PRIMARY': INSERT INTO {taxonomy_term__parent}
  

• incorrect handling of multiple parents for the same term, when those span multiple batches;
• scalability issues when processing a large number of terms, since at each batch step the batch size increases, potentially leading to out of memory errors.

Additionally it seems that Drupal Console is not handling this update properly.

Proposed resolution

• Adjust the term hierarchy records selection query to behave deterministically, track the last processed term so it can be fully processed across batches, and handle batch size properly.
• Use drush or update.php to perform the update.

Remaining tasks

Review/commit.

User interface changes

None

API changes

None

Data model changes

None

Composer update is reporting the following error when updating Drupal Core (no matter to which version, 8.5.x or 8.6.x);

- Updating drupal/core (8.5.6 => 8.6.1): Downloading (100%) The process "unzip -qq 'web/core/d0aae1f2722b0b9203fde990aa92ad76' -d '/var/www/html/vendor/composer/a55bd770'" exceeded the timeout of 300 seconds.
The archive may contain identical file names with different capitalization (which fails on case insensitive filesystems)
Unzip with unzip command failed, falling back to ZipArchive class

Composer has been executed inside a Docker container (https://ddev.readthedocs.io/en/latest/, version 1.2.0) on a Windows 10 Pro host machine. The host filesystem is NTFS.

The user formatter has a setting "Link to the user". The link is only displayed if the account (user that the output is being generated for) has access to view the target user (the one whose name is being displayed).

Expected behaviour: Drupal check access accurately, calling all custom hooks such as hook_entity_access.
Actual behaviour: Drupal checks permission 'access user profiles'

This isn't a security issue - when the link is clicked to visit the page the correct access check is performed, so there will be access denied/403 if necessary.

This feature request was first discussed at Workbench Moderation's issue queue at #2652786: Provide a Views filter for moderation state. It's origin was that currently is not possible to filter content by it's moderation state within a view. Here is a screenshot that illustrates the problem:

@Crell suggested to go for a core solution so all entity reference fields that point to configuration entities could benefit from it, hence I am creating this issue.

Problem/Motivation

When applying the telephone link field formatter on number with 5 digits or less, Drupal miserably breaks, displaying some kind of WSOD with the following message: "The website encountered an unexpected error. Please try again later". Another message can be then found in the watchdog: InvalidArgumentException: The URI 'tel:112' is invalid. You must use a valid URI scheme. in Drupal\Core\Url::fromUri() (line 301 of /media/alex/4126b75c-86e8-4b12-a7c2-08e2d7dbfb08/alex/201310/drupal/core/lib/Drupal/Core/Url.php).

Steps to reproduce

• Create a content type with a telephone field.
• In the "Manage Display" page, choose the "Telephone link" field formatter for this field.
• Create a node of that content type with "123" as value of this field.
• The exception is thrown when the page is displayed.

Cause

The bug occurs in the parse_url PHP function, which processes numbers with 5 digits or less like TCP ports.

Proposed resolution

• Not allowing numbers with 5 digits or less: however, short numbers do exist, like emergency numbers, internal numbers, etc.
• We might have to deal with these numbers differently, though: are there specifications about this?
• Writing our own function, instead of the parse_url PHP function.
• Use a tiny hack to force parse_url to behave as expected. (add an empty query string at the end of the uri)

The underlying parse_url PHP function problem can be managed in a follow up issue. See https://www.drupal.org/node/2575577

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

None.

In Drupal core, there is a single permission 'administer users' that controls whether a user can 'administer' the user account of another user. However the Drupal 8 Entity API makes it possible to refine the access, for example by means of hook_entity_access. This allows modules such as Administer Users by Role to create a "sub-admin" - a user without 'administer users' permissions that nevertheless has access to update some other users' account.

Drupal allows an admin with permission 'administer users' to create/edit/cancel a user with a blank email address. However there is no easy way for a site to extend that permission to a sub-admin. That means that a sub-admin cannot even edit or cancel an account with blank email address unless they set a value for the field.

We should provide a hook to alter permission to assign a blank email address. A secondary use of the hook is so a site can have a policy that blank emails are not allowed, even for a full admin.

Problem

In Russia the URL https://oembed.com/providers.json, as well the whole website https://oembed.com/ is blocked by providers by Roskomnadzor.

Media module in 8.6. is have setting media.settings.oembed_providers_url which used to parse available and actual oEmbed providers for Media. e.g. for Remote video media type.

In our case, Drupal can't access this JSON file and Remote video can't be created at all. Drupal throws error and thats it.

If I trying to add Remote Video on Simplytest, with same URL, this works fine as expected.

Solution

The URL of the provider database is already a configuration setting. Let's expose it in the Media module's configuration form (along with good help text and validation) so that site builders can easily use an alternate provider database.

Remaining Tasks

Write a patch, write tests, bikeshed the help text so it's nice and clear, commit.

Problem/Motivation

You cannot create a view and try to list rendered entities using relationship.

Steps to reproduce (based on Standard profile):

1. Add an entity reference field named "field_content" to the "page" content type. Allow content > article references.
2. Create and edit a content view.
3. Add a relationship for "Content using field_content." or "Content referenced from field_content."
4. The row style plugin is "Content" by default.
5. Click on "Teaser" in order to change the view mode, nothing happens.
6. You can't choose a view mode even if you don't want to actually use a relationship, just having one on your view triggers this.

The problem is a fatal AJAX error triggered when RowPluginBase::buildOptionsForm() calls RelationshipPluginBase::init() while providing a wrong argument type (Array instead of DisplayPluginBase).

Argument 2 passed to Drupal\views\Plugin\views\relationship\RelationshipPluginBase::init() must be an instance of Drupal\views\Plugin\views\display\DisplayPluginBase, array given, called in /app/web/core/modules/views/src/Plugin/views/row/RowPluginBase.php on line 93

Proposed resolution

Fix it, by passing along the relationship as needed and using it.

Remaining tasks

None.

User interface changes

None

API changes

None

If you try to use #ajax on a Views exposed filter form element, the callback is never invoked. This was discussed at length in the Views issue queue here:

#1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback

The same bug exists in the version of Views in Drupal 8 core. As merlinofchaos wrote:

Views are $_GET forms and they specifically remove the form_id and form_build_id and form_token because they are 'submitted' even when they aren't submitted. That means the standard #ajax tools don't work with them, since those rely on being able to cache the form in core's form cache. That system is to naive to work with core's filters. I've never really tried to do anything like this in D7 yet, so I don't know what the solutions might be, but I can say that it's going to provide very ugly URLs if you hack the form id back in.

The proposed solution is to add a little custom JS magic so that we identify all the form info via after_build callbacks, stash those in JS settings, and then inside the JS, we reattach the relevant form info to the #ajax-enabled form elements so that their callbacks can be properly invoked.

Problem/Motivation

Right now, EntityViewBuilder always uses $entity_type_id as #theme. #2698909: EntityViewBuilder uses non-existing #theme hooks corrects that a bit and doesn't use it when no such template exists.

However, to view an entity, you still need to implement hook_theme(), define a template, provide a default template and if you want to do it like node, implement quite some preprocess logic, theme suggestions and so on.

Proposed resolution

This proposes to introduce a standard template, with the common preprocess stuff and theme suggestions.

Instead of node.html.twig, you would then use entity--node.html.twig and so on.

That removes all the unecessary glue code that is currently necessary to have useful entity templates.

Previous attempts at standardizing this failed (#2023571: Support preprocessing in EntityViewBuilder, #2270883: Automatically add theme hook suggestions for all entity types), this basically replaces those issues. Those issues were complicated because it affects existing templates, so there is a risk of changes and BC breaks.

Remaining tasks

User interface changes

None

API changes

A new template.

Data model changes

The ban module enables you to store single IP-addresses, from which any access of the website will be prevented.
In some cases spammers uses IP-ranges from where they spam contact forms. So it would be nice to have a comfortable opportunity to block IP-ranges or if the usage of wildcards would be supported.

Problem/Motivation

Drupal crashes with a segfault when doing a file scan and the the source contains a npm/grunt/nodejs source folder (node_modules). This is probably due to the many folder nesting of npm.
https://drupal.stackexchange.com/questions/126880/how-do-i-prevent-drupa...

Proposed resolution

Ignore the node_modules folder in includes/file.inc, it has no use for Drupal.
Backport Ignore front end vendor folders to improve directory search performance

Remaining tasks

-

User interface changes

-

API changes

-

Original report by guusvandewal

I use grunt to development templates in plain HTML,
if I clone this HTML source for use in the Drupal templates folder( and run npm install afterwards) it's not possible to clear the cache (with or without drush) anymore.
I get an ' segmentation fault 11 ' error.

A fix would be to hide node_modules from Drupal core in includes/file.inc
I've included a patch.

It would be great if this could be implementated, thanks in advance.

Problem/Motivation

Under Block Layout there are three pages. Two of these (Block layout and Block types) are structure and site-building tasks. Any configuration or new block types are exported in the configuration management.
But the Custom block library page is a page to create and edit content. Administrators on a production website need to be able to edit this content - but usually they should not be able to change block layout etc at the same time.
There already is an issue to provide more granular block permissions, or at least a separate permission that only allows to edit an existing block (#1975064: Add more granular block permissions and #2809291: Add "Edit blocks" permissions). This would solve part of the problem because users then can't break the site.
However, users still require access to the whole Structure and Configuration part of the site to get to the Custom block library tab on the Block layout page.

Proposed resolution

Move the "Custom block library" as a submenu item and/or tab on the content page.
It would then also be possible to move "Block types" up one level as a tab on "Block layout" page.

Remaining tasks

User interface changes

This is a UI change, and therefore the hook_help page also needs edited to correct the locations and paths.

API changes

Data model changes

Problem/Motivation

There are many instances where we fetch an object's keys, Object.keys() and then iterate over them, .map()/.filter(). In some instances we have to additionally fetch the value of the object at the key.

Object.entries() simplifies this by returning an array of a given object's own enumerable property [key, value] pairs, in the same order as that provided by a for...in loop.

Proposed resolution

Use Object.entries() where appropriate.

Problem/Motivation

Right now we don't have a solid plan for how we can handle polyfill support.

Proposed resolution

For now, I see a few options:

1. Include the appropriate polyfills manually:

We can provide one file (e.g misc/polyfills.es6.js) which includes needed polyfills (most probably used from https://github.com/zloirock/core-js).

This file will be loaded as the first one before any other JS files.

The similar approach was done by CRA.

2. Add https://polyfill.io/

What we need is just add one js file before any others:
<script src="https://cdn.polyfill.io/v2/polyfill.min.js"></script>

But it seems polyfill.io is a good service with bad polyfills (different authors/projects which doesn't well play together).

3. Configure https://babeljs.io/docs/en/babel-polyfill

It's quite heave. But will include all needed polyfills. Need more investigation.

4. Configure https://babeljs.io/docs/en/babel-plugin-transform-runtime

This solution will add polyfills automatically only when needed (based on target browsers from babel-present-env).

But, that's something which depends on require or import - we don't support it ¯\_(ツ)_/¯

5. Any others?

Remaining tasks

1. discuss with community
2. write solution
3. review
4. 🎉

Problem/Motivation

I think the approach that the views AJAX system takes to determine views arguments is incorrect. Right now when doing AJAX pagination, the view attempts to get all of the contextual view information from the pager link. If ?page=1 is set on the link, it will use that in it's ajax request. If /VIEW-PATH/arg1/arg2/arg3 is set, it will use those three arguments when executing the view.

This makes sense for query strings because they are never aliased and are required to store the pagination state. The problem with arguments is that all of the argument plugins that load context are aware of the underlying route. For example, when a views block is attached to /user/1 (aliased to /member/admin), the plugins can successfully determine that the view needs to be filtered by user id 1.

When an AJAX pagination link is clicked, the arguments are attempted to be determined from the HREF of the link. This is done on the client and has no knowledge of being able to pull an argument value from a route. The result is /member/admin is parsed and "admin" is determined as the argument for the view. Once this filters through to executing the view, the context of this being an entity ID that can be filtered with is lost and the view returns 0 results.

I don't believe we can successfully parse a views arguments on the client without the routing context.

Proposed resolution

When paginating, don't recalculate the views arguments based on the link HREF. Use the same arguments that were present when the view loads.

I believe this makes sense because it's unlikely you would ever want arguments to change between pages.

Remaining tasks

Validate/patch/test.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

I am getting and setting values to PrivateTempStore on every request. This works fine while accessing the site through a browser but when my code is invoked through Drush on the command line. drush cron in this case, no session exists and the following error is thrown:
Error: Call to a member function getId() on null in Drupal\user\PrivateTempStore->getOwner()
getOwner is trying to access $this->requestStack->getCurrentRequest()->getSession()->getId(); where ->getSession() returns null.

Shouldn't PrivateTempStore act as a void store or throw a more informative error about usage in this case?

Problem/Motivation

Imagine an organisation WidgetCo with editors and users in a variety of different time zones. They commonly face 2 problems trying to use the Date module. Support for some of this was present in D7's date but lost as it went to D8 core.

A. When creating session entities as part of their annual conference in New York, the times of the sessions as input by the editor are interpreted by Drupal in terms of the time zone of the editor who is creating or updating it, not New York. In this case their sitebuilder needs to be able to control the time zone used by the widget to interpret the times the editors input.

B. When creating meeting entities to describe meetings held at various locations across the world, the same problem happens. But in this case the intended time zone needs to specified for each meeting by the editor, and that preference needs to be stored with the date/time.

Proposed resolution

• Refactor datetime formatters to simplify the logic.
• Give settings to the datetime widgets (shared in common with the formatters, and date_range) that allow sitebuilders to control the time zone used to interpret input.
• Add a new (optional) property to the date field (and date_range) that stores the preferred time zone.
• Create thorough tests to verify that all this arcane time zone handling is working correctly everywhere.

Remaining tasks

• Add tests for the widget and formatter settings forms
• Extend tests to cover date range
• Extend tests for the full range of formatters and widgets
• Debug the date_range formatter
• Various minor cleanups, debugging and testing per #105.
• Upgrade path tests
• Finish/reroll the datetime element once #2799987: Datetime and Datelist element's timezone handling is fragile, buggy and wrongly documented gets fixed

User interface changes

A timezone handling configuration drop down on field storage configuration, and if configured for per-date storage, a timezone selector on the date widget.

API changes

• The datetime form element will have an optional #expose_timezone boolean, that if TRUE, will add a timezone selector to the element.
• Date time widgets and formatters will have various new methods. Possibly getDefaultValue() should be public.
  

  Data model changes

  Datetime storage will store a timezone per date.

  Screenshots

Problem/Motivation

Issue #2554321: Clean up Migrate's test suite introduces helper methods in MigrateDrupal6TestBase, that allow to perform bundled migrations in tests, such as migrateUsers(), migrateContentTypes(), migrateFields(), ...

Proposed Resolution

Add D7 variants of these helper methods to MigrateDrupal7TestBase