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

[META] Run PHPStan on Drupal core

$
0
0

Using PHPStan can improve the code quality of Drupal core.

This issue can be used to track progress on cleaning up all PHPStan errors found in Drupal Core.
PHPStan runs in different levels, the plan is to go up each level, and fix errors one level at a time.

PHPStan has a baseline to add, so we can go up a level, and by that moment disallow new errors from that level to enter the codebase, and add all the existing errors to the baseline so they can be fixed afterwards.

Start using phpstan

Add and configure phpstan in core

#3178534: Start running PHPStan on Drupal core (level 0)
#3259142: PHPStan commit check fails if a file is deleted
#3259353: Run full phpstan on composer change
#3259355: Always do a full phpstan analysis on DrupalCI

PHPStan ignored errors and files

To allow PHPStan to be added to core it was decided to ignore some files throwing problems and also ignore some errors. Those should be revisited.

excludePaths:
    # Skip settings.
    - ../*/settings*.php
    # Skip test fixtures.
    - */tests/fixtures/*.php
    # Below extends on purpose a non existing class for testing.
    - modules/system/tests/modules/plugin_test/src/Plugin/plugin_test/fruit/ExtendingNonInstalledClass.php
    # @todo files below need to be excluded as they prevent baseline generation.
    # Fixing them is a priority.
    - modules/link/tests/src/Kernel/LinkItemTest.php

  ignoreErrors:
    # new static() is a best practice in Drupal, so we cannot fix that.
    - "#^Unsafe usage of new static#"

    # Ignore common errors for now.
    - "#^Access to an undefined property#"
    - "#^Call to an undefined method#"
    - "#^Cannot unset offset#"
    - "#should return .* but return statement is missing#"
    - "#Drupal calls should be avoided in classes, use dependency injection instead#"
    - "#^Plugin definitions cannot be altered.#"
    - "#^Missing cache backend declaration for performance.#"
    - "#cache tag might be unclear and does not contain the cache key in it.#"
    - "#^Class .* extends @internal class#"

#3254966: PHPStan error LinkItemTest
#3259110: Fix undefined variables where files are included
#3259109: Fix 'Cannot unset offset' PHPStan L0 errors
#3259716: Replace usages of static::class . '::methodName' to [static::class, 'methodName']

Upstream issues to followup

We already found some improvements / false positives. The should be fixed upstream and updated when a new release is available for phpstan / phpstan-drupal.

* Function twig_escape_filter not found #310

message: "#^Function twig_escape_filter not found\\.$#"
			count: 1
			path: lib/Drupal/Core/Template/TwigExtension.php

* BrowserTestBaseDefaultThemeRule ignore InstallerExistingConfigTestBase tests #311

message: "#^Drupal\\\\Tests\\\\BrowserTestBase\\:\\:\\$defaultTheme is required\\. See https\\://www\\.drupal\\.org/node/3083055, which includes recommendations on which theme to use\\.$#"
			count: 1
			path: modules/quickedit/tests/src/FunctionalJavascript/QuickEditJavascriptTestBase.php

* RenderCallbackRule causes error in PlaceholderGenerator #303

message: "#^The \"\\#lazy_builder\" expects a callable array with arguments\\.$#"
			count: 1
			path: lib/Drupal/Core/Render/PlaceholderGenerator.php

PHPStan level 0

Review the baseline and check for issues to be created.
https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/phpstan-bas...

One of the most occuring problems in the baseline is
Call to deprecated constant REQUEST_TIME (133 of 230 lines in baseline)
#2902895: [meta][no patch] replace uses of REQUEST_TIME and time() with time service

PHPStan level 1 (and up)

Decide when to go a level up? Does the baseline needs to be fully clean?
#3190406: Update PHPStan to level 1


Fix Drupal 7 .htaccess to protect .orig and .save files from view

$
0
0

Add a missing pipe between .orig and .save extentions

Let the administrator choose the fallback region for the "Social Bar" block

$
0
0

The block in the "Social Bar" region appears at the bottom of the page on mobile. It would be nice to let the admin choose the fallback region in the theme configuration.

[Ignore] In space (and/or this issue), no one can hear patches scream III

Remove unneeded \Drupal\Tests\filter\Kernel\TextFormatElementFormTest::getUrl()

$
0
0

Problem/Motivation

Looks like \Drupal\Tests\filter\Kernel\TextFormatElementFormTest::getUrl() is unneeded.

The simpletest bit in the comment kinda gives it away already:

    // \Drupal\simpletest\AssertContentTrait needs this for ::assertFieldByName
    // to work.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Make the whole media item clickable in the Media Library field widget

$
0
0

Problem/Motivation

Currently media can be only selected when clicking the checkbox related to it.

Steps to reproduce

Given that a field is using the Media Library widget
When clicking on the media item
Then its checkbox is not checked
But the checkbox has to be checked in order to select the media

Proposed resolution

Make the whole media item clickable in the Media Library

Remaining tasks

  • ✅ File an issue
  • ➖ Addition/Change/Update/Fix
  • ➖ Testing to ensure no regression
  • ➖ Automated unit testing coverage
  • ➖ Automated functional testing coverage
  • ➖ UX/UI designer responsibilities
  • ➖ Readability
  • ➖ Accessibility
  • ➖ Performance
  • ➖ Security
  • ➖ Documentation
  • ➖ Code review by maintainers
  • ➖ Full testing and approval
  • ➖ Credit contributors
  • ➖ Review with the product owner
  • ➖ Release notes snippet
  • ❌ Release

User interface changes

Make media items clickable

API changes

  • N/A

Data model changes

  • N/A

Release notes snippet

  • N/A

View's ResultRow uses deprecated dynamic properties

$
0
0

Problem/Motivation

See parent issue. Dynamic properties on PHP objects is going to be deprecated in the next minor and removed in the next major version of PHP requiring ResultRow to track all properties and provide storage for dynamic data.

Steps to reproduce

Test views in PHP 8.2

php8.2 ./vendor/bin/phpunit -c core core/modules/views/tests/src/Unit/Plugin/query/SqlTest.php
PHPUnit 9.5.11 by Sebastian Bergmann and contributors.

Warning:       Your XML configuration validates against a deprecated schema.
Suggestion:    Migrate your XML configuration using "--migrate-configuration"!

Testing Drupal\Tests\views\Unit\Plugin\query\SqlTest
.........                                                           9 / 9 (100%)

Time: 00:00.054, Memory: 14.00 MB

OK (9 tests, 33 assertions)

Remaining self deprecation notices (26)

  11x: Creation of dynamic property Drupal\views\ResultRow::$id is deprecated
    3x in SqlTest::testLoadEntitiesWithNoRelationshipAndNoRevision from Drupal\Tests\views\Unit\Plugin\query
    3x in SqlTest::testLoadEntitiesWithRelationship from Drupal\Tests\views\Unit\Plugin\query
    3x in SqlTest::testLoadEntitiesWithRevisionOfSameEntityType from Drupal\Tests\views\Unit\Plugin\query
    2x in SqlTest::testLoadEntitiesWithNonEntityRelationship from Drupal\Tests\views\Unit\Plugin\query

  6x: Creation of dynamic property Drupal\views\ResultRow::$entity_second__id is deprecated
    3x in SqlTest::testLoadEntitiesWithRelationship from Drupal\Tests\views\Unit\Plugin\query
    3x in SqlTest::testLoadEntitiesWithRelationshipAndRevision from Drupal\Tests\views\Unit\Plugin\query

  6x: Creation of dynamic property Drupal\views\ResultRow::$vid is deprecated
    3x in SqlTest::testLoadEntitiesWithRevision from Drupal\Tests\views\Unit\Plugin\query
    3x in SqlTest::testLoadEntitiesWithRelationshipAndRevision from Drupal\Tests\views\Unit\Plugin\query

  3x: Creation of dynamic property Drupal\views\ResultRow::$entity_first__revision__vid is deprecated
    3x in SqlTest::testLoadEntitiesWithRevisionOfSameEntityType from Drupal\Tests\views\Unit\Plugin\query

...

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Require Composer 2.3.5 for developing Drupal 10 core

$
0
0

Problem/Motivation

Should we keep composer 1 support in Drupal 10 given that composer 1 itself is "pretty much EOL" (quote from https://blog.packagist.com/deprecating-composer-1-support/)?

Do we even need to change anything in core to drop composer 1 support or nothing to remove?

Is keeping composer 1 support still worth maintaining, given that packages.drupal.org will need to support composer 1 for a while for Drupal 8 and 7 projects?

Proposed resolution

Require Composer 2.3.5, because:

  1. TUF integration for Automatic Updates requires at least 2.3.5.
  2. Non-LTS Composer minors are EOL pretty much as soon as the next minor is available. For example, https://github.com/composer/composer/security/advisories/GHSA-frqg-7g38-... was fixed for 2.1 but not for 2.0. 2.2 has already been released and is an LTS release that will be supported until end of 2023 or later, which means 2.1 is already EOL and not receiving security fixes. Ref composer/issues/10340
  3. Composer 2.2 significantly improves CPU and memory usage, even beyond the improvements that 2.0 brought. If Automatic Updates claims to support 2.1, we'll need to run tests on 2.1 (wasting DrupalCI resources) and might get bug reports that we have to triage from people who run into out-of-memory or timeout errors that we wouldn't have to deal with if we only have to support 2.2.

Remaining tasks

#3265094: Update our composer/composer dev dependency to the required minimum for Automatic Updates is already in. The remaining tasks are:

  1. Decide how to enforce the version requirement on the CLI. Warning? Error? Existing Composer API?
  2. Add a CR explaining the client (platform) requirement of Composer 2 (2.3.5) and what that means. Mention: composer self-update --2
  3. Add a release note.
  4. Handbook documentation updates.

User interface changes

API changes

Data model changes

Release notes snippet

Drupal 10 will require Composer version 2.3.5 or higher. Core developers must update to at least Composer 2.3.5 to work on Drupal core, and site owners may also receive a warning or error about older Composer versions in the future.


Add the MigrationPluginManager to Drupal\migrate\Plugin\migrate\id_map\Sql

$
0
0

Problem/Motivation

In #2876085: Before upgrading, audit for potential ID conflicts we needed to have access to the MigrationPluginManager inside Drupal\migrate\Plugin\migrate\id_map\Sql. To avoid a BC break, we used a singleton behind a protected accessor with a todo to resolve in 9.0.

Proposed resolution

Add the MigrationPluginManager by dependency injection.

Remaining tasks

Do it.

User interface changes

None.

API changes

The Sql class would have a new parameter to its constructor, the MigrationPluginManager.

Data model changes

None.

Add content in tests only when needed

$
0
0

Problem/Motivation

This a followup to #3087061: Move existing assertions of IdConflict page to new test files.

The Upgrade tests adds content for testing the IdConflict form. There are now new tests just for that page and the Upgrade tests should not be adding content before the migration because migrations should run on an fresh install.

Steps to reproduce

Proposed resolution

Remove the creation of content before the upgrade.

This issue was already RTBC when #3259355: Always do a full phpstan analysis on DrupalCI was committed, so update code/phpstan-baseline.neon to allow a few more instances of an existing PHPStan exception. (See #17 and #18 for more details.) The problem comes from a trait that this issue adds in two more places, so this issue does not make it much harder to fix it.

Remaining tasks

  • Patch
  • Review
  • Reroll
  • Commit

User interface changes

API changes

Data model changes

Release notes snippet

Exception trace cannot be serialized because of closure

$
0
0

Problem/Motivation

Probably something has changed recently either in PHPUnit or somewhere else and we started seeing different issues related to serialization in tests. This particular issue was reported by @quietone in #3192893: [META] Serialization issues in Migration tests, which is now a meta task.

The issue is the following:

If the test is failing with exception, then PHP is trying to serialize a stack trace, which contains functions, methods, classes that have been executed. One of these functions is recognized as Closure (in other words it's anonymous function) in the stack trace (see the screenshot).

exception trace

This happens because we have array_walk() inside array_walk(), so the deepest one is executed inside the closure.

PHPUnit has a related issue. In that issue it is said that the solution is to not call assertions in a closre. Later comments give examples of the problem which do not include closures and finally a fix is provided by mpyw.

Steps to reproduce

Change a query in any source plugin and run the relevant migration test.
For example,
In d6\Term.php change ->orderBy('td.tid'); to ->orderBy('td.foo');

Then run the d6 term test.

phpunit -c core --debug -v --colors=always core/modules/taxonomy/tests/src/Kernel/Migrate/d6/MigrateTaxonomyTermTest.php

You'll see something like:

Drupal\Tests\taxonomy\Kernel\Migrate\d7\MigrateTaxonomyTermTest::testTaxonomyTerms
PHPUnit\Framework\Exception: PHP Fatal error:  Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:80
Stack trace:
#0 Standard input code(80): serialize(Array)
#1 Standard input code(112): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 80
Fatal error: Uncaught Exception: Serialization of 'Closure' is not allowed in Standard input code:80
Stack trace:
#0 Standard input code(80): serialize(Array)
#1 Standard input code(112): __phpunit_run_isolated_test()
#2 {main}
  thrown in Standard input code on line 80
  
/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/AbstractPhpProcess.php:254
/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/AbstractPhpProcess.php:171
/var/www/html/vendor/phpunit/phpunit/src/Framework/TestSuite.php:601
/var/www/html/vendor/phpunit/phpunit/src/TextUI/TestRunner.php:633
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:204
/var/www/html/vendor/phpunit/phpunit/src/TextUI/Command.php:163

Proposed resolution

Add a dependency on mpyw / phpunit-patch-serializable-comparison

There is no way to add a test here because the serialization happens when the test is already executed.

Remaining tasks

Review, commit.
Think about how we can prevent this in the future.

Ignore, testing issue

$
0
0

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Drupal 8 .htaccess rule to prevent php file access can be easily bypassed

$
0
0

Problem/Motivation

.htccess is supposed to prevent executing php files like those in vendor

  # Deny access to any other PHP files that do not match the rules above.
  # Specifically, disallow autoload.php from being served directly.
  RewriteRule "^(.+/.*|autoload)\.php$" - [F]

the .htaccess rule is somehow wrong or incomplete that supposed to prevent execution of php files in the vendor dir, however

/core/vendor/behat/mink/driver-testsuite/web-fixtures/headers.php/1

is executed while

/core/vendor/behat/mink/driver-testsuite/web-fixtures/headers.php

is a 403

Proposed resolution

Fix .htaccess in this issue and move vendor out of webroot in: #2508591: vendor/ is web accessible

Remaining tasks

User interface changes

n/a

API changes

n/a

Data model changes

n/a

originally reported as part of the Drupal 8 bug bounty
https://tracker.bugcrowd.com/submissions/77918e9ef18b0f36f4279efbdb39bf8...

original reporter: DongIT

Use getStorage('taxonomy_term') instead of getStorage('taxonomy_vocabulary')

Refactor Claro's file stylesheet

$
0
0

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the file stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/file.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.


Remove modernizr usages from core

$
0
0

Problem/Motivation

We want to deprecate and then remove modernizr in core.

In order to do that, we need to make sure core isn't reliant on it any more. This includes any JavaScript dependencies on it, as well as any CSS relying on markup it adds.

The actual deprecation of the library itself can be left to #3239980: Deprecate Modernizr.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Refactor Claro's container-inline.module stylesheet

$
0
0

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the container-inline.module stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/container-inline.module.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.
Please post before/after screenshots and make sure they look the same.

Refactor Claro's container-inline stylesheet

$
0
0

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the container-inline stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/container-inline.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

Refactor Claro's form--field-multiple stylesheet

$
0
0

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the form--field-multiple stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/form--field-multiple.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

Refactor Claro's autocomplete-loading.module stylesheet

$
0
0

Problem/Motivation

This is part of the CSS modernization initiative, and intended to be worked on by our Google Summer of Code student only. This is intended to be a straightforward second issue to easily onboard the student.

The first issue was regarding the autocomplete-loading.module stylesheet.

Steps to reproduce

The stylesheet at https://git.drupalcode.org/project/drupal/-/blob/10.0.x/core/themes/claro/css/components/autocomplete-loading.module.pcss.css needs to be refactored to make use of modern CSS and Drupal core's PostCSS tooling.

Proposed resolution

Use CSS Logical Properties where appropriate
Use CSS nesting where appropriate

Remaining tasks

We need two patches. One for Drupal 9.5.x and one for Drupal 10.0.x
We need a followup issue to refactor this component in Drupal 10.0.x to make use of component-level CSS custom properties.

User interface changes

None. There should be no visual differences.

Viewing all 296553 articles
Browse latest View live


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