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

Replace use of whitelist/blacklist in \Drupal\Core\Security\RequestSanitizer and its test

$
0
0

Problem/Motivation

Lets remove usage of "blacklist" and "whitelist" in \Drupal\Core\Security\RequestSanitizer and its test

They are:

  • An historic bad labelling of people
  • Provide no context: "what is listed in them"?

Proposed resolution

@see The CR:

  • The sanitize_input_whitelist site setting has been renamed to sanitize_input_safe_keys
  • Similarly, the Drupal\Core\Security\RequestSanitizer::SANITIZE_WHITELIST constant has been replaced with RequestSanitizer::SANITIZE_INPUT_SAFE_KEYS.
  • Update all function parameter names, variables and code comments to reflect these changes.

Remaining tasks

  1. Do the renames.
  2. Handle deprecated setting BC. See #3163226: Add the ability to deprecate a Settings name
  3. Reviews / refinements.
  4. RTBC.
  5. Commit.

User interface changes

None

API changes

@see The CR:

  • The sanitize_input_whitelist site setting has been renamed to sanitize_input_safe_keys
  • Similarly, the Drupal\Core\Security\RequestSanitizer::SANITIZE_WHITELIST constant has been replaced with RequestSanitizer::SANITIZE_INPUT_SAFE_KEYS.

Data model changes

N/A

Release notes snippet

TBD


Convert config module hook_help() to topic(s)

$
0
0

Problem/Motivation

#3041924: [META] Convert hook_help() module overview text to topics for the config module(s).

Proposed resolution

Take the information that is currently in the hook_help module overview section for the module(s), and make sure the information is in one or more Twig help topic files. Steps:

  1. Find the hook_help() implementation function in the core/modules/MODULENAME/MODULENAME.module file(s). For example, for the core Contact module, the module files is core/modules/contact/contact.module, and the function is called contact_help().
  2. Locate the module overview portion of this function. This is located just after some lines that look something like this:
      switch ($route_name) {
        case 'help.page.contact':
    

    And ends either at the end of the function, or where you find another case 'something': line.

  3. We want to end up with one or more topics about the tasks that you can do with this module, and possibly a section header topic. So, read the help and figure out a good way to logically divide it up into tasks and sections. See Standards for Help Topics for information on how to do this.
  4. See if some of these tasks are already documented in existing topics. Currently, all topics are in core/modules/help_topics/help_topics. Note that to see existing topics, you will need to enable the experimental Help Topics module (available in the latest dev versions of Drupal 8.x).
  5. For each task or section topic that needs to be written, make a new Twig topic file (see Standards for Help Topics) in core/modules/help_topics/help_topics. You will need to choose the appropriate module prefix for the file name -- the module that is required for the functionality. Alternatively, if the information spans several modules or if the information should be visible before the module is installed, you can use the "core" file name prefix. For instance, it might be useful to know that to get a certain functionality, you need to turn on a certain module (so that would be in the core prefix), but then the details of how to use it should only be visible once that module is turned on (so that would be in the module prefix).
  6. File names must be MODULENAME.TOPICNAME.html.twig -- for example, in the Action module, you could create a topic about managing actions with filename action.managing.html.twig (and "MODULENAME" can be "core" as discussed above).
  7. Make a patch file that adds/updates the Twig templates. The patch should not remove the text from the hook_help() implementation (that will be done separately).

Remaining tasks

a) Make a patch (see Proposed Resolution section).

b) Review the patch:

  1. Apply the patch.
  2. Turn on the experimental Help Topics module in your site, as well as the module(s) listed in this issue.
  3. Visit the page for each topic that is created or modified in this patch. The topics are files in the patch ending in .html.twig. If you find a file, such as core/modules/help_topics/help_topics/action.configuring.html.twig, you can view the topic at the URL admin/help/topic/action.configuring within your site.
  4. Review the topic text that you can see on the page, making sure of the following aspects:
    • The text is written in clear, simple, straightforward language
    • No grammar/punctuation errors
    • Valid HTML -- you can use http://validator.w3.org/ to check
    • Links within the text work
    • Instructions for tasks work
    • Adheres to Standards for Help Topics [for some aspects, you will need to look at the Twig file rather than the topic page].
  5. Read the old "module overview" topic(s) for the module(s), at admin/help/MODULENAME. Verify that all the tasks described in these overview pages are covered in the topics you reviewed.

