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

Use of Symfony Expression Language "Expression" in OptimizedPhpArrayDumperTest doesn't match library

$
0
0

Follow-up to #2747083: drupal/core-dependency-injection wrongly requires symfony/expression-language

Problem/Motivation

If you install the Expression Language library from symfony the test suite fails.

Missing argument 1 for Symfony\Component\ExpressionLanguage\Expression::__construct(), called in /.../core/tests/Drupal/Tests/Component/DependencyInjection/Dumper/OptimizedPhpArrayDumperTest.php on line 577 and defined
 /.../vendor/symfony/expression-language/Expression.php:28
 /.../core/tests/Drupal/Tests/Component/DependencyInjection/Dumper/OptimizedPhpArrayDumperTest.php:577

Note: this constructor has always been this way, the Mock object was just made as small as possible and an emergent bug was created.
https://github.com/symfony/expression-language/blob/2.4/Expression.php

Proposed resolution

Pass an argument to the Expression constructor and provide a empty constructor with an argument to ensure new tests don't make the same mistake.

API changes

n/a tests

Data model changes

n/a tests


Fix 'Cannot unset offset' PHPStan L0 errors

$
0
0

Problem/Motivation

PHPStan is currently ignoring #^Cannot unset offset# errors.

Proposed resolution

Fix the issues and remove the ignore.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Fix undefined variables where files are included

$
0
0

Problem/Motivation

PHPStan has identified possible undefined variables in cases where we include files, in the color module and the transliteration component. This is because the variables are set inside the included files, but PHPStan cannot be sure this is happening.

Steps to reproduce

Proposed resolution

Set default values for the variables before including the file.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Update JavaScript dependencies for 10.x-alpha

$
0
0

Problem/Motivation

Makes the BC compatible updates (according to semver).

Steps to reproduce

yarn outdated

Proposed resolution

yarn upgrade
yarn upgrade-interactive and do the minor version upgrades...

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Remove support for EasyRDF 0.9

$
0
0

Problem/Motivation

In #3110972: Update easyrdf library to 1.0.0 we added support for EasyRDF 1.0 while keeping backward compatibility with 0.9.

In Drupal 10, we can remove support for EasyRDF 0.9 and only support the 1.0 version.

Steps to reproduce

Proposed resolution

Remove code that supports EasyRDF 0.9 and tighten the dependency constraint.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Fix code base for known deprecation

$
0
0

Problem/Motivation

Several depracated codes found:

 Line   src/Controller/UserController.php                                                                        
  226    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  340    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();  
  Line   src/EventSubscriber/UserRequestSubscriber.php                                                              
  51     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()>getRequestTime();                                                                   
  55     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();  
  Line   tests/src/Functional/UserCreateTest.php 
  41     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  42     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime(); 
  Line   tests/src/Functional/UserEditTest.php 
  95     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime(); 
  Line   tests/src/Functional/UserPasswordResetTest.php  
  74     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.
  Use \Drupal::time()->getRequestTime();
  177    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  184    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  222    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  361    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime(); 
  Line   tests/src/Functional/UserPictureTest.php 
  89     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();  
  Line   tests/src/Functional/UserRegistrationTest.php 
  275    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime(); 
  Line   tests/src/Functional/Views/UserChangedTest.php 
  52     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime(); 
  Line   tests/src/FunctionalJavascript/UserPasswordResetTest.php 
  68     Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0. 
   Use \Drupal::time()->getRequestTime(); 
  Line   tests/src/Kernel/UserLegacyTest.php                                       
  22     Call to deprecated function user_password():                             
         in drupal:9.1.0 and is removed from drupal:10.0.0. Use                   
           \Drupal\Core\Password\PasswordGeneratorInterface::generate() instead. 
  Line   user.module 
  462    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  524    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  557    Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  1146   Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();
  1157   Call to deprecated constant REQUEST_TIME: Deprecated in drupal:8.3.0 and is removed from drupal:10.0.0.  
         Use \Drupal::time()->getRequestTime();

