Problem/Motivation

There are several cases when Drupal can get "2002 Connection refused" error:

1. The 'unix_socket' option is set in settings.php and the socket is not accessible.
SQLSTATE[HY000] [2002] No such file or directory

2. The 'host' option is empty or set to 'localhost', which means to use default Unix socket, but socket is not accessible.
SQLSTATE[HY000] [2002] No such file or directory

3. There is an issue with accessing the server via TCP/IP:
3.1. Host name could not be resolved:
SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo failed: Name does not resolve

3.2. Host is not accessible.

3.3. Host is accessible, but connection on specified port refused:
SQLSTATE[HY000] [2002] Connection refused

3.4. I'm sure there are more cases.

Sometimes it takes significant time to discover the root cause of the error (especially for unexperienced developers). It would be great if Drupal provided more informative messages for MySQL error 2002. Perhaps with some tips how to resolve the issue.

Proposed resolution

The proposal is to introduce special exception class for MySQL 2002 error and provide additional information in error message.

Remaining tasks

Perhaps there will be a follow-up issues for pgsql and sqlite.

It's super frustrating when you want to have a text field (255chars) but the only way to see the entire 255 chars in that field is a really really reeeeally long textfield. Text areas are a thing. We should be able to use them (and not just for longtext text fields).

in Drupal 7, to use a textarea you need to create a whole new field and migrate all your data into it, but the underlying data structure is exactly the same!! This should not be necessary. Let's add the textarea widget as an option for text fields (but leave the existing widget as default)

Problem/Motivation

