Bug description

We've met a buggy behaviour of a view having two reference-field filters in an OR subgroup.

That's how filters looked like:

And this is the resulting query:

There are two issues:
1. AND operator is used instead of OR one.
2. Even if OR operator would be used, INNER join breaks the OR logic. (The fix for this is being handled separately in #1766338: Incorrect filter group OR behavior, LEFT JOIN changed to INNER JOIN)

STR

1. Create new Drupal 8 installation with a Standard profile.
2. Export configuration.
3. Copy/replace files from attached configuration-parts.tgz.
4. Import/synchronize the configuration.
5. At admin/structure/views/settings enable the "Show the SQL query" option.
6. Visit admin/structure/views/view/many_to_one_test and see the resulting query.

Remaining tasks

- decide if we want to somehow determine when the INNER join can be used

A user must select a label and machine name for all new fields during the first of attaching the field to an entity. By default, the machine name is generated automatically based on the input of the label. However, there exists a UX issue whereby typing the label and hitting save too quickly may result in an incomplete machine name being generated. The problem seems to amplified on environments with less resources, such as local envs or shared hosts. To reproduce, consider the following:

Add a new field of any type to any entity. Type any name for the field label (although the longer the name, the more potential for problems) and quickly click "Save and Continue". The expected machine name for a label like user integration id would be field_user_integration_id, but the issue described might result in the machine name actually being set to something like field_user_integrat or field_user_integration.

This issue is also present when updating the label prior to submitting the form. Let's say you had a typo in your label. You meant for it to be Featured Article, but you accidentally type Featrued Article. Fixing the label and submitting the form too quickly may result in a label of Featured Article and machine name of field_featrued_article.

It may also be an issue when copy/pasting a value into the label field either as a fresh value, as in case 1 above, or as a replacement to an existing value, as in case 2.

Is there some way to block/delay submission of the form while that machine name is being generated? I haven't dug into the code at all, but I'd assume there's an ajax callback associated with the machine name generation that might be able to act on the related entity form.

Setting status to Major as due to "Cause user input to be lost, but do not delete or corrupt existing data."

After updating to 8.7.9 I can no longer access the pages that shows all the views.

When going to /admin/structure/views it shows The website encountered an unexpected error. Please try again later.

Also getting this error message. Not sure if they are related: Plugin ID 'page_1' was not found.

This all started after updating. I am reading that this could be due to a deleted view that had an attachment. Not sure though.

And in the log I have this message:
Error: Call to a member function getPluginDefinition() on null in Drupal\views_ui\ViewListBuilder->getDisplaysList() (line 260 of /home/***/public_html/core/modules/views_ui/src/ViewListBuilder.php) #0 /home/***/public_html/core/modules/views_ui/src/ViewListBuilder.php(109): Drupal\views_ui\ViewListBuilder->getDisplaysList(Object(Drupal\views\Entity\View)) #1 /home/***/public_html/core/modules/views_ui/src/ViewListBuilder.php(235): Drupal\views_ui\ViewListBuilder->buildRow(Object(Drupal\views\Entity\View)) #2 /home/***/public_html/core/lib/Drupal/Core/Entity/Controller/EntityListController.php(23): Drupal\views_ui\ViewListBuilder->render() #3 [internal function]: Drupal\Core\Entity\Controller\EntityListController->listing('view') #4 /home/***/public_html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #5 /home/***/public_html/core/lib/Drupal/Core/Render/Renderer.php(582): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #6 /home/***/public_html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #7 /home/***/public_html/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #8 /home/***/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #9 /home/***/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #10 /home/***/public_html/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #11 /home/***/public_html/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #12 /home/***/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #13 /home/***/public_html/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /home/***/public_html/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /home/***/public_html/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /home/***/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /home/***/public_html/core/lib/Drupal/Core/DrupalKernel.php(693): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 /home/***/public_html/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #19 {main}.

Problem/Motivation

Pretty much like before 8.0.x in #2139921: Contextual links can't handle multiple occurrences of the same contextual links, contextual module does not support multiple contextual blocks with the same parameters, although it manifests a bit differently.

When the same content appears more than once on the same page, that content naturally has the same contextual links (specifically, exactly the same contextual links placeholder, e.g. <div data-contextual-id="foo:"></div>). Each contextual link should work correctly and act independently, of course.

However, that is not what happens. In the current codebase, when clicking one contextual link (by clicking on the pencil icon), it does not open. As observed in the chrome devtools, both links receive the event (flashes in the inspector), but none displays.

Steps to reproduce

• Create a render array in a controller
• Add a #contextual_links element, pointing to some section with appropriate parameters
• Add a child element within the top-level render array
• Within that element, add a similar #contextual_links element, with the same parameters

Go to the page for that controller. The same contextual link now appears twice: once in the main content area, once in the other element further down. Click either contextual link. No contextual link menus will be opened.

Workaround

Add an unused extra route_parameter, with a different value in each element like ['instance' => 1] in the first one, ['instance' => 2] in the second one. The blocks will now work normally, and the links will only carry the extra unused parameter in the query.

This is pretty much how multiple pagers work.

Proposed resolution

Either:

• Fix this.
• Or document the workaround

Problem/Motivation

When getting config from TypedConfigManager, i expected to get overridden config. Results and source code show that overrides are not applied.

\Drupal\Core\Config\TypedConfigManager::get

  public function get($name) {
    $data = $this->configStorage->read($name);
    return $this->createFromNameAndData($name, $data);
  }

Proposed resolution

Fix this.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

See this one for example: https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...

Problem/Motivation

Umami comes with a new language switcher.
When adding more languages (beyond the existing English and Spanish) it will break the nice flow of the header.

Proposed resolution

Add the list of available languages into a dropdown menu.

Remaining tasks

Create dropdown menu.
Figure out best positioning and a visual representation that will be easy to identify as "Here's where I can switch to another language"

GitHub has recently started to make use of SECURITY.md files if present in the repository root. Many open source projects have since stared to have a SECURITY.md file explaining how to report security vulnerabilities properly.

Just a moments ago, we got WordPress to commit their SECURITY.md file, and I would like to propose that we use a SECURITY.md file as well.

This file can explain the procedures we have security.drupal.org, how to report a Drupal core vulnerability, how it works for core, security coverage, and a lot of other information that will surely make it easier for security researchers and end users alike.

Thank you.

UrlHelper::parse does not support external URLs with more than one question mark. At the moment some parts of the URL gets stripped of in case there are more than one question mark which is not properly encoded. Thus we do not consider the URL as invalid, so we must return the fully constructed and properly encoded URL when this is the case.

Example of problematic URL :
http://ville.montreal.qc.ca/portal/page?_pageid=3619,4034073&_dad=portal&_schema=PORTAL&params_recherche=http://ville.montreal.qc.ca/sel/sypre-consultation/recherchereglement?params=type_regl=999**critere=pesticides**source=**type_recherche=0**total=0**crement=10**start_pos=1**acces=0**langue=fr**instances=901**expression=pesticides**etendue=titre**statut=1**no_reglement=04-041**no_regl_cond=**applic_territ=0**bro_orderdate=2016-02-01**bro_endorderdate=2016-02-01**utilisateur=&has_been_there=1

When passed through UrlHelper::parse it returns :
http://ville.montreal.qc.ca/portal/page?_pageid=3619,4034073&_dad=portal&_schema=PORTAL&params_recherche=http://ville.montreal.qc.ca/sel/sypre-consultation/recherchereglement

The fix is very simple, we just need to explode the URI considering the first question mark.
Patch attached.

Problem/Motivation

Twig 3 is here
https://github.com/twigphp/Twig/releases/tag/v3.0.0

Proposed resolution

Update Drupal 9 to Twig 3.

Remaining tasks

Discuss. Patch. Commit.

User interface changes

None.

Problem/Motivation

When you adjust a views display's machine name to match its plugin id (e.g. have a page display named page), attachments will no longer be displayed with this view. This is clearly not intended behavior.

One way to reproduce:

1. Create a view with 2 page displays, change the machine name of the second display from page_2 to page in the advanced settings.
2. After saving, add an attachment display to both pages.
3. Navigate to the url of the first display. The attachment is shown.
4. Navigate to the url of the second display. The attachment is not shown.

Proposed resolution

The culprit here is DisplayPluginBase::acceptAttachments(). The comparison of $this->definition['id'] == $this->view->current_display compares a display name with a plugin id, which causes this unintended behavior.
The intention of the code probably was to check the display name of the attachment against that of the display being rendered, as the comment above the check states. However, the method documentation states that it "Determines whether this display can use attachments.", so this check should not even be made here, and we do not have any information about which displays would be attached anyway.
Therefore, I think the check can be removed completely, especially since it always returns FALSE when using default display machine names like page_1.
Aditionally, the views UI does not allow a user to attach an attachment to another attachment anyway, let alone itself.

For now, a workaround would be to rename the display in question in order to have attachments show up again (Don't forget to check the "attach to" setting of you attachment after renaming the display machine name).

Remaining tasks

We should probably add a test that catches this bug in the current version to prevent regression.

Trying to migrate from Drupal 6 to Drupal 8. Running migration through UI.

• Source site runs Pressflow 6.44 LTS
• Destination site runs Drupal 8.5.6
• Source and destination sites are set to a PHP memory limit of 512M
• Source site has currently 123,598 nodes

• Server is a Xeon D-1520 with 2.2/2.7 GHz and 4/8t, 64 GB RAM
• Operating system is Debian 8

The expected behaviour is that the migration system manages to migrate a Drupal 6 site within a reasonable timeframe, let's say max. 1-2 days. Also I'm expecting usable progress indications in the UI. If the migration systemm has not dies, I expect to be able to see any kind of progress.

The experienced behaviour is that migration simply takes too long or does not work at all. I'm getting a progress status with "33%" which does not change for the past three days (!). According to the output at ./batch?id=13&op=start, it is processing URL aliases and has processed "63 of a total of 188 tasks". Like the statement in %, the tasks feedback has not change withing the past three days. Altogether, this migration is running for ~5 days.

This is an undesirable behaviour. At least every couple of hours something visible needs to indicate if migration is still in progress. If migration does not progress by 1% within a couple of hours, another UI feedback is required, be it 0.1% steps or a progress indication for a subroutine (33% of the whole migration … 78% of migration script foo). If I'm looking for three days at 33% progress, the currently implemented feedback indicator is simply useless or broken.

It's not that migration had completely died; according to the 'mytop' utility, the database server gets a SQL query every 1-2 minutes. This has slowed down significantly within the past days. At the beginning, the databse server was continously running SQL queries on the destination database. I believe this to be another bug as the migration subsystem seems not to be able to process any site with more than a couple of thousend nodes respectively taxonomy terms. It simply does not scale.

The steps required to reproduce the bug(s) are relatively simple - just try to migrate a medium-sized Drupal site (medium sized == number of nodes and/or taxonomy terms > 100,000; a large site would be something like d.o with content of several 100k). You can generate dummy content with devel, if you do not have access to medium to large Drupal sites in the wild. If someone bothers trying to reproduce, you will notice that with increasing amount of content all migrations procedures slow down to a crawl.

I have attempted a couple of migration attempts mit various real-world medium-sized sites, and without exception ran into dead ends like this. It's not a fixed failure at exactly 33% or at "63 of a total of 188 tasks" or at URL alias processing, but migration simply never finishes.

As a side note, I am aware that there is the (theoretical) alternative to run migrations through drush. I have tried this, too, but it also fails (different issue, but it does not work at all, especially it does not work to process separate migrations scripts as described in the docs).

A major thorn in the side of anyone who is upgrading to D8 is how slow the Migrate system is. Sites that would take half an hour to an hour to run all scripts to upgrade a site from D6 to D7 are looking at possibly days to migrate to D8.

Lets examine the system and see what could be improved.

I am currently looking for different performance bottlenecks in the Drupal admin pages using xdebug, and found one more thing that could be optimized.

In theme.inc, function _theme_process_registry, called a lot of times by _theme_build_registry, I count around 80.000 calls to function_exists() looking for hook implementations with '_preprocess_' in the name, while there are only around 2.000 functions defined (using get_defined_functions). It's not a big deal, but it adds up to overall execution time (around 150ms on my machine) for those requests which rebuild the theme registry.

I imagine we could improve this (and maybe other hook scans as well) with the following approach (pseudo-php) inside _theme_build_registry:

<?php
$implementations_by_prefix = array();
$implementations_by_hook = array();
$candidates = get_defined_functions();
foreach ($candidates as $candidate) {
  $explode = explode('_preprocess_', $candidate);
  if (count($explode) == 2) {
    list($prefix, $hook) = $explode;
    $implementations_by_hook[$hook][] = $candidate;
    $implementations_by_prefix[$prefix][] = $candidate;
  } else if (count($explode) > 2) {
    // TODO: kill the author of this function..
  }
}
// TODO: do something with the functions found this way..
?>

This is not yet thought through to the end, but maybe it could be a useful approach?

Hi,

As requested by Fabianx on IRC and on the related issue #1545964: Do not copy over the owner and engine of a theme if the child theme uses a different engine than the base theme, here's a patch for Drupal 8 that adds some tests for testing themes and subthemes engine inheritance.

Patch will follow.

Hello,

Autocomplete forms fields when multiple do not fit their parent container causing ovelapping elements.
A simple css line fix the issue in /stable/css/system/components/autocomplete-loading.module.css on line 8 by adding width: 100%.

.js input.form-autocomplete {
background-image: url(../../../images/core/throbber-inactive.png);
background-position: 100% center; /* LTR */
background-repeat: no-repeat;
width: 100%;
}

Thanks !

Problem/Motivation

When updating from 8.6.x to 8.7 the following error (or similar) may occur:

[error]  Exception thrown while performing a schema update. Cannot rename tmp_a207a5menu_link_content_revision to menu_link_content_revision: table menu_link_content_revision already exists.

This normally occurs when attempting to run the DB update a second time, after that a previous attempt failed with a different error.

There are a couple of people reporting that the issue happens on fresh a DB where the update was never attempted (see #77 see and #86), but the root/original error was not reported yet.

Here's a list of issues that may cause the first error:

• #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved
• #3006815: ViewsEntitySchemaSubscriber may fail when a view has a broken handler

Proposed resolution

There is no proposed solution yet, since the focus so far has been to fix the initial error(s) in dedicated issues, for instance #3052492: ViewsEntitySchemaSubscriber should not make an entity update fail if a view cannot be resaved. The problem is that many different problems can result in a failed update, which on a second attempt would lead to the reported error. This issue will focus on finding a fix for bugs triggering the reported errors on the first run, while separate issues will be created to address bugs triggering the reported errors on the second run.

The current working hypothesis to explain the error occurring on the first attempt is that for some reason the update is run on a DB where the menu link content (and/or taxonomy term) entity type was already converted to revisionable, possibly via drush entup. A patch was posted to address this issue (latest version at #83).

However in most cases it seems people are experiencing this error as a consequence of a previously failed update. The workaround in this case is to remove the revision tables created by the update (see #39), in fact just restoring a fresh DB dump may not be enough (see #29).

It is also possible that a similar error occurs with the taxonomy_term entity type, see #81. It is very important to make sure that the update actually failed before dropping tables, otherwise this could result in a broken database, see for instance #60. In that case the menu_link_content had likely completed successfully.

Please note that a successful update will not remove backup tables (tables prefixed by old_) unless the system is specifically configured to do so, see https://www.drupal.org/node/3046576.

Remaining tasks

• Confirm that the error can occur also on the first run and track down the root cause.
• Write a patch
• Reviews

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

TBD

There is a typo in a form element of the AssignOwnerNode action.

An extra "t" in #selection_setttings of the autocomplete field.

Introduced this commit.

Attached patch fix it.

Problem/Motivation

Support of if condition in for tag was deprecated in Twig 2 and removed in Twig 3.

Proposed resolution

Update core templates.

Remaining tasks

Discuss. Patch. Commit.

User interface changes

None.

Problem/Motivation

spaceless tag has been removed in Twig 3

Proposed resolution

Use spaceless filter instead.
https://twig.symfony.com/doc/3.x/filters/spaceless.html

Remaining tasks

Create a patch.

User interface changes

None.