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

Fix strict type errors: Convert FormattableMarkup to strings (complex replacement) in core Functional tests

$
0
0

Problem/Motivation

See parent(s).

This issue is for complex conversions of FormattableMarkup into regular double-quoted strings with simple function calls or new variables used in the arguments embedded directly inside the quoted string. Occasional use of sprintf may also be considered.

The scope here is the core Functional tests.

Steps to reproduce

Proposed resolution

Convert all test assertion methods in functional tests from using FormattableMarkup that are not covered in #3404273: Fix strict type errors: Convert FormattableMarkup to strings (simple replacement) in core Functional tests.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Investigate random failures in nightwatch and phpunit

$
0
0

Problem/Motivation

It's been reported both in core and contrib that some test jobs fail due to DB not being available (?)

Core

PHPUnit

https://git.drupalcode.org/issue/drupal-1959304/-/jobs/573143
https://git.drupalcode.org/project/address/-/jobs/616657

Nightwatch

https://git.drupalcode.org/issue/drupal-3324560/-/jobs/629098

Contrib

https://git.drupalcode.org/project/cdn/-/pipelines/75330

Steps to reproduce

Proposed resolution

Add CI_DEBUG_SERVICES=true to .gitlab-ci.yml so we can get detailed information on what's happening in the database from a test that will fail.
Revert the change as soon as we find one job that will fail due to this

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Fix notice in _install_prepare_import() due to alternate approach to translations

$
0
0

Problem/Motivation

The locale deploy allows a site to manage all of its translation deployments via it's own project repository and prevent the translation system from getting translations from localize.drupal.org outside of its own Drush commands. One of the things it does is remove the version information from translation files. This results a warning in _install_prepare_import() due to assumptions that code makes.

Steps to reproduce

  1. Install minimal
  2. Enable locale_deploy module
  3. Add a language
  4. Run drush locale-deploy:localize-translations
  5. Import the site from configuration drush si --existing-config

Proposed resolution

There's nothing for this code to do in this situation.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/a

exception messages in FieldConfig::getFieldStorageDefinition() are inaccurate

$
0
0

Problem/Motivation

https://api.drupal.org/api/drupal/core%21modules%21field%21src%21Entity%...

This throws N exception with a message
"Attempted to create an instance of field with name {$this->field_name} on entity type {$this->entity_type} when the field storage does not exist.");

However, this method is not only called when creating a field, but also in preSave(), calculateDependencies(), preDelete(), and postDelete()

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[Meta] Bug Smash Initiative monthly triage meta commencing 2024-01-09

$
0
0

Meta for triage credit, please note: you only need to add a comment for one issue that was triaged and closed, not every one.

Remember to add the tag 'Bug Smash Initiative' to issues that are triaged.

Remove 'pattern' description from hook_theme

$
0
0

Problem/Motivation

The doc block for hook_theme includes 'pattern' which doesn't seem to be used anymore. Therefore, it can be removed.

 *   - pattern: A regular expression pattern to be used to allow this theme
 *     implementation to have a dynamic name. The convention is to use __ to
 *     differentiate the dynamic portion of the theme.

Discovered this in consultation with larowlan while working on #3409388: Remove usage of forum module from comments and strings, which used 'forum' as an example for the pattern.

Steps to reproduce

Proposed resolution

Remove the entire description for 'pattern'

   - pattern: A regular expression pattern to be used to allow this theme
 *     implementation to have a dynamic name. The convention is to use __ to
 *     differentiate the dynamic portion of the theme. For example, to allow
 *     forums to be themed individually, the pattern might be: 'forum__'. Then,
 *     when the forum is rendered, following render array can be used:
 *     @code
 *     $render_array = array(
 *       '#theme' => array('forum__' . $tid, 'forum'),
 *       '#forum' => $forum,
 *     );
 *     @endcode

Remaining tasks

Confirm it is not used
Create an MR

User interface changes

API changes

Data model changes

Release notes snippet

One form validation function should be able to bypass other validation steps

$
0
0

Transferred from https://security.drupal.org/node/134653 since this was determined to be a feature request for FAPI, as opposed to a security vulnerability.

Problem/Motivation

Example 1 reported by hejazee
==================
some form validators should take precedence. for example the validator should be executed first.
and if it fails, other validators should not be executed.

because form validators set messages on the form.
and if the initial validation fails, the user (attacker bot) should not see if other fields are valid since this could expose unwanted information.

Example 2 reported by jpcondon (private issue)
==================
This module has a denial of service vulnerability.

You can see this vulnerability by:
1. Install Drupal.
2. Create content type with file field with two different restrictions on it, such as file size and file type.
3. Upload file with wrong file type and wrong file size and observe that both error messages appear.

While this isn't a big deal when simply validating file type or size, this presents a larger issue when using a module like the ClamAV module where it will attempt to scan the file even if other file validation errors have occurred. If a file is excessively large it will still be scanned which could cause a denial of service on the website.

Proposed resolution

Create a cancel validation variable, getter, and setter in the form state to track whether subsequent form validation functions should be skipped, i.e. if it is preferred that further validation functions should be prevented from executing, e.g.: you might set setValidationCanceled(TRUE) if a CSRF token is not valid, because it doesn't make sense to perform any further validation (and it might be a security risk to do so).

Remaining tasks

Decide how to add this feature in a backward-compatible way.

Commentary from @David_Rothstein:

There probably isn't a way to actually prevent other validation functions from running currently, but there should be some ways to prevent their error messages from displaying... Here's what I wrote elsewhere:

I don't think we necessarily need a change to Drupal core for this. I haven't looked too deeply into it, but couldn't you at least use something like form_get_errors(), form_set_error(), and form_clear_error() to clear out all validation errors on the form (at the end of the validation process) and then re-set the ones from the desired field only? I think something like this technique might work for both Drupal 6 and Drupal 7.

Also for Drupal 7 there's $form_state['triggering_element']['#limit_validation_errors'] which is a cleaner way to tell Drupal to ignore (and not display) certain form validation errors, but perhaps there's no place in the code where you can set that during form validation and have it work on the rest of the validation... not sure.

User interface changes

n/a

API changes

TBD

Data model changes

n/a

Incorrect behaviour for block page visibility

$
0
0

Problem/Motivation

When leaving the "listed pages" text area empty in "Pages" block visibility, the options "Show for the listed pages" and "Hide for the listed pages" do the exact opposite of what they claim, they work as though there was an entry * in the list, i.e.:

  • Show for the listed pages will result in the block showing on all pages when the list is empty
  • Hide for the listed pages will result in the block showing nowhere when the list is empty

For an empty list, "Show on the listed pages" should not show the block anywhere. And, "Hide on the listed pages", should have the block show up on every page, when the list is empty.

Proposed resolution

Add a new radio button option for "Show on all pages", select this by default, hide the text area when this is selected, then validate that the box is not empty if either of the other two options are selected. See #19

One consideration is that the default currently causes the block to show everywhere, which in itself is probably a good default. It's just that it is being achieved by combining "Show on the listed pages" with an empty list, which at least caused me to select "Hide on the listed pages", expecting that to result in the block showing everywhere.

Another consideration is to ensure that the descriptive test (Not Restricted/Restricted to certain pages) in the Pages tab is correct.

Remaining tasks

  1. Decide on resolution
  2. Implement resolution
  3. code review
  4. add change record - suitable for a novice. There are instructions for adding a change record.

User interface changes

Before

After

API changes

None.


Deprecated function: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\views\Plugin\views\PluginBase->viewsTokenReplace()

$
0
0

Here is the web/core/modules/views/src/Plugin/views/PluginBase.php::viewsTokenReplace() function:

  protected function viewsTokenReplace($text, $tokens) {
    if (!strlen($text)) {
      // No need to run filterAdmin on an empty string.
      return '';
    }
     ....

The !strlen($text) check is made to check if $text is empty or null
This is deprecated in php 8.1

maybe we can replace by:

  protected function viewsTokenReplace($text, $tokens) {
    if (!$text) {
      // No need to run filterAdmin on an empty string.
      return '';
    }
     ....

Why doesn't AccountInterface yield a isEnabled() method?

$
0
0

AccountInterface in Drupal doesn't yield an isEnabled() or an isBlocked() method, why is that ?

Access checkers code could use this information to determine access to some resources, for example, in Symfony, the AdvancedUserInterface interface brings along multiple methods such as isAccountNonExpired(), isAccountNonLocked(), isCredentialsNonExpired() and isEnabled().

I'm not saying all those methods would be useful altogether, but an isEnabled() method would be nice to have at the interface level, an AuthenticationProviderInterface implementation that does not uses core entity could want to propagate this information as well.

Moreover, under certain scenarios, it's an information that may be required for some business code in order to proceed to access checks. And since the authentication provider can return a non-core-entity user, it might be nice to have it directly on the top level interface.

UserInterface::id(), AccountInterface::id() should return int to match typehints

$
0
0

Problem/Motivation

AccountInterface::id()'s typehint states it returns an integer, but this is not true in many (all?) cases. Weakly typed as PHP is, uids stored on AccountProxy, UserSession, UserInterface may return the uid as a string. This prevents strongly typed comparison, e.g. $currentUser->id() === $ownerIdAsInteger, if one is represented as an integer and the other a string. Or, it will fail strict type enforcement if passed to a method which expects an integer.

Steps to reproduce

Proposed resolution

Classes implementing AccountInterface::id() should ensure they return an integer as documented by the the API.

Remaining tasks

Framework manager decision on if a class implementing AccountIinterface::id() should:

  1. Return integers as documented in the API (cast string's returned by the DB layer to int)
  2. Change the API Spec for AccountInterface::id() to return string

Note:
In both cases we appear to need to add |null as well.

User interface changes

None

API changes

Data model changes

None

Release notes snippet

Move AccountInterface out of Session namespace

$
0
0

Problem/Motivation

As of #2347799: Remove bugged session-related methods from AccountInterface the AccountInterface does not have any session related methods anymore. In addition #2345611: Load user entity in Cookie AuthenticationProvider instead of using manual queries removes the usage UserSession from production code entirely.

Proposed resolution

Move the AccountInterface and AnonymousUser to \Drupal\Core\Authentication interface. Replace UserSession with a User entity in the remaining test code.

Remaining tasks

approve change
commit

User interface changes

no

API changes

  • Move \Drupal\Core\Session\AccountInterface to \Drupal\Core\Authentication\AccountInterface, but leave a deprecated subinterface thereof at the old place.
  • Move \Drupal\Core\Session\AnonymousUserSession to \Drupal\Core\Authentication\AnonymousUser.
  • Remove \Drupal\Core\Session\UserSession and replace it with user entity #2345611: Load user entity in Cookie AuthenticationProvider instead of using manual queries.
  • Move \Drupal\Core\Session\AccountProxy to \Drupal\Core\Authentication\AccountProxy
  • Move \Drupal\Core\Session\AccountSwitcher to \Drupal\Core\Authentication\AccountSwitcher

Follow-up to #2347799: Remove bugged session-related methods from AccountInterface

Use AccountProxyInterface instead of AccountInterface

$
0
0

Problem/Motivation

The currentUser method, in ControllerBase class, provides the return type \Drupal\Core\Session\AccountInterface rather then the expected \Drupal\Core\Session\AccountProxyInterface

Proposed resolution

Correct the return type hint, even for the currentUser property

Remaining tasks

Update the ControllerBase class comments related to currentUser property and currentUser method.
Update all accessors of currentUser method.

Add declare(strict_types=1) to all Functional tests

$
0
0

Problem/Motivation

This is a child issue of #3399413: [meta] Fix strict type errors in functional tests. After fixing strict type issues we can add the strict_types declaration to all Functional tests.

Steps to reproduce

Add to phpcs.xml.dist:

<rule ref="SlevomatCodingStandard.TypeHints.DeclareStrictTypes">
    <properties>
      <property name="spacesCountAroundEqualsSign" value="0" />
    </properties>
    <include-pattern>*/tests/src/Functional/*</include-pattern>
    <include-pattern>./tests/Drupal/FunctionalTests/*</include-pattern>
  </rule>

Run phpcs:

composer phpcs

Proposed resolution

Run phpcbf:

composer phpcbf

Remaining tasks

Postponed on #3399413: [meta] Fix strict type errors in functional tests

User interface changes

API changes

Data model changes

Release notes snippet

Overview menu missing in all admin menus

$
0
0

Problem/Motivation

Overview menu missing after upgrading drupal 9.5 to 10.2.2
Only local images are allowed.
Only local images are allowed.

Steps to reproduce

After upgrading, check your admin menus. overview menu missing in list

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Fix strict type errors in Functional tests: Add casts and fix types where needed

$
0
0

Problem/Motivation

See parents.

This issue is for:

  • adding explicit (string), (int) and (bool) casts
  • fixing incorrect type declarations
  • fixing incorrect hardcoded values (floats to ints, ints to bools, etc)

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

[meta] Fix strict type errors in functional tests

$
0
0

Problem/Motivation

This is a child issue of #3376057: [META] Add declare(strict_types=1) to all tests. After adding enabling strict types to all tests there were around 3000 errors. Fixing them all in one issue will lead to an enormous merge request that's difficult to review, as per the issue scope guidelines.

Steps to reproduce

See #3399746: Add declare(strict_types=1) to all Functional tests

Run the test suite:

./vendor/bin/phpunit -c core/phpunit.xml.dist --bootstrap=core/tests/bootstrap.php --testsuite=functional

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

UI fatal caused by views argument handlers no longer can provide their own default argument handling

$
0
0

Problem/Motivation

Some argument handlers provide their own default argument handling, like the Date argument. The Date argument handler does so by extending the list of of options in the defaultArgumentForm. An exception is however thrown on saving the form.

Steps to reproduce

  • Create a new view /admin/structure/views/add using (node) content
  • Under advanced tab, add new Contextual filter, select Created date (node.created)
  • On "When the filter value is not available", select "Provide default value", on the drop-down select "Current date".
  • Try to submit this form.

Result: A fatal error occurred on dblog: Drupal\Component\Plugin\Exception\PluginNotFoundException: The "date" plugin does not exist.

Proposed resolution

Get the date handlers in line with the other default argument handlers.
Add a 'Current date', a "Current node's creation time" and "Current node's update time" default argument handler.

Remaining tasks

  • Add a follow-up for improving caching - see #114
  • Add a follow-up to make this work for all entity-types using a deriver - see #176
  • Confirm if this works with date time range fields - see #157

User interface changes

API changes

Data model changes

Release notes snippet

Problem

Steps to reproduce:

Proposed resolution

Omitting $start in entityQuery->range() does not return full result set

$
0
0

Problem/Motivation

There is a discrepancy between the documentation of the entityQuery ::range() method and its observed behavior.

The documentation says that if the $start parameter is omitted, the range should be reset (and hence should return the full result set):

  /**
   * Defines the range of the query.
   *
   * @param int|null $start
   *   (optional) The first record from the result set to return. If NULL,
   *   removes any range directives that are set.
   * @param int|null $length
   *   (optional) The maximum number of rows to return. If $start and $length
   *   are NULL, then a complete result set will be generated. If $start is
   *   not NULL and $length is NULL, then an empty result set will be
   *   generated.
   *
   * @return $this
   */
  public function range($start = NULL, $length = NULL);

However, in the current implementation, when $start is NULL, and $length is set, the full result set is NOT returned. Instead it returns the number of results passed in $length.

We should either update the documentation to match the existing behavior, or change the behavior.

Steps to reproduce

\Drupal::entityQuery('field_storage_config')->range(NULL, 1)->execute();

Expected result: all records are returned.
Actual result: 1 record is returned.

Proposed resolution

We should either fix the implementation, or change the documentation to match the existing behavior.

Updating the documentation is probably the best solution since it will not affect existing projects.

Remaining tasks

Decide on a solution and implement.

User interface changes

API changes

Data model changes

Release notes snippet

Remove calls to clearstatcache in \Drupal\Tests\file\Functional\FileFieldRevisionTest::testRevisions

$
0
0

Problem/Motivation

The function signature for clearstatcache is clearstatcache(bool $clear_realpath_cache = false, string $filename = ''): void but in FileFieldRevisionTest::testRevisions it is called 4 times with only a string file URI.

Since these filename strings would be truthy that would be equivalent of passing TRUE for the $clear_realpath_cache argument, meaning we are clearing the entire stat cache and realpath cache 4 times!

Moreover, there is a todo comment above these calls that suggests the calls should not be necessary:

// TODO: This seems like a bug in File API. Clearing the stat cache should
// not be necessary here. The file really is deleted, but stream wrappers
// doesn't seem to think so unless we clear the PHP file stat() cache.

The test still passes after removing these calls, so that confirms they are not necessary.

Steps to reproduce

Proposed resolution

Remove calls to clearstatcache

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Viewing all 296285 articles
Browse latest View live


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