Problem/Motivation

Pretty much all of the other issues that are asking for OO hook implementations all run into the same problem: we have an unsettlingly large number of places throughout core that build a function name and then call it with some arguments, rather than calling ModuleHandler->invoke() or ModuleHandler->invokeAll().

This actively prevents implementation of a contrib module that, as an example, extends ModuleHandler and emits events when hooks are invoked. Pretty much anywhere where ModuleHandlerInterface->getImplementations() is used outside of ModuleHandler, there's likely a function name being constructed, and in the vast majority of these cases, it's unnecessary.

Proposed resolution

• Introduce two new hook invocation methods that take an additional callable (often, but not limited to, closures) that takes care of calling each individual hook implementation. Code currently calling ModuleHandlerInterface::getImplementations() to invoke hooks themselves can use custom callables to customize their hook invocations. This is useful to pass on extra parameters or process return values.
• Mark ModuleHandlerInterface::getImplementations() deprecated, to encourage developers to use the (new) ::invoke*() methods instead.

Remaining tasks

Convert all remaining calls to ModuleHandlerInterface::getImplementations() that do not cause test failures. If that's because of a lack of coverage, decide what to do about that.

User interface changes

None.

API changes

None. Existing APIs are merely extended. ModuleHandlerInterface is extended, which is not considered a break (@catch in #29)

Data model changes

None.

On a website we enabled recently workflows and content moderation modules. At first we thought it was working great but we discovered that after editing a page it was impossible to edit the translation. This is the error shown in the log:

InvalidArgumentException: The state '' does not exist in workflow. in Drupal\workflows\Plugin\WorkflowTypeBase->getState() (line 155 of /home/dm166/www/core/modules/workflows/src/Plugin/WorkflowTypeBase.php).

I've found a relatively similar issue but even after updating to latest version and also on a fresh install from simplytest.me the bug is still present. Here is the similar issue: https://www.drupal.org/project/drupal/issues/2915398

Here are the steps to reproduce the issue:

1. Enable i18n modules (content translation, interface translation, language)
2. Add a language in admin/config/regional/language
3. Add the language switcher block in admin/structure/block
4. Enable page translation in admin/config/regional/content-language
5. Create a page in English and translate it
6. Enable the workflows and content moderation modules
7. Enable editorial workflow for “basic page” content type in admin/config/workflow/workflows/manage/editorial
8. Now you can edit the previous page in English, but after that if you try to edit the translated one you will have the error (preventing the edit page to be displayed)

I've made the priority major but I'm hesitating with critical since content in translated language can't be edited. The only "workaround" I've found is editing the code temporarily so that instead of throwing an error it set the state to "published".

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.

From #2157945-72: Convert format_size() to a class:

Problem/Motivation

this code

  $default_max_size = format_size(file_upload_max_size());
  $form['max_size'] = [
    '#type' => 'textfield',
    '#default_value' => $image_upload['max_size'],
    '#title' => t('Maximum file size'),
    '#description' => t('If this is left empty, then the file size will be limited by the PHP maximum upload size of @size.', ['@size' => $default_max_size]),
    '#maxlength' => 20,
    '#size' => 10,
    '#placeholder' => $default_max_size,
    '#states' => $show_if_image_uploads_enabled,
  ];

Is wrong. Because you need to enter a valid PHP file size so it shouldn't be translated.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

format_size() is still a procedural function, while it can be turned into a static method in an utility class.

Proposed resolution

• Add a ::toUnitAndSizesize calculation method to the \Component\Utility\Bytes class.
• Convert format_size() to OO code, using the new method provided in \Component\Utility\Bytes::toUnitAndSize class.
• Add related PHP unit tests.

Remaining tasks

• reviews

User interface changes

none

API changes

• Add a Bytes::toUnitAndSize() method to return separately a unit of measurement and the size expressed in the unit of measurement, given a byte quantity.
• Add a Bytes class in \Drupal\Core\Utility, extending from \Drupal\Component\Utility\Bytes, with a toTranslatableString method where we call Bytes::toUnitAndSize() and format the size string.
• Refactor format_size() to use Bytes::toTranslatableString().
• format_size() is deprecated.

Problem/Motivation

The error message returned upon a non existing config entity does not include entity type.
example:
A non-existent config entity name returned by FieldStorageConfigInterface::getBundles(): field name: field_reference_number, bundle: test_field_1

In order to make debugging easier we could improve the error message by adding the entity type to it.

Proposed resolution

Use $entity_type that already exist in the method to improve error message.
Path to file: views/views.views.inc line 378

Remaining tasks

Create patch

User interface changes

Non

API changes

Non

Data model changes

Non

Is there a reason hook_field_update doesn't update the taxonomy index for unpublished entities? I have a use case where editors can manipulate the taxonomy terms of unpublished nodes but these updates aren't inserted into the taxonomy index table. This makes it a challenge to create a view that searches unpublished nodes by taxonomy term name (as opposed to tid, which can be search by taxonomy_field_name_instance)

This would be trivial to patch as it is just an if statement in line 501 of field.api.php.

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/Motivation

Follow up to #2949964: Add an EntityOwnerTrait to standardize the base field needed by EntityOwnerInterface.

Because of a bug in our test coverage, the Comment entity requires that the default owner is the anonymous user for the tests to pass. In order to provide better API and REST support for automatically associating the logged in user with created comments, we should ensure new comments are owned by the logged in user by default.

Proposed resolution

Delete getDefaultEntityOwner, which requires no deprecation because it was introduced at the start of the 8.7.x cycle and has never made it into a stable release.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Currently, the 'get' process plugin is the only place that contains the logic needed to process row keys by unescaping '@' and determining if the key represents a source or destination property. As such, any process plugin that might take in a row key as a configuration value must instantiate a copy of the get plugin to determine the value.

Proposed resolution

Currently Row has a getSourceProperty method and a getDestinationProperty method. Lets add a generic get method which performs the same logic as the plugin, and implement the magic __get method as well to access a property and have the Row object determine if it is a source or destination property and return the correct one.

Remaining tasks

Add a get, getMultiple, and __get method to the Row Class
Write Tests

User interface changes

None

API changes

Add \Drupal\migrate\Row::get($property)
Add \Drupal\migrate\Row::getMultiple($properties)
Add \Drupal\migrate\Row::__get($property)

Data model changes

None

Hello,
Clearing the caches in Drupal is something that needs to be done for different purposes and not always is an administrator task.

Right now there is no specific permission for "flush" the caches, so many modules rely on "administer site configuration" permission.

I think it could be useful to have an specific permission "clear caches" where other modules can rely on.

Problem/Motivation

In the discussion of #2997960: Missing taxonomy hierarchy items in 8.6.0 after running taxonomy_update_8502, it seems that some site maintainers applied the update function after updating to Drupal 8.6.0, then applied it again when 8.6.1 was released. The first update added a table, and the second update threw an exception when it tried to create a table that was already there.

One suggestion was to add a truncate to the update function. This would solve the immediate problem for some users, allowing the update function to complete.

@plach noted that adding the truncate could hide other problems and that the best practice is to start from a database that has not had any failed update attempts.

Proposed resolution

If an update function creates a database table, then it should fail gracefully, with a useful error message, if that table already exists.

Add a helper function so that update functions can do this consistently and conveniently.

Remaining tasks

User interface changes

This will add a warning message, presented to users during updates when update functions attempt to create tables that already exist.

API changes

Add a new helper function available to update functions.

Data model changes

None

Problem/Motivation

Currently it's only possible to delete a file entity by the owner of an file entity. There is no additional condition defined for any permission or even an exception for user/1 (main admin user).

Proposed resolution

• Add existing or new permission to delete file entities.
• And maybe define an exception for user/1 to delete file entities like other entities.

Remaining tasks

User interface changes

API changes

Data model changes

Original Issue summary:

I've faced with problem when user with id '1' (main admin user) can't delete file entities created by another user. I used view_bulk_operations for deleting file entities. I thought user 1 has absolute access to all entities.

Hi,

This looks totally awesome.
To improve the user experience, is it planned (if it even makes sense) to display a discreet spinner / loader image by default for all the blocks loaded after the first flush?

Thanks

Related reading

1. http://www.callumhart.com/blog/non-blocking-uis-with-interface-previews
2. http://www.callumhart.com/demo/building-interface-previews-with-react
3. https://calendar.perfplanet.com/2016/progressive-storyboards/
4. https://github.com/egoist/vue-content-loader

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.

There are several occasions where you should not be using certain systems, yet Drupal does not stop you from doing so. Examples are trying to use the entity storage in DB updates (instead of post updates) or, more exotically, trying to access the router from within entity type builders.

A really good example of how messed up and obscure these problems can become can be found here: #2651974-44: field_ui_entity_operation() cannot respect route parameters because of incorrectly named routes It basically shows that if you try to access route information from hook_entity_type_alter(), Drupal will go into an endless loop but only if you have Views enabled (because its route subscriber requests entity type info).

I've discussed the above problem with tstoeckler and he explained that we should assume that the entity system is of a lower level than the routing system, so theoretically you should only be able to access entity type information while building routes, but not the other way around.

So can we please prevent developers from shooting themselves in the foot unknowingly by throwing a fatal error when you try and access something you shouldn't? I'm thinking $entity->save() in database updates, building the router while building entity types, etc.

Having a central system in perhaps the container to prevent all of this would be awesome.

hi there,

while uninstalling themes during a config import (drush cim) I get the error message:
"The base theme $key cannot be uninstalled, because theme $sub_key depends on it."

but in the same config import I would also uninstall the sub theme.

on config import all the uninstalled themes should be in the same uninstall call, so that the test about
"Base themes cannot be uninstalled if sub themes are installed, and if they are not uninstalled at the same time." is possible.

/core/lib/Drupal/Core/Extension/ThemeInstaller.php Line 232:

      // Base themes cannot be uninstalled if sub themes are installed, and if
      // they are not uninstalled at the same time.
      // @todo https://www.drupal.org/node/474684 and
      //   https://www.drupal.org/node/1297856 themes should leverage the module
      //   dependency system.
      if (!empty($list[$key]->sub_themes)) {
        foreach ($list[$key]->sub_themes as $sub_key => $sub_label) {
          if (isset($list[$sub_key]) && !in_array($sub_key, $theme_list, TRUE)) {
            throw new \InvalidArgumentException("The base theme $key cannot be uninstalled, because theme $sub_key depends on it.");
          }
        }
      }

as a temporary solution I replaced

            throw new \InvalidArgumentException("The base theme $key cannot be uninstalled, because theme $sub_key depends on it.");

with a recursive call

            $this->uninstall([$sub_key]);

thx for your ideas, feedbacks or long term fixes ;-)
cheers iwan