Proposed resolution

Replace deprecated codes to as suggested

Remaining tasks

  1. I will write a patch
  2. Someone else should review

Translation of toolbar button tooltips still not working.

$
0
0

Problem/Motivation

Toolbar button tooltipps are not translated if different language then English is enabled

Steps to reproduce

1. Install Drupal in Englisch via Simplytest.me
2. Enable Interface Translation Local and CKEditor 5
3. Enable Ckeditor 5 in any text format e.g basic HTML
4. Add desired interface language e.g Geman
5. Set the enabled Language to default
6. Change Language Display order so that English is below the new enabled language
7. Click on Manage>> Content >>Add Content >> Article
6. Hover the mouse cursor over any button

Expected result: Tooltips should be displayed in Drupal's default UI Language
Current Result: Tooltips are still displayed in English.
Demo https://www.youtube.com/watch?v=XS-INmiEA8M

Proposed resolution

Find cause

Remaining tasks

find cause
fix
retest
release

User interface changes

Maybe translations on l.d.o are needed

API changes

maybe some

Data model changes

probably none

Release notes snippet

Disable CKEditor 5's automatic link decorators (in Drupal filters should be used instead) + explicitly test manual link decorators

$
0
0

Problem/Motivation

Discovered in #3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!).
See https://ckeditor.com/docs/ckeditor5/latest/api/module_link_link-LinkConf... and https://ckeditor.com/docs/ckeditor5/latest/api/module_link_link-LinkDeco....

Try this by applying

diff --git a/ckeditor5.ckeditor5.yml b/ckeditor5.ckeditor5.yml
index f6eaf90..80467ef 100644
--- a/ckeditor5.ckeditor5.yml
+++ b/ckeditor5.ckeditor5.yml
@@ -224,6 +224,9 @@ ckeditor5_link:
   ckeditor5:
     plugins:
       - link.Link
+    config:
+      link:
+        addTargetToExternalLinks: true
   drupal:
     label: Link
     library: ckeditor5/ckeditor5.link