User interface changes

Help topics will be added to cover tasks currently covered in modules' hook_help() implementations.

API changes

None.

Data model changes

None.

Release notes snippet

None.

PluginWithFormsInterface and PluginWithFormsTrait should reference each other in docs

Unused local variables from ActiveLinkResponseFilterTest.php file

$
0
0

Problem/Motivation

In core/tests/Drupal/Tests/Core/EventSubscriber/ActiveLinkResponseFilterTest.phpproviderTestSetLinkActiveClass() initializes $markup, but it never uses it.

Proposed resolution

Remove $markup.

'query' => [],
     ];
     // Nothing to do.
-    $markup = '<foo>bar</foo>';
     $situations[] = ['context' => $context, 'is active' => FALSE, 'attributes' => []];
     // Matching path, plus all matching variations.
     $attributes = [

Unused variable $id in comment module, Comment.php

$
0
0

Problem/Motivation

In core/modules/comment/src/Entity/Comment.php, $id variable never used.

SQL source plugins: allow defining conditions in migration yml

$
0
0

Problem/Motivation

It would be great to be able to use conditions to narrow down your SQL source data for content/config entity types. The resulting functionality would provide similar capabilities to how you can migrate nodes one content type at a time, and the same for taxonomy terms -- but for users (by role), menu links (by menu), and so on.

The functionality would let you narrow your data during the source/extraction phase, instead of during the process/transformation phase (which you can do using skip_on_value/empty + method: row).

Benefits would include general tidiness of data :) And! Speed/performance!

(discussion of ideas/concerns/etc. started on Slack in mid-July 2019)

Proposed resolution

Ideas so far...

  • Generic system for skipping rows based on arbitrary/arbitrary-ish conditionals.
  • ^^ in SourcePluginBase and/or SqlBase.
  • Migration yml would have a conditions array with keyed values that get passed to the SQL source plugin.

Remaining tasks

(reviews needed, tests to be written or run, documentation to be written, etc.)

User interface changes

(New or changed features/functionality in the user interface, modules added or removed, changes to URL paths, changes to user interface text.)

API changes

(API changes/additions that would affect module, install profile, and theme developers, including examples of before/after code if appropriate.)

Data model changes

(Database or configuration data changes that would make stored data on an existing site incompatible with the site's updated codebase, including changes to hook_schema(), configuration schema or keys, or the expected format of stored data, etc.)

Release notes snippet

(Major and critical issues should have a snippet that can be pulled into the release notes when a release is created that includes the fix)

[ignore] patch testing

Autocomplete input text can visibly overflow under magnifier icon

$
0
0

Problem/Motivation

If an autocomplete input's text fills the input, the text will appear underneath the magnifying glass icon.

This is also an issue in Seven, but may be less noticeable due to the size of the inputs and icons.

There is a patch that included a fix that almost fully resolved the problem, but it resulted in autocomplete and text inputs not having the same widths at certain viewport widths - this discrepancy is easy to spot using a node form and adjusting the viewport width from narrow to wide.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes


Empty gallery not hidden on content page

$
0
0

Hi,

I created a content type with two media reference fields : one is for videos, the other for a slideshow. Both fields are optional, and fot both fields, only one type of media is available : respectively videos and gallery.

When I try to add a new content, if I leave the videos field empty, it is not shown on the content page once it's published, which works the way it is intended.
But even if I don't create any slideshow, the empty block is showed on the published content page, with only the field title, and an empty space below.

I have no idea why, since both fields are of the same type (media reference entity), and both are optional.

FYI, the layout of my content type is built with Layout Builder.

Thanks

Unused variable $frequency in locale module, locale.module

$
0
0

Problem/Motivation

In core/modules/locale/locale.module, $frequency variable never used.

Layout Regions are not responsive

$
0
0

Layout Regions in the theme are not responsive.

On smaller screens, the panel on the right (with Meta info, like published, URL, etc), should reposition down below below the primary edit region. This is especially a problem when using vertical tabs on the left side of the edit screen, not much room is left for the primary edit region.

I got around this using the Meta Position module https://www.drupal.org/project/meta_position but it would be nice not to have to do this.

See attached image for issue (using Adminimal theme, but same issue in seven theme)

Unused variable $config in locale module, locale.bulk.inc

$
0
0

Problem/Motivation

In core/modules/locale/locale.bulk.inc, $config variable never used.

"Azure Database for MySQL server" reports wrong database version

$
0
0

Steps to reproduce

Inside a DDEV container, which has 10.2.25-MariaDB, configure a remote MySQL connection, which is on MySQL 8.0.15.

Expected behavior

The site should be usable with the remote connection

What happened instead

In Connection.php line 469:
                                                                                       
  SQLSTATE[42000]: Syntax error or access violation: 1231 Variable 'sql_mode' can't be se  
  t to the value of 'NO_AUTO_CREATE_USER'

Debug details

In drupal/web/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php, $pdo->getAttribute(\PDO::ATTR_SERVER_VERSION) returns the local version, not the version of the remote server.

Provide a theme setting for disable the block contextual link or not

$
0
0

Seven theme dos not have contextual link because of #2487025: Remove contextual links in Seven.
I believe the contextual link is a useful feature in some case, for example: layout_build need contextual link to edit the block settings.
Could we provide a theme setting for disable block contextual link or not?

No error messages are shown for applied validation on a view exposed filter with on "AJAX"

$
0
0

The applied validation error messages are not shown for a view exposed filter on failure when "Ajax" is on.

ajax-option

the messages are displayed again on next page load.

There is an older issue opened for Drupal 7

https://www.drupal.org/node/1833322

Recommended solution:


function MODULE_views_ajax_data_alter(&$commands, $view) {
$commands[] = ajax_command_prepend($commands[0]['selector'], theme('status_messages'));
}

Is the correct way to solve the problem or solution should be implemented in views module itself ?


Error after updating core from 8.6.2 to 8.7.14

$
0
0

After I have updated my Drupal core version from 8.6.2 to 8.7.14, I have got below error at the time of cache clear and db update.

composer update drupal/core webflo/drupal-core-require-dev --with-dependencies

Below error occurs while running update.php

An AJAX HTTP error has occurred. HTTP result code: 200 Debug information follows. 
Path: /update.php/start?id=55&op=do_nojs&op=do 
Status text: OK 
Answer text: ArgumentCountError: Too few arguments to function Drupal\Core\Entity\EntityTypeManager :: __ construct(), 
5 passed and exactly 6 expected in Drupal\Core\Entity\EntityTypeManager->__construct()
(line 92 of C:\myproject\html\core\lib\Drupal\Core\Entity\EntityTypeManager.php).

This error occured at the time of cache rebuilt (Drush cr)

Fatal error: Uncaught ArgumentCountError: Too few arguments to function Drupal\Core\Entity\EntityTypeManager::
__construct(), 5 passed in C:\myproject\html\core\lib\Drupal\Component\DependencyInjection\Container.php on line 285 
and exactly 6 expected in C:\myproject\html\core\lib\Drupal\Core\Entity\EntityTypeManager.php:92

I couldn't able to proceed my update process.

PHP version 7.3.12
Windows OS
Drush version 9.3

Add assertSameCount()

:focus indicator not visually distinct in ui dialog in Bartik, Seven, Classy

Replace assertions involving calls to drupalGetHeader() with session-based assertions, where possible

$
0
0

Problem/Motivation

As title, we can explore replacing assertions looking at results of the drupalGetHeader method, by asserting the session and then using methods from WebAssert on it.

Proposed resolution

For example:

-    $this->assertEqual($expectedGeneratorHeader, $this->drupalGetHeader('X-Generator'));
+    $this->assertSession()->responseHeaderEquals('X-Generator', $expectedGeneratorHeader);

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

FileItem::generateSampleValue() should generate files with the actual allowed extensions

$
0
0

Problem/Motivation

FileItem::generateSampleValue() hard-codes to generating txt files. If I have a file field that doesn't allow txt files, this is creating unwanted values.

Proposed resolution

Honor the field configuration's file_extensions setting and only generate sample files with allowed extensions.

Remaining tasks

  1. Write test. See #30
  2. Fix code.
  3. Fix minor CS violation.
  4. RTBC.
  5. Commit.

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

Viewing all 296921 articles
Browse latest View live


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