PS: I don't think, that this problem is covered with https://www.drupal.org/node/474684

There is a strange behavoir with the _form_alter hook if the form is located inside an block. The form attributes are set on the block instead of the form element.

We had this issue with the search api pages block and now again with an views exposed filter block.

Steps to reproduce (fresh Drupal 8 installation):

1. Create a view
2. Add some fields and filters which are exposed to the user
3. Under "Advanced" choose Exposed form in block > Yes
4. Save the view and add the block
5. See the markup, for example the "views-exposed-form" class is set on the block instead of the form. If you switch the view setting Exposed form in block to NO, its correctly printed out as form class

Unable to change non-translatable field value on translatable content with content moderation enabled, because of EntityUntranslatableFieldsConstraintValidator::validate

To reproduce:
1) Install D8.5.0 with the standard profile in EN language.
2) Enable content moderation on Article node type.
3) Enable 'Content Translation' (with dependent Language) module.
3) Add another language.
4) Enable translation of Article content type at Configuration --> Content language and translation, set all fields translatable, except Tags.
5) On manage fields, disable 'Users may translate this field' for Tags field.
6) Add new Article node, with e.g. 'Test' tag and publish content.
7) Create new draft on the created node and change Tags field - e.g. delete 'Test' tag, or add another one.

You wouldn't be able to save the node because of validation error:
Non-translatable fields can only be changed when updating the current revision.