Now every link you create that matches ^(http|//) will get target="_blank" rel="noopener noreferrer" applied.

This feature makes a ton of sense in CKEditor 5, where the generated HTML is the served HTML. But it does not make sense in Drupal, where we prefer not storing (hardcoding) such decisions in the database, and instead filter it on output, using the filter system.

For this example, the Drupal equivalent is https://www.drupal.org/project/extlink.

Steps to reproduce

See above.

Proposed resolution

  1. Disable CKEditor 5's automatic decorators entirely, both on server (done) and client (TODO).
  2. Add explicit test coverage for manual link decorators, for the drupalImage (done) and drupalMedia plugins in particular (TODO).

Remaining tasks

  1. Discuss with CKEditor 5 team to determine best approach.Done. Conclusion: throwing an exception when automatic decorators are configured, both in PHP and in JS.
  2. Prevent automatic link decorators on server side.
  3. Prevent automatic link decorators on client side.
  4. Test coverage for automatic link decorators being prevented on server side.
  5. Test coverage for manual link decorators working with <img>.
  6. Manual link decorators working with <img>.
  7. Test coverage for manual link decorators working with <drupal-media>.
  8. Manual link decorators working with <drupal-media>.

User interface changes

None.

API changes

None.

Data model changes

None.


Views with exposed filter (ajax enabled) inside modal window only work on first modal open

$
0
0

On one of our current projects we have a view with some exposed filters and ajax enabled that is called inside a drupal modal window.
The exposed filters work while opening the modal for the first time - on the second call the it breaks and nothing happens due to javascript problems.

The issue was already described in #1809958 - i also get the Cannot read property 'top' of null ajax_view.js error, caused by a no longer existing class name (views DOM ID) of the view.

Attached you find a patch solving the issue.

Expose Layout Builder data to REST and JSON:API

$
0
0

Problem/Motivation

When accessing Layout Builder overrides via REST (i.e. when accessing an overridden entity's layout field), the contents of sections are empty.

Proposed resolution

Add a normalizer for the layout_section DataType, which ensures that sections can be properly serialized and unserialized via the serialization API (and REST).

Remaining tasks

N/A

User interface changes

N/A

API changes

A new normalizer will be added for the layout_section DataType.
Layout section data will be exposed for all serialization types.

Data model changes

N/A

longwave patch testing

$
0
0

Problem/Motivation

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Update report should show whether suggested project versions are compatible with recommended core version

$
0
0

Problem/Motivation

#3096078: Display core compatibility ranges for available module updates adds information to the update report: for each extension (module or theme) it indicates whether the suggested version is compatible with the currently installed version of Drupal.

The update report also recommends updating to the latest release of Drupal core.

The update report does not indicate whether the suggested version of each extension is compatible with the recommended version of Drupal core.

Proposed resolution

For each extension listed on the update report, say whether the suggested version is compatible with the recommended version of Drupal core.

Remaining tasks

User interface changes

This will add additional information to the update report (/admin/reports/updates),

API changes

N/A

Data model changes

N/A

Extraneous closing parentheses and curly brace in visually-hidden button description text

$
0
0

Problem/Motivation

The visually hidden text describing a toolbar buttons purpose has unnecessary parentheses and curly braces at the end. The screen readers I tested include the curly brace in their announcement, so this is more than cosmetic

Steps to reproduce

Proposed resolution

Remove that punctuation.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Add checks for 3rd party libraries on Status page.

$
0
0

Problem/Motivation

Many modules depend on 3rd party javascript libraries, that need to be installed independently in site-wide libraries folder. Since those libraries are defined with each module's libraries.info file, we can set up a unified way to check for their presence and report errors on Status page. Now each module takes care of own libraries itself, which leads to duplicated or non-optimal code and extra load on module developers.

Steps to reproduce

Proposed resolution

Add a check for libraries in system_requirements().

Remaining tasks

Review, care for css files as well, write tests.

User interface changes

No.

API changes

No need for module developers to implement hook_requirements in order to check for presence of 3rd party libraries, defined in module.libraries.yml

Data model changes

No.

Release notes snippet

Replace t() with $this->t() in all plugins

$
0
0

Problem/Motivation

When attempting to unit test a widget which extends the StringTextfieldWidget the traditional method of mocking the string translation service fails and an error is produced Call to undefined function Drupal\Core\Field\Plugin\Field\FieldWidget\t().

On further inspection many of the plugins extending PluginBase do not utilize $this when calling t().

Steps to reproduce

1. Extend StringTextfieldWidget
1. Override settingsForm by adding to what parent produces
1. Unit test new class

Proposed resolution

PluginBase is using StringTranslationTrait but many of the child plugins are not utilizing it properly. Use $this->t() instead of t() for string translation calls for all classes extending PluginBase.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Add Alpha level Experimental Automatic Updates module

$
0
0

Please DO NOT push to this branch. See How to Help for instructions for working in the contrib module.

Problem/Motivation

Automatic Updates is one of Drupal Core current strategic initiatives

For full details of the initiative see #2940731: Automatic Updates Initiative overview and roadmap

Currently the work on the module is happening in 8.x-2.x branch of the Automatic Updates contrib module.

This issue is to bring in the current version of the 8.x-2.x branch of the contrib module into core as an Alpha level experimental module.

Proposed resolution

A merge request will be created on this issue that will mirror the 8.x-2.x branch of the contrib module. Because some things in the module will need to be altered to work in core the merge request commits will be created by a conversion script that will change things like the module machine name from automatic_updates to auto_updates

Since this is will be a very large merge request we will continue to create issues and make improvements in the contrib module 8.x-2.x branch and convert that work via the conversion script to commits here. @tedbow or @phenaproxima will make the conversion daily if there are commits to the contrib module.

How to help

Feel free to leave feedback on this merge request. If you would like to help address the feedback please search the 8.x-2.x issue queue to see if any existing issue exists and if not create one in that project.

Remaining tasks

  1. Review the patch
  2. Framework manager sign-off
  3. Release manager sign-off

User interface changes

API changes

Data model changes

Release notes snippet

Avoid hundreds of unnecessary installs when testing config entities

$
0
0

Problem/Motivation

EntityResourceTestBase is subclassed by every entity type in core, which is further subclassed nine times for various REST and HAL tests. It contains four test methods, one for each HTTP verb.

However, when testing config entities, three of these HTTP verbs simply pass immediately:

  public function testPost() {
    // @todo Remove this in https://www.drupal.org/node/2300677.
    if ($this->entity instanceof ConfigEntityInterface) {
      $this->assertTrue(TRUE, 'POSTing config entities is not yet supported.');
      return;
    }
...
  public function testPatch() {
    // @todo Remove this in https://www.drupal.org/node/2300677.
    if ($this->entity instanceof ConfigEntityInterface) {
      $this->assertTrue(TRUE, 'PATCHing config entities is not yet supported.');
      return;
    }
...
  public function testDelete() {
    // @todo Remove this in https://www.drupal.org/node/2300677.
    if ($this->entity instanceof ConfigEntityInterface) {
      $this->assertTrue(TRUE, 'DELETEing config entities is not yet supported.');
      return;
    }

The setup of these tests is still done, but no actual testing is performed. This means that for each config entity type we perform 3 x 9 = 27 installs via BrowserTestBase::setUp() that are immediately thrown away because the test is effectively skipped.

At present there are 31 config entity types (and only 13 content entity types) in core. This means that we are performing 31 x 27 = 837 unnecessary installs during every full test run across core.

Steps to reproduce

Proposed resolution

Split EntityResourceTestBase into a new subclass ContentEntityResourceTestBase for content entities that require all four methods.
Remove all the skipped methods from EntityResourceTestBase keeping only testGet() and supporting methods.
Modify EntityResourceRestTestCoverageTest to ensure both config and content entities are tested correctly.

Revert this patch when #2300677: POST/PATCH config entities via REST for config entity types that support validation lands.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Provide ability to set track_last_imported via configuration

$
0
0

I am not quite sure if this is the right project for this report.

I am running migrations through drush and the last_imported column in the map tables is 0 for all of them.

[Symfony 6] Symfony\Component\HttpKernel\HttpKernelInterface::MASTER_REQUEST is deprecated, use ::MAIN_REQUEST instead

$
0
0

Problem/Motivation

From https://github.com/symfony/http-kernel/blob/5.x/HttpKernelInterface.php#...

    /**
     * @deprecated since symfony/http-kernel 5.3, use MAIN_REQUEST instead.
     *             To ease the migration, this constant won't be removed until Symfony 7.0.
     */
    public const MASTER_REQUEST = self::MAIN_REQUEST;

Steps to reproduce

Proposed resolution

Add an FC (forward compatibility) layer, replace the constant.

Search for related instances of "master" in comments and replace them with "main" at the same time.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

hook_theme_suggestions_HOOK_alter never called for input__textfield

$
0
0

Problem/Motivation

I'm trying to add suggestions for input elements.

Steps to reproduce

Create a theme and implement hook_theme_suggestions_HOOK_alter for an input:

my_theme_suggestions_input_alter() // <= works
my_theme_suggestions_input__textfield_alter() // <= does not work

More info

According to the THEME_HOOK info, the 'input__textfield' hook exists and should be called:

THEME HOOK: 'input__textfield'
FILE NAME SUGGESTIONS:
   * input--textfield.html.twig
   x input.html.twig

While my_theme_suggestions_input_alter() may be fine in most cases, input--textfield.html.twig actually gets a higher priority then suggestions added in the ...input_alter() hook.

Viewing all 297136 articles
Browse latest View live


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