Quantcast
Channel: Issues for Drupal core
Viewing all 293056 articles
Browse latest View live

Issue with doTrustedCallback() must be array

$
0
0

Hello Everyone,

I installed drupal 8.9.16. Installation process is completed successfully but when i tried to login with admin details I got error "
TypeError: Argument 1 passed to Drupal\Core\Render\Renderer::doTrustedCallback() must be callable, array given, called in /var/www/html/docroot/core/lib/Drupal/Core/Render/Renderer.php on line 781 in Drupal\Core\Render\Renderer->doTrustedCallback() (line 51 of core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php)."

Please anyone can help to resolve this issue.

Thanks


Figure out how to handle views grid in Olivero

$
0
0

This is split off from #3219959: Update standard profile so Olivero is the default theme and is closely related to #3151553: Make core views grid styles responsive.

Problem

Olivero does not respect the following Views setting when the user selects the "grid" format option.

Screenshot of Views Grid settings with arrows pointing to 'automatic width', 'default column classes', and 'default row classes'

Why?

Because Olivero's implementation of Views Grid is responsive. The number of columns will change depending on the width of the browser's viewport. This IMO should be a requirement.

You can test this out at

Because the default implementation of Views Grid was written so long ago (before responsive web design was a thing), there were wrappers put around each row (or column). The settings within the Views UI allow the site-builder to add CSS classes onto those wrappers. Because Olivero does away with those wrappers, we have no place to put these classes.

What to do?

It's obviously not optimal to have UI settings that do nothing.

Options:

  • We could add the wrappers back in place. This would make the grid no longer responsive. I'm personally hoping this doesn't happen.
  • We could continue as is, and deprecate those options in Drupal 10 and fix #3151553: Make core views grid styles responsive.
  • ??

[META] Make Olivero the default theme for Drupal 9.3

$
0
0

Update standard profile so Olivero is the default theme

HTTP request checking is unreliable and should be removed in favor of watchdog() calls

$
0
0

This issue has a history starting in D6 #245990: HTTP request testing unreliable and may be undesirable

Problem/Motivation & Proposed resolution

(Note: this is the original summary)
Summary of Problem: Drupal's attempts to detect and report when a site cannot make outgoing HTTP requests do not always work correctly, and probably never will. The problem in Drupal is a result of the function system_check_http_request() reporting that the connection isn't working when it actually is. As a result dependent features, such as update status, aggregator, adding new feeds etc. fail and performance substantially slows (~30 seconds) on admin pages when it runs.

What to do about the check function system_check_http_request()
D8: Patch to remove system_check_http_request
- Suggest dependent contrib modules log to watchdog on fails
- Update function to delete drupal_http_request_fails variable addressed in issue#
D6/D7: Leave system_check_http_request for dependent modules
but patch to add a timeout to the drupal_http_request() call to improve performance

What to do about failed HTTP requests:
- D6/D7/D8: When drupal_http_request fails apply patch to log message to watchdog instead of using variable_set('drupal_http_request_fails')
- Need to address potential security issues related to logging urls with possible presence of passwords/tokens/etc.

Remaining tasks

    7.x-dev
  • Currently working on the backport to D7
  • Consider the comments in #70 as part of the code review.
  • Needs further discussion concerning the security implications of logging full URLs in D7.
    This issue should remain open while those discussions are on-going.
    8.x-dev
  • The patch from #46 was reviewed and tested (RTBC).
  • The patch from #46 was commited in #58 here is the commit information (from 8.x repo)

User interface changes

None, but some additional watchdog error messages might appear in the system error log.

API changes

The function system_check_http_request() has been marked as deprecated but only in the Doxygen comments, the original code remains intact.

(Note: Intentionally not including closed/fixed issues and duplicates -- please see comments for those)
#1635882: Remove stale drupal_http_request_fails variable
#2012468: Add trusted roles recommendation to 'access site reports'

Views relationships with multi-valued entity reference fields invalidate Distinct query option

$
0
0

When creating a view with a relationship to an entity reference field (to join the referred-to entity in the query), duplicates will be produced if the entity reference field is multi-valued (i.e. cardinality > 1). Users assume that checking the box at Advanced -> Query settings -> Distinct will solve this problem, but it doesn't.