Solutions:
a) the EntityUntranslatableFieldsConstraintValidator::validate() should check if the content isModeratedEntity() or
b) content moderation module should extend EntityUntranslatableFieldsConstraintValidator::validate()

Problem/Motivation

#2866779: Add a way to trigger_error() for deprecated hooks added ways to mark hooks deprecated by introducing new API methods. This means we needed one new API method for every method hooks can be invoked, adding three new methods for one small purpose, as well as putting the deprecation burden not on the hook owner, but the owner of every single invocation of deprecated hooks, and while we tend to wrap hook invocations in their own API methods, invoking hooks without API wrappers used to be common practice for a long time.

Proposed resolution

We can deprecate these three ::*Deprecated() methods and put the burden of deprecation solely with hook owners by marking hooks deprecated in hook_hook_info() implementations:
Before Drupal 8.7:

\Drupal::moduleHandler()->invokeDeprecated('foo_bar');

Drupal 8.7:

function foo_hook_info() {
return [
  'foo_bar' => [
    'deprecated' => 'hook_foobar() has been deprecated since Drupal 8.7. Use hook_foo_baz() instead. See https://drupal.org/node/foo_bar',
  ],
]
}

ModuleHandler::getImplementations() will trigger errors for any implementations of deprecated hooks.

Remaining tasks

• Deprecate the change record for the original change and document this new deprecation flag.
• Convert all usages of the three deprecated methods in Drupal core.

User interface changes

None.

API changes

ModuleHandlerInterface::*Deprecated() will become deprecated.

Data model changes

One optional addition to hook_hook_info()'s return value.