Over many years Drupal has held off checking queries for reserved words in column names, table names and aliases because it was a design decision. The idea is that we just just should not use reserved words. However, time has made it clear that this position (as stated in the long discussions in #371: resolve ANSI SQL-92/99/2003 reserved words conflict in query statements) is not really tenable. Here are the problems:

• The list of reserved words is different for different database drivers even those the support the various ANSI SQL standards. For example OFFSET is reserved in PostgreSQL but not in MySQL
• Database drivers add new reserved keywords in new versions. MySQL has been doing this in every new version for example 5.7 and 8

Proposed resolution

• Add a new syntax square bracket syntax to the query builder to know what identifiers (column names/ aliases) are. Leverage work in #371: resolve ANSI SQL-92/99/2003 reserved words conflict in query statements suggested using [COLUMN_NAME] to match {TABLE_NAME}. This supports db_query(), addExpression() and addWhere()
• Automatically quote fields and aliases in escapeField() and escapeAlias().
• All identifiers should be quoted. This helps us ensure that the database API is properly used when query building and will make edge-cases less likely.

Using [] to identify identifiers (field names / aliases)

There is precedence - this is the quote character in MSSQL.

The one consideration is that :variable[] is used to identify and expand array variables.

Discarded resolution(s)

We could deprecate SELECT, UPDATE, INSERT queries via \Drupal\Core\Database\Connection::query() since the methods like \Drupal\Core\Database\Connection::select() require fields to be specified. If we do that we have to worry about performance - see #1067802: Compare db_query() and db_select() performance. Also this does not work for columns added using ->addExpression() or ->addWhere(). Therefore this resolution has been discarded.

Remaining tasks

Fix the blockers:

• #2986334: Add a way to enforce an empty result set for a database condition query
• #2986539: \Drupal\user\Plugin\EntityReferenceSelection\UserSelection::entityQueryAlter() should escape the fake condition column on replacement

File follow-ups:

• add coder rule to try to check for missing []
• Ensure core uses new square bracket syntax

User interface changes

None

API changes

At the moment \Drupal\Core\Database\Connection::escapeField() and \Drupal\Core\Database\Connection::escapeAlias() in their core implementations are re-entrant. And some core code relies on this. That said the docs hint that this should not be case. In the new implementation methods also now quote identifiers BUT because the code removes the quotes before adding them they still are re-entrant. The new implementations result in strings like users_data.uid becoming "users_data"."uid".

\Drupal\Core\Database\Query\ConditionInterface::condition()'s first argument $field must be a field and cannot be (ab)used to do ->condition('1 <> 1'). The way to do this is to use the new API added by #2986334: Add a way to enforce an empty result set for a database condition query

\Drupal\Core\Database\Connection::prepareQuery() now takes additionally takes a boolean that is derived from a query's $options['allow_square_brackets'] value that allows specific queries to use square brackets and to not them for identifier quotes. The default value for $options['allow_square_brackets'] is FALSE.

\Drupal\Core\Database\Connection::prefixTables now quotes tables so {node} becomes "node".

Data model changes

None

Release notes snippet

All identifiers (table names, database names, field names and aliases) are quoted in database queries. Column names or aliases should be wrapped in square brackets when using Connection::query(), db_query(), ConditionInterface::where() or SelectInterface::addExpression. Custom or contrib database drivers should read https://www.drupal.org/node/2986894 to see what changes are necessary.

After upgrading Drupal from version 7.67 to 7.68 it started to show a plenty of the messages below. I am currently using PHP 7.3.9-1.
At https://www.drupal.org/project/drupal/releases/7.68 we have "This is the first release to fully support PHP 7.3. Please test and report any bugs in the issue queue.". So I am reporting this and expecting some help.

Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in require_once() (line 915 of /var/www/website/sites/all/modules/libraries/libraries.module).
Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in include_once() (line 24 of /var/www/website/sites/all/modules/webform2pdf/webform2pdf.install).

Notice: Undefined property: stdClass::$uri in theme_file_link() (line 783 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$uri in theme_file_link() (line 803 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_icon() (line 849 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 893 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_map() (line 936 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filesize in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filename in theme_file_link() (line 821 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$uri in theme_file_link() (line 783 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$uri in theme_file_link() (line 803 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_icon() (line 849 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 893 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_map() (line 936 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in file_icon_path() (line 908 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filemime in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filesize in theme_file_link() (line 815 of /var/www/website/modules/file/file.module).
Notice: Undefined property: stdClass::$filename in theme_file_link() (line 821 of /var/www/website/modules/file/file.module).

Thanks in advance.

Apologize for my poor English.
While I debugging slow queries on my Drupal 7.12 site, I found a query in locale module is very slow.
I think the reason is that some modules will filter/sort {locales_target} table by `language` field, however it's not indexed.
Please see this function for example:
http://api.drupal.org/api/drupal/includes%21locale.inc/function/_locale_...

$result = db_query("SELECT s.lid, s.source, s.context, t.translation FROM {locales_source} s INNER JOIN {locales_target} t ON s.lid = t.lid AND t.language = :language WHERE s.location LIKE '%.js%' AND s.textgroup = :textgroup", array(':language' => $language->language, ':textgroup' => 'default'));

so, I just updated to 8.7.8, and the fixed 3021452 issue is persisting for me. I see a title is provided for my example youtube video.

VIDEO: https://www.youtube.com/watch?v=6X8f9CLBoB8

EMBED JSON URL: https://www.youtube.com/oembed?format=json&url=https%3A%2F%2Fwww.youtube...

EMBED JSON:

{
    "provider_url": "https://www.youtube.com/",
    "author_name": "The Four on KTVU",
    "height": 270,
    "thumbnail_height": 360,
    "provider_name": "YouTube",
    "author_url": "https://www.youtube.com/channel/UCHTnUyoYpA4txfWEVoY1Ysg",
    "width": 480,
    "version": "1.0",
    "html": "<iframe width=\"480\" height=\"270\" src=\"https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen></iframe>",
    "thumbnail_width": 480,
    "thumbnail_url": "https://i.ytimg.com/vi/6X8f9CLBoB8/hqdefault.jpg",
    "type": "video",
    "title": "New Sensor Network Reveals Telltale Patterns in Neighborhood Air Quality"
}

GENERATED IFRAME IN RENDERED DRUPAL 8.7.8 PAGE:

<div class="embed-media embed-media--video-youtube">
<iframe src="https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed" allowfullscreen="allowfullscreen" width=" 480" height="270" frameborder="0"></iframe>
</div>

I've even tried deleting the iframe and re-creating it. No luck. The title just doesn't get appended to an attribute in the <iframe> tag.

My CKEditor Media Embed module is configured to use Provider Url: //noembed.com/embed?url={url}&callback={callback}, which does show an iframe without a title, but does include the title data in the json:

GENERATED IFRAME URL: https://noembed.com/embed?url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%...

EMBED JSON:

{
    "html": "\n<iframe width=\" 480\" height=\"270\" src=\"https://www.youtube.com/embed/6X8f9CLBoB8?feature=oembed\" frameborder=\"0\" allowfullscreen=\"allowfullscreen\"></iframe>\n",
    "version": "1.0",
    "height": 270,
    "thumbnail_url": "https://i.ytimg.com/vi/6X8f9CLBoB8/hqdefault.jpg",
    "thumbnail_width": 480,
    "title": "New Sensor Network Reveals Telltale Patterns in Neighborhood Air Quality",
    "author_name": "The Four on KTVU",
    "url": "https://www.youtube.com/watch?v=6X8f9CLBoB8",
    "width": 480,
    "provider_name": "YouTube",
    "thumbnail_height": 360,
    "provider_url": "https://www.youtube.com/",
    "type": "video",
    "author_url": "https://www.youtube.com/channel/UCHTnUyoYpA4txfWEVoY1Ysg"
}

If I am missing something about how the 13282573 fix is supposed to work, can someone please walk me through it?

P.S. My Basic HTML editor has the title attribute enabled for iframes, so I doubt its being filtered out (and wouldn't expect it to be anyways):

P.S.S. For what it is worth, I have also tested using iframe.ly as the source and also am not getting a title in that case.

<iframe src align frameborder height width scrolling type title bgcolor allowtransparency>

First of all great to have the possibility to create and upload new media elements directly in the media field widget.

I came across an issue regarding media image elements. If there is an upload validator specified for image resolution this is not going to be taken into account from the media library field widget. Actually media library field widget does only use upload validation for extensions and file size.

I see that since it is possible to have a media field with multiple media types, it could get difficult to include this upload validation for resolution correctly in such a case that you may have different media types allowed in one field. So maybe it is intentional that the image resolution validator is left out (but I could not find a hint about this actually).

But I feel this is kind of a bug or at least very annoying if you have specified image resolution validation on a media type and this is just not taken into account via the media library field widget. It actually allows to circumvent this restriction.

I provide a patch that will enforce resolution validation if applicable. This is maybe just a start for solving this issue, because it does not handle cases where you might have different image media types with different settings for image resolution. But at least for a single media type this seems to work correctly.

Possibly the best solution would be to have an intermediate dialog in the media upload modal to choose the type of media first (if there are multiple types allowed) and then go to the actual upload form with the validators taken from the media type chosen. But this seems a bit more complicated.

Moreover as far as I could see it is not possible to remove just the "Add media" button from the media library field widget, so to basically allow the creation only via media/add but not via Media library field widget and therefore enforce the restrictions regarding resolution (of course this could be done by form_alter, but not via UI - this is discused here https://www.drupal.org/project/drupal/issues/2993187).

Problem/Motivation

Steps to reproduce:

1. Install Drupal 8.4.2 with the Standard profile
2. Create a text format that doesn't filter by "Limit allowed HTML" - the use case is a "Full" format for dangerous things like iframes or script tags or inline styles. Not advisable, but there is a use case for it for admin users.
3. Create an "Article" node with <div style="color: red">red text</div> followed by less than 600 characters of text
4. Create an "Article" node with <div style="color: red">red text</div> followed by more than 600 characters of text
5. On the node view page for both nodes, the text at the top will be red -- this is expected, because the text filter allows it
6. Go to the /node page - you'll see that one node (the one with less than 600 characters) shows the text in red, but the other (the one with greater than 600 characters) does not

The problem is, when the "Summary or trimmed" or "Trimmed" field formatters do their thing, they first apply the text filter and then text_summary() will either return the same value (if no trimming is necessary) which is already marked as "safe" or will return a trimmed value, which is just a plain string (and so not marked as safe).

Then in \Drupal\Core\Render\Renderer->ensureMarkupIsSafe(), if it's a plain string (and so not marked as safe) it'll additionally run Xss::filter() on the output, which will remove stuff, even if it's allowed by the text format!

Proposed resolution

I'm not sure... This is kind of an edge case, so trying to isolate the changes in the most specific place possible makes sense? That would mean doing it in text_summary() or maybe TextTrimmedFormatter?

Maybe if it's passed text that's already marked as safe, it should return text that's also marked as safe? I can't imagine how trimming safe HTML could become unsafe, but I suppose could be possible with some extreme creativity since it's doing text trim...

Remaining tasks

1. Decide on approach
2. Write tests
3. Implement fix
4. Review

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

The post update workspaces_post_update_move_association_data() makes an entity schema change. It deletes the workspace_association entity.

Generic entity type operations in hook_update_N implementations cannot depend on this update because it's a post update. If they are checking something on all entity types then the workspace_association entity type is completely invalid because neither the storage nor the entity type class exist.

As a whole workspaces_post_update_move_association_data() itself cannot be a hook_update_N because it is saving revisions.

Proposed resolution

Move the entity type deletion to an update hook so updates can depend on it.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

While working on #2757007: Convert all book web tests to BrowserTestBase, I discovered that, in a JavascriptTestBase test, it's impossible to swap 2 rows by dragging the lower over upper row. The reverse works: you can swap them by dragging the upper over the lower row.

This behaviour doesn't occur when testing manually

In order to unblock #2757007: Convert all book web tests to BrowserTestBase, I opened this dedicated issue for investigation but it can be also a starting point for a full draggable table test.

It's possible that this behaviour is caused by:

1. a bug in our tabledrag.js implementation

OR

2. an upstream cause in \Behat\Mink\Element\NodeElement::dragTo()

I will let our JavaScript team to find the cause. I'm only providing here this starting test.

Proposed resolution

1. Find the cause of this bug and fix if it's a Drupal bug or report upstream.
2. Expand the test to cover all draggable table aspects like indenting, other actions test, etc.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

To replicate,

* create users view
* add roles filter (exposed) with "Select all" selected in Options field.
* Export view to module/profile and reinstall website.

The following error would occur
Error: Call to a member function getConfigDependencyKey() on null in Drupal\user\Plugin\views\filter\Roles->calculateDependencies() (line 93 of /docroot/core/modules/user/src/Plugin/views/filter/Roles.php).

While debugging the role_id with the value all is used in Drupal\user\Plugin\views\filter\Roles::calculateDependencies() in the following code

    foreach ((array) $this->value as $role_id) {
      $role = $this->roleStorage->load($role_id);
      $dependencies[$role->getConfigDependencyKey()][] = $role->getConfigDependencyName();
    }

Problem/Motivation

Now that #2807145: [policy, no patch] Allow contrib projects to specify multiple major core branches has been done core_version_requirment can be used to declare core compatibility via Composer semver constraint. It is technically already possible to declare that your module is already compatible with Drupal 9 only. For instance if a module requires one of the newly updated composer dependencies in Drupal 9.

This means that currently the update module could be listing contrib modules that are only compatible with Drupal 9. Previously this would not have been possible.

Once #3009338: [META] Support semantic versioning for extensions (modules, themes, etc) in Drupal core is completed there will no correlation between the module version number and core compatiblity.

Therefore we should display the core compatibility of updates to display this information to the user.

In #3076183: Determine how available updates for modules should be handled if they are not compatible with the current version of Drupal core we determined we want

1. Should a message on all update that display their core compatibility based of the core_version_requirement in info.yml files. This information is now in the update XML from drupal.org as core_compatibility

   The message should be in this format:

   This module is compatible with Drupal core: 8.8.3 to 8.9.1

2. As 2nd step will switch to a update XML feed that is not tied to CORE_COMPATIBILITY but rather all 8.x and future module updates.
   This will be handled in #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

Original all this handled in #3074993 because only the /current feed had core_compatibility
but now this available in the current XML we can handle this first in it's own issue.

Proposed resolution

copied from #3076183: Determine how available updates for modules should be handled if they are not compatible with the current version of Drupal core

1. Done: in #3074998: Add explicit information about core compatibility to update data add a new core_compatiblity value for each update. This is will be based on core_version_requirement or if not available it will be based core: 8.x

   This is will be for the project not individual modules in the project. Details to be determine in that issue

2. Display a message for each available project update that displays the core compatiblity range based on 1) actual available updates the update module has retrieved from the update server and 2) the core_compatiblity for the project update xml(see above)
3. For most common possibilities for core_compatiblity this will be able to displayed as a simple range.

   For example
   Installed core: 8.8.3
   latest 8.x patch release: 8.9.1
   Drupal 9 not released yet
   project xml core_compatiblity: ^8 || ^9

   This module is compatible with Drupal core: 8.8.3 to 8.9.1

   If Drupal 9.0.3 had been released this would change to

   This module is compatible with Drupal core: 8.8.3 to 9.0.3

   if project xml wascore_compatiblity: ^: ^8.8.9 || ^9 (not using core_version_requirement because the value will be directly from the project xml not the info.yml files)
   This module is compatible with Drupal core: 8.8.9 to 9.0.3

4. Some less common values for core_compatiblity will not be able to display by a simple range. In that case we should display them in a series of ranges.

   For example
   Given:
   Installed core: 8.8.3
   latest 8.8.x: 8.8.7
   latest 8.x patch release: 8.9.1
   Drupal 9 not released yet

   core_compatiblity: ~8.8.0 || ^9

   This module is compatible with Drupal core: 8.8.3 to 8.8.7

   Because 9 hasn't been released it won't come into play.

   If Drupal 9.0.3 had been released

   This module is compatible with Drupal core: 8.8.3 to 8.8.7 and 9.0.0 to 9.03

5. In this first step no modules will be filtered out of the list.

   This will mean hypothetically you could get projects updates with the message like

   This module is compatible with Drupal core: 9.0.0 to 9.0.5

   In the near term this is very unlikely because 1) Drupal 9 is not out so no module should be compatible with it but not Drupal 8 and 2) 9.0.0 should be compatible with 8.9.0 for modules not using deprecated code. Therefore any module that is compatible with 9.0.0 because it remove deprecations should also be compatible with 8.9.0. So the project would likely have this in the project xml
   core_compatiblity: ^8.9 || ^9 or core_compatiblity: ^8.8 || ^9

Remaining tasks

Finish patch, review

User interface changes

New messages on available updates list

API changes

none

Data model changes

None

Release notes snippet

TBD

Originally submitted on Github

Problem/Motivation

Recent interviews and research exposed pain points around Drupal's admin experience of looking and feeling dated.

Proposed resolution

Implement new Dialog (and Overlay) styles:

Specs:
https://www.figma.com/file/OqWgzAluHtsOd5uwm1lubFeH/Drupal-Design-system...

Remaining tasks

• Update patch
• Accessibility review
• RTL review (Right to left)

Test Pages

@todo

Problem/Motivation

Sometime i get error / exception backtraces that lack newlines in the dblog html view.

Without patch:

Error: Cannot use object of type Drupal\Core\Render\Markup as array in Drupal\leaflet\LeafletService->leafletProcessGeofield() (line 141 of /var/www/html/web/modules/contrib/leaflet/src/LeafletService.php) #0 /var/www/html/web/modules/contrib/leaflet/leaflet_views/src/Plugin/views/style/LeafletMap.php(441): Drupal\leaflet\LeafletService->leafletProcessGeofield(Array) #1 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2112): Drupal\leaflet_views\Plugin\views\style\LeafletMap->render(Array) #2 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1530): Drupal\views\Plugin\views\display\DisplayPluginBase->render() #3 /var/www/html/web/core/modules/views/src/Plugin/views/display/Page.php(171): Drupal\views\ViewExecutable->render() #4 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1627): Drupal\views\Plugin\views\display\Page->execute() #5 /var/www/html/web/core/modules/views/src/Element/View.php(77): Drupal\views\ViewExecutable->executeDisplay('page_1', Array) #6 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array) #7 

With patch:

Error: Cannot use object of type Drupal\Core\Render\Markup as array in Drupal\leaflet\LeafletService->leafletProcessGeofield() (line 141 of /var/www/html/web/modules/contrib/leaflet/src/LeafletService.php).
#0 /var/www/html/web/modules/contrib/leaflet/leaflet_views/src/Plugin/views/style/LeafletMap.php(441): Drupal\leaflet\LeafletService->leafletProcessGeofield(Array)
#1 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2112): Drupal\leaflet_views\Plugin\views\style\LeafletMap->render(Array)
#2 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1530): Drupal\views\Plugin\views\display\DisplayPluginBase->render()
#3 /var/www/html/web/core/modules/views/src/Plugin/views/display/Page.php(171): Drupal\views\ViewExecutable->render()
#4 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1627): Drupal\views\Plugin\views\display\Page->execute()
#5 /var/www/html/web/core/modules/views/src/Element/View.php(77): Drupal\views\ViewExecutable->executeDisplay('page_1', Array)
#6 [internal function]: Drupal\views\Element\View::preRenderViewElement(Array)
#7 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(378): call_user_func(Array, Array)

Proposed resolution

Add a

 tag to *all* backtraces (one source line already has).


Remaining tasks

Doit.


User interface changes

n/a


API changes

n/a


Data model changes

n/a

Problem/Motivation

API page: https://api.drupal.org/api/drupal/core!modules!system!templates!links.ht...

1. The 'link' element is not documented.
2. The 'url' element is documented, but is not available in the template.
3. It is unclear for developers what the input is for the theme function.

Question for the Theme System / Twig maintainers

We have a case here where there is a preprocessing function that expects certain input from the render array, and then the Twig template expects the processed output of that as its input.

My question is whether in the Twig template we are supposed to document what comes in after preprocessing? In which case, where are we documenting what goes into the render array? This is kind of a generic question, not just for this issue:
- Module developers passing stuff from their module through a given theme hook -- where do they look for docs and what do they expect?
- Theme developers overriding a theme template -- where do they look for docs and what do they expect?

The `d7_taxonomy_term` migration source at `core/modules/taxonomy/src/Plugin/migrate/source/d7/Term.php` produces a query with duplicate `machine_name` fields. This causes MySQL errors.

I have attempted to begin addressing this by aliasing the vocabulary machine name field.

I'll attach a patch once I get this issues #.

Problem/Motivation

The actual password reset mechanism exposes a user enumeration security vulnerability defined as Testing for User Enumeration and Guessable User Account (OWASP-AT-002) by OWASP - Open Web Application Security Project.

When resetting the password, the actual status messages displayed to the user, depending if the user exists and is active, are:

1. The username (or Email) belongs to a valid and active account: Further instructions have been sent to your email address..
2. The username (or Email) belongs to a blocked user: %name is blocked or has not been activated yet.
3. No account exists for that username or Email: %name is not recognized as a username or an email address.

The last 2 cases are helping a potential attacker, that is doing a user enumeration, to restrict the list candidates and identify usernames or user Email addresses that are real active users (as well as blocked users).

Along with the security aspect comes also the privacy side. Think of the following scenario:

Alice wants to check if her fiancé Bob is registered at "adult-dating.example.com", a well known Internet dating site run by Drupal. She visits adult-dating.example.com/user/password and enters his mail address bob@doe-family.example. If she gets the message "Further instructions have been sent to your e-mail address.", she'll know that there is a user registered with Bobs mail address (= Bob himself) or with a username matching his mail address (unlikely that it would be someone else).

Proposed resolution

Always show Further instructions have been sent to your e-mail address.

[to be discussed] Maybe we should change the wording of this message then (adding something like "if matched any account").

Remaining tasks

None.

User interface changes

Same message regardless the user exists, is active or blocked.

[to be discussed] Make the message configurable.

API changes

None.

Data model changes

None.

Problem/Motivation

In a composer managed repository, there is a distinction between any files that are provided by packages and those that are local. A typical repository looks as follows:

htdocs (or: web)
-/modules
--/contrib
--/custom
-/themes
--/contrib
--/custom

Drupal can import localization files provided in a local directory or download them from localize.drupal.org. When the webserver is configured to not make any outgoing requests, you can use a composer plugin to download these for you (https://github.com/drupal-composer/drupal-l10n).

It would be nice to have the locale importer search the translations directory, allowing for this directory structure:

translations
-/contrib
-/custom

Proposed resolution

Search translations directory recursively for localization files, so contributed localization files can be saved in a different directory than custom localization files .

Remaining tasks

Write change record

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Local translations directory can now be organised like modules and theme directories.

Problem/Motivation

As stated in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.

Part of this process includes creating theme-specific copies of all Classy libraries to core themes. This ensures Classy can be removed without impacting those themes.

Because this is the first of several issues for copying a Classy library to Umami, there are no tests for this yet.

Also because this is the first of several similar issues, this will also be used to collect feedback about the process and naming conventions, with the goal of making the additional issues as easy as possible to patch and review.

Proposed resolution

• Make an Umami-specific copy of classy/dropbutton This includes:
  • The library should be called classy.dropbutton, using the classy. prefix to make it clear that it is copied from Classy, not custom to Umami
  • Umami should extend core/drupal.dropbuttonso the end result behaves identically to Classy's extending of the library.
  • The CSS file will be located in css/classy/components. As a rule, copied assets from Classy should go in a classy subdirectory of that asset type, but otherwise maintain the directory structure from classy (such as going in a components or theme directory)
• Add a test class that confirms the copy is successful, and build it so it is easily capable of testing other libraries when they are copied to a theme that previously depended on the Classy library.
• Manually test in Umami by comparing elements that use the dropbutton css before-patch and after-patch, and provide screenshots.

Remaining tasks

Currently all the steps above.

User interface changes

no

API changes

no

Data model changes

no

Release notes snippet

...

Hi

config-import getting error while deploy to remote server using CI

drush cim --partial

after update core 8.7 to 8.8

Unable to install the <em class="placeholder">path_alias</em> module since it
does not exist. in Drupal\Core\Config\ConfigImporter->validate() (line 755 of
/var/www/html/abc/deployments/1575986970/web/core/lib/Drupal/Core/Config/ConfigImporter.php).
The import failed due for the following reasons:                              [error]
Unable to install the <em class="placeholder">path_alias</em> module since it

Resolution: Needs to clear the cache in deployment script before import the configs