This is because from a database perspective, the records actually aren't duplicates. Each different entity reference in the multi-valued field will produce a different row as the target IDs are different, even though this isn't necessarily reflected in the view itself if not all fields are included. Said another way, the view results may look the same on the front-end, even though they're not on the back-end.

It should be noted that this affects all entity types, whether it be taxonomy terms, nodes, paragraphs, custom entities, etc. There are several duplicates of this issue in various other queues that should be marked as such, with all efforts directed here.

Proposed solution

If the Distinct box is checked in the view configuration, after the query has executed, remove results whose entity IDs are already in the list.

Remaining tasks

  1. Produce a patch to solve the basic problem.
  2. Add support for pagers (as per #12).
  3. Add support for aggregation (as per the D7 version of Views Distinct).
  4. Add tests.

Original report

If you have a content type with a multivalue taxonomy term field and add a relationship based on that field in a view (in my case I want to use the term name as an argument) the resulting views result has duplicates if one or more of the nodes has multiple terms in that field.

The DISTINCT keyword does not help, since the tid is added as a field in the SELECT part of the query.

I have the following query:

SELECT DISTINCT node_field_data.sticky AS node_field_data_sticky, node_field_data.created AS node_field_data_created, node_field_data.nid AS nid, taxonomy_term_field_data_node_field_data.tid AS taxonomy_term_field_data_node_field_data_tid
FROM 
{node_field_data} node_field_data
LEFT JOIN {taxonomy_index} taxonomy_index ON node_field_data.nid = taxonomy_index.nid
LEFT JOIN {taxonomy_term_field_data} taxonomy_term_field_data_node_field_data ON taxonomy_index.tid = taxonomy_term_field_data_node_field_data.tid
WHERE (node_field_data.promote = '1') AND (node_field_data.status = '1')
ORDER BY node_field_data_sticky DESC, node_field_data_created DESC

.. which produces duplicates, even though the DISTINCT keyword is present, because the taxonomy_term_field_data_node_field_data.tid makes the duplicate nodes in the results 'distinct'.

Ideally the query should just exclude the field from the SELECT part like this:

SELECT DISTINCT node_field_data.sticky AS node_field_data_sticky, node_field_data.created AS node_field_data_created, node_field_data.nid AS nid
FROM 
{node_field_data} node_field_data
LEFT JOIN {taxonomy_index} taxonomy_index ON node_field_data.nid = taxonomy_index.nid
LEFT JOIN {taxonomy_term_field_data} taxonomy_term_field_data_node_field_data ON taxonomy_index.tid = taxonomy_term_field_data_node_field_data.tid
WHERE (node_field_data.promote = '1') AND (node_field_data.status = '1')
ORDER BY node_field_data_sticky DESC, node_field_data_created DESC

which works an nodes with multiple terms in the field are now only appearing once.

I have couldn't find a way to actually omit the field in the SELECT part of the query, and I'm also not sure, if it could create other issues if removed. But the tid in the select the DISTINCT keyword is useless..

Steps to reproduce.
1. add multivalue taxonomy term field to node type, and add a node with multiple terms selected
2. add a view which uses that field to add a relationship to the term (needed to use the term name as argument)
3. make the view results DISTINCT
4. optionally add the argument (contextual filter) that uses the relationship to filter the views result on the term name.
5. if no argument is given, the node with multiple terms in the field will appear multiple times

Migration messages for failed rows are gone

$
0
0

Problem/Motivation

I am creating migrations to add content to the system. I would like Entity Validation to occur, so I included "validation: true" in the yml migration file. To test out validation I created a migration that was missing required data. When I run the migration, however, I only get error messages for the last record in the csv migration. I expected a message for every row.

I am using Migrate Source UI to run the migration.

Steps to reproduce

I created this test scenario to reproduce this issue.

Create field on Article content type that's required. I created a field called Random Info (field_random_info) that's just a plan text field. Make it required.

Create a migration for Articles, like so

langcode: en
status: true
dependencies: {  }
id: new_articles
class: null
field_plugin_method: null
cck_plugin_method: null
migration_tags: null
migration_group: article_migration_group
label: 'Test article ingest'
source:
  plugin: csv
  ids:
    - local_id
  path: 'Will be populated by the Migrate Source UI'
process:
  title: title
  body: body
  field_random_info: random_info
destination:
  plugin: 'entity:node'
  default_bundle: article
  validate: true
migration_dependencies: null

Migration group:

langcode: en
status: true
dependencies: {  }
id: article_migration_group
label: article_migration_group
description: ''
source_type: null
module: null
shared_configuration: null

Put in "config/sync" directory and import configuration.

Create CSV migration file:

local_id,title,random_info,body
test_01,Article 1,,This is article one
test_02,Article 2,,This is article two
test_03,Article 3,,This is article three

Note that it's missing data for the required field Random Info. Run the migration via the Migrate Source UI. (I don't think Migrate Source UI is causing the issue, but I'm really not sure. It might be).

All the records should fail to ingest because they are missing the required field "Random Info".

However, the only message you'll see in the migration table is about the 3rd item. There is no messaging about the other two items. That seems odd.

Proposed resolution

Ideally all error messages would show up. From some testing, errors are being created and then aggressively deleted.

I've tracked it to here -- It appears the code here might need some reordering, but I'm not sure about all the scenarios this code handles.
It seems like this line of code here: https://git.drupalcode.org/project/drupal/-/blob/8.9.x/core/modules/migr...
should only be run if you're going to act on the row. I noticed that it iterates over all the rows each time it's looking for a new row to work on. So each time it iterates looking, it appears to delete all the messages for the rows that have already run (and failed), even if it's not going to act on that data again.

Not sure if reordering this code is the solution, it's just what I've come up with after hours of looking at this. Perhaps there is something else going on that I'm not aware of.

Unable to delete translation of a node with multiple revisions in multilingual site

$
0
0

Problem/Motivation

While content translation & content moderation is enabled, in some cases "Delete translation" feature is not working in node EDIT page of translated node. Mostly if a translated node contains multiple revisions, then delete translation is not deleting the node instead takes admin to dashboard after form submission.

But Delete button in dashboard drop-down & in Delete tab is working

Steps to reproduce

  • In a multilingual site, enable languages like PT, ES, etc. apart from default English
  • Enable content translation & content moderation for a content type
  • Lets assume your workflow have states like: Draft, Published & Archived state
  • Create default English content (Original node) with revision enabled
  • Set moderation state like Draft & Save
  • Add a translation with revision enabled. Set moderation state as Draft
  • Edit translated node and set moderation state as Published with revision enabled
  • Again edit and change state to increase number of revisions
  • Now edit translated node & click "Delete translation" button
  • Translation node won't get deleted. Instead redirects admin to dashboard page

Proposed resolution

Create a patch to address the issue

Remaining tasks

Patch creation

User interface changes

N/A

API changes

M/A

Data model changes

N/A

Release notes snippet

N/A


Update changed link for /filter/tips

$
0
0

Problem/Motivation

The /filter/tips page has a link to http://www.w3.org/TR/html/ but this page is redirected to https://html.spec.whatwg.org/, resulting in a 301 error.

Steps to reproduce

Run an SEO check on any site with comments enabled. The 301 error should appear.

Proposed resolution

Change the link to https://html.spec.whatwg.org/ to eliminate the 301 error.

Remaining tasks

Change the link to https://html.spec.whatwg.org/

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

[meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI

$
0
0

Problem

Without proper caching, Drupal is SLOW, just like many extensible PHP frameworks. Despite the great cache tag feature of Drupal 8, not everything can be fully cached.
One major problem is Drupal's bootstrap is very resource-intensive. Regardless of how much time we put into optimizing it, it can only become slightly faster. The reason for this as i believe is because we're using the wrong approach. Bootstrapping the whole application for every request is just wrong. Things get even worse when one wants to use Drupal as a headless REST API for something like a progressive application with many small simultaneous requests.

Why is this critical

The web is becoming much faster and the content is extremely customized. In many cases caching just wouldn't cut it.
just to name few related technologies: Progressive Apps, HTTP2, IoT, REST, Li-Fi, 5G, etc.
With Drupal headless initiative which makes using Drupal for modern web much easier and semantic versioning which makes it possible to add many new features to core every several months, can Drupal really compete with Walled Garden ? Will 200-300ms for dynamics content acceptable for users and clients? Drupal can be used for sites with heavy traffic and dynamic content, but if we put aside how challenging it's, it can never deliver the same performance as more modern Web solutions written by likes of Node.js

I think this is important enough to become an initiative.

Solution

It's simple, not to bootstrap Drupal every time. Up until a few years ago, there wasn't any reliable solution fast enough worth the effort. But now there are several open-source projects already in production (PHP-PM, PHPFastCGI, Icicle, AppServer.io , etc). And it is fast, we're talking about 10-30ms and few kilobytes of memory usage without any caching or optimization against 100-150ms and megabytes of memory usage (The numbers come from my experiment with ReactPHP HTTP server and a custom Silex application). This is without any optimization, just changing the approach! But when the application bootstraps only once and objects are persistent, a lot of things can be greatly optimized.

Demonstration

I haven't been able to find any benchmarks for Drupal, but for other frameworks the are several :

More information on the wiki page: https://groups.drupal.org/node/417723

Work already done

There has been several attempts, discussions and experiments so far using different approaches :

Roadmap

TypeError EntityViewsData::mapFieldDefinition() null given

$
0
0

I get the following error after upgrading from 8.8 to 8.9.
TypeError: Argument 3 passed to Drupal\views\EntityViewsData::mapFieldDefinition() must implement interface Drupal\Core\Field\FieldDefinitionInterface, null given, called in /var/www/html/web/core/modules/views/src/EntityViewsData.php on line 315 in Drupal\views\EntityViewsData->mapFieldDefinition() (line 412 of core/modules/views/src/EntityViewsData.php).

I made a quick patch to handle the error so that I can keep going until I or someone can take a closer look.
Hope this helps someone.

Multisite setup based on paths is broken

$
0
0

Problem/Motivation

According to Multisite Mapping with Drupal It is possible to create a multisite setup without symlinks that is based on paths, for example

http://dev.example.com/site1
http://dev.example.com/site2

But the code that should handle that scenario is completely broken:

    // Otherwise, use find the site path using the request.
    $script_name = $request->server->get('SCRIPT_NAME');
    if (!$script_name) {
      $script_name = $request->server->get('SCRIPT_FILENAME');
    }
    ...
    $uri = explode('/', $script_name);

SCRIPT_NAME always returns index.php and SCRIPT_FILENAME returns the real path in the file system which is obviously the same for site1 and site2 as long as you don't create any symlinks and virtual hosts for every site. According to the documentation that was the case for Drupal 7 and that's where the code comes from:

By sharing the same drupal code base as above (/public_html/drupal) , you may extend the Subdomain Mapping where you can set another drupal sites under URL's Paths like so:

http://dev.example.com/site1,
http://dev.example.com/site2, etc..

Symbolic Links

First you will need to access your server shell. Then create the symbolic links to the drupal root folder named site1 and site2 by following command:

$ cd /path/to/your/public_html/drupal
$ ln -s . site1
$ ln -s . site2

For Drupal 8 the documentation states something else (which makes a lot of sense):

Multi Drupal Sites (By Drupal 8)

By Drupal 8 the symbolic links are no more required, there even a flexibility to name the folders under /public_html/drupal/sites as long you put them on the file sites.php like:

$sites = array(
'dev.example.com' => 'dev',
'dev.example.com.site1' => 'dev.site1',
'dev.example.com.site2' => 'dev.site2',
);

Proposed resolution

In Drupal 8 the algorithm must simply use REQUEST_URI instead of SCRIPT_FILENAME.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Modules get disabled during a " module save" race condition

$
0
0

after about the 20th client of mine did this during training, I decided to file and patch this problem.

The problem:
On a fresh Drupal 7 installation with standard Drupal modules enabled, it is possible to inadvertently disable modules simply by clicking "Save Configuration" twice in succession before the page has had time to reload. I run into this a lot with clients who dont know any better, and don't see the 'loading...' that is being displayed in the overlay. They tend to think nothing happened and click submit again.

The classic symptom is the user asking "where did the toolbar go?" After digging into it, it's almost always that the toolbar, shortcuts and sometimes the overlay modules have been disabled, even though the user never unchecked them. Sometimes even more modules have been disabled - it really depends on how long the user waits between clicks.

This seems to be most common on WAMP or possibly WIMP installs, but also happens on MAMP and other configurations. Generally speaking, as long as the modules page takes a reasonably long amount of time to process and load, this problem becomes more noticeable.

The solution:

Rather than tracking down the race condition that is taking place in the system module build process, it seems that it might make the most sense to implement a lock during the module save process to prevent either users hitting save twice, or two users hitting save at the same time. This seems to do the trick in preventing this problem from reoccurring.

see attached patch for lock implementation.

Hope this helps someone!
-Chris

[Meta] Bug Smash Initiative triage fortnight commencing 2021-07-06

$
0
0

Meta for triage credit, please comment and link to issues you triaged and closed.

[Meta] Bug Smash Initiative triage fortnight commencing 2021-07-20

$
0
0

Meta for triage credit, please comment and link to issues you triaged and closed.


Create a public read/write interface for $StylePluginBase::rendered_fields

$
0
0

API page: https://api.drupal.org/api/drupal/core%21modules%21views%21src%21Plugin%...

I would suggest to create 2 new methods that will get data from or set data to $StylePluginBase::rendered_fields.

At first, it was proposed to simply make $StylePluginBase::rendered_fields public instead of being protected. This was rejected as this is not in line with OOP philosophy which requires methods to access properties.

Prior to the proposed solution, creating a derived class of StylePluginBase was considered as well. However, the methods would not spread throughout all style plugins. The latter is a pre-requisite because Views Merge Rows is a display extender intended to work with any style plugin.

Here is a sample of the module code::

$view->style_plugin->renderFields($view->result);
$rendered_fields = $view->style_plugin->getRenderedFields();

Deprecate jquery.once and use the new once lib

$
0
0

Deprecate and replace all instances of jQuery.once in core

HOW TO REVIEW

There are 2 branches:

  • The branch 3183149-jquery-once-review-friendly is the one to commit to. This holds all the change on top of the automated replacements, The diff between auto fix and manual changes.
  • The branch 3183149-auto-replace holds all the automated replacements (no human intervention on the code of this branch, see below for the list of replacement that are made automatically). It is used for reference, so please do not commit to it.

The human code is on the branch 3183149-jquery-once-review-friendly and the majority of manual changes are in this commit: https://git.drupalcode.org/project/drupal/-/merge_requests/513/diffs?com...

The Merge request for core is !513


The majority of the patch was made thanks to a custom codemod, automated replacement are:
BeforeAfter
$('body')
  .once('detailsAria')
  .on('click.detailsAria', function () {});
$(once('detailsAria', 'body'))
  .on('click.detailsAria', function () {});
const $collapsibleDetails = $(context)
  .find('details')
  .once('collapse')
  .addClass('collapse-processed');
const $collapsibleDetails = $(once('collapse', 'details', context))
  .addClass('collapse-processed');
const $progress = $('[data-drupal-progress]').once('batch');
const $progress = $(once('batch', '[data-drupal-progress]'));
$(context)
  .find('th.select-all')
  .closest('table')
  .once('table-select')
  .each(Drupal.tableSelect);
$(once('table-select', $(context)
  .find('th.select-all')
  .closest('table')))
  .each(Drupal.tableSelect);
const $timezone = $(context).find('.timezone-detect').once('timezone');
const $timezone = $(once('timezone', '.timezone-detect', context));
$(this).removeOnce('big-pipe');
$(once.remove('big-pipe', $(this)));
const $configurationForm = $(context)
  .find('.ckeditor-toolbar-configuration')
  .findOnce('ckeditor-configuration');
const $configurationForm = $(
  once.filter('ckeditor-configuration', '.ckeditor-toolbar-configuration', context)
);
$('<div class="color-placeholder"></div>').once('color').prependTo(form);
$(once('color', $('<div class="color-placeholder"></div>'))).prependTo(form);
$('.color-preview')
  .once('color')
  .append(`<div id="gradient-${i}"></div>`);
$(once('color', '.color-preview'))
  .append(`<div id="gradient-${i}"></div>`);
if ($('body').once('contextualToolbar-init').length) {
  initContextualToolbar(context);
}
if ($(once('contextualToolbar-init', 'body')).length) {
  initContextualToolbar(context);
}
$context
  .find('#filters-status-wrapper input.form-checkbox')
  .once('filter-editor-status')
  .each(function () {});
$(once(
  'filter-editor-status',
  '#filters-status-wrapper input.form-checkbox',
  context
))
  .each(function () {});
editors = $(context).find('[data-editor-for]').findOnce('editor');
editors = $(context).find('[data-editor-for]').removeOnce('editor');
editors = $(once.filter('editor', '[data-editor-for]', context));
editors = $(once.remove('editor', '[data-editor-for]', context));
$context
  .find(selector)
  .removeOnce('fileValidate')
  .off('change.fileValidate', Drupal.file.validateExtension);
$(once.remove('fileValidate', $context
  .find(selector)))
  .off('change.fileValidate', Drupal.file.validateExtension);
$(context)
  .find('.js-filter-guidelines')
  .once('filter-guidelines')
  .find(':header')
  .hide()
  .closest('.js-filter-wrapper')
  .find('select.js-filter-list')
  .on('change.filterGuidelines', updateFilterGuidelines)
  // Need to trigger the namespaced event to avoid triggering formUpdated
  // when initializing the select.
  .trigger('change.filterGuidelines');
$(once('filter-guidelines', '.js-filter-guidelines', context))
  .find(':header')
  .hide()
  .closest('.js-filter-wrapper')
  .find('select.js-filter-list')
  .on('change.filterGuidelines', updateFilterGuidelines)
  // Need to trigger the namespaced event to avoid triggering formUpdated
  // when initializing the select.
  .trigger('change.filterGuidelines');
// Keep the jQuery find because of sizzle selector.
$(context)
  .find('table .bundle-settings .translatable :input')
  .once('translation-entity-admin-hide')
  .each(function () {});
// Keep the jQuery find because of sizzle selector.
$(once('translation-entity-admin-hide', $(context)
  .find('table .bundle-settings .translatable :input')))
  .each(function () {});
$('.js-click-to-select-trigger', context)
  .once('media-library-click-to-select')
  .on('click', (event) => {});
$(
  once('media-library-click-to-select', '.js-click-to-select-trigger', context)
)
  .on('click', (event) => {});
const $view = $(
  '.js-media-library-view[data-view-display-id="page"]',
  context,
).once('media-library-select-all');
const $view = $(once(
  'media-library-select-all',
  '.js-media-library-view[data-view-display-id="page"]',
  context
));
$('.js-media-library-item-weight', context)
  .once('media-library-toggle')
  .parent()
  .hide();
$(once('media-library-toggle', '.js-media-library-item-weight', context))
  .parent()
  .hide();
$('body').removeOnce('copy-field-values').off('value:copy');
$(once.remove('copy-field-values', 'body')).off('value:copy');
$(`#${ids.join(', #')}`)
  .removeOnce('copy-field-values')
  .off('blur');
$(once.remove('copy-field-values', `#${ids.join(', #')}`))
  .off('blur');
this.$el
  .find(`#toolbar-link-${id}`)
  .once('toolbar-subtrees')
  .after(subtrees[id]);
$(once('toolbar-subtrees', this.$el
  .find(`#toolbar-link-${id}`)))
  .after(subtrees[id]);
initTableDrag($(context).find(`#${base}`).once('tabledrag'), base);
initTableDrag($(once('tabledrag', `#${base}`, context)), base);
$('table')
  .findOnce('tabledrag')
  .trigger('columnschange', !!displayWeight);
$(once.filter('tabledrag', 'table'))
  .trigger('columnschange', !!displayWeight);
const $forms = (contextIsForm ? $context : $context.find('form')).once('form-updated');
// Replace
const $forms = $(once('form-updated', contextIsForm ? $context : $context.find('form')));
const $source = $context
  .find(sourceId)
  .addClass('machine-name-source')
  .once('machine-name');
const $source = $(once('machine-name', $context
  .find(sourceId)
  .addClass('machine-name-source')));
// Don't replace.
_.once(() => {});
CKEDITOR.once('instanceReady', (e) => {});
// Don't replace.
_.once(() => {});
CKEDITOR.once('instanceReady', (e) => {});

The patch in #21 show all the automated replacements. Then a manual step was necessary to replace the once calls on $(window) and $(document) as well as replacing calls to $.each by .forEach when possible. The interdiff in #23 show the manual changes.

From there the creation of the merge request was based on patch #29 with updates to the once lib files and a fix for the library dependency of autocomplete.

"Has taxonomy term" contextual filter does not take the language value into account

$
0
0

Problem/Motivation

On a multilingual website:

  1. Create an article with a tag, for example in english
  2. Translate the article in french and do not associate the french version with the tag.
  3. Go to the tag page in english
  4. See your article in english: OK, normal
  5. Go to the tag page in french
  6. See your article in french: KO, the french version of the article is not associated with the tag

The problem is due to the taxonomy_index table, the langcode of the node is not stored. So when the contextual filter "Content: Has taxonomy term ID" make a relationship on the table, it includes the node in all the languages.

Proposed resolution

I don't know how the clean way to solve this and as I need something working quickly I made a workaround. I will upload a patch (with a hook_update_n starting at 8300 to not be incompatible with further merged hook_update_n).

The idea is to add a "langcode" column to store the langcode of the node in which the taxonomy term is referenced.

Then adding a new view filter on this column to be able to filter the results to avoid duplication.

Remaining tasks

  1. Code / idea review
  2. Needs tests
  3. Needs proper update path

User interface changes

A new view filter is created: "Taxonomy term: Node language"

Data model changes

Column "langcode" added to taxonomy_index and "langcode" added to the primary key and the ndexes of the table.

Link error "The internal path component is invalid"

$
0
0

Steps to reproduce

  1. create an entity type that includes AJAX calls on the node edit form, e.g. node with a link field and a media field, or a field with multiple elements and "add another" links
  2. as a user without the 'link to any page' permission, try to create an instance of that entity
  3. enter an invalid path in the link field, e.g. 'foo'
  4. click on the button that initiates an AJAX request, e.g. file upload, add another

Expected result

An error message should appear about the invalid internal path, but you should be able to proceed with the action

Actual result

It isn't possible to proceed.
The AJAX call responds with a 500 error "The internal path component is invalid. Its path component must have a leading slash" with field widget type "Link".

↵An AJAX HTTP error occurred.↵HTTP Result Code: 500↵Debugging information follows.↵Path: /fr/node/6/edit?element_parents=field_test/widget/0&destination=/admin/content&ajax_form=1↵StatusText: 500 Service unavailable (with message)↵ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: The internal path component &#039;test&#039; is invalid. Its path component must have a leading slash, e.g. internal:/foo.

This error generates from \Drupal\Core\Url::fromInternalUri

It happens from \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
in code
$item->getUrl()->access() (core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php:175)

For avoidance of this error we have next element validator where check input values
\Drupal\link\Plugin\Field\FieldWidget\LinkWidget::validateUriElement

So we can't catch this error on common entity save operation.
But we can catch it with any additional ajax buttons, which skip validation with #limit_validation_errors

It appears on all browsers.

In my example "foo" value is incorrect for Link field. We can avoid this error by putting only correct values. But customer can be confused. He doesn't know what values are correct, and he doesn't know why all his AJAX buttons don't work. So we should avoid 500 error with ajax buttons.

I have investigated this issue and found, that we need to add additional check in \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
I have prepared patch and I will apply it in comment.

User login flood lock doesn't clear when reset password as admin

$
0
0

Problem/Motivation

#992540: Nothing clears the "5 failed login attempts" security message when a user resets their own password clears the user login flood lock when user try to reset password. However, it doesn't work for admin resets user password.

Steps to reproduce

  1. Register as a normal user
  2. Try to login with wrong password for 5 times
  3. Login as admin and change user's password
  4. Try to login as user with new password

Expected
Allow user to login with new password.

Expected
- Still getting "There have been more than 5 failed login attempts for this account. It is temporarily blocked. Try again later or request a new password."

Proposed resolution

Dispatch an event on password reset to clear flood lock.

Remaining tasks

- One scenario current patch doesn't work - When admin reset the password and new password == old password.

Viewing all 293056 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>