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

Extend AddItemToToolbar config action to provide plugin settings

$
0
0

Problem/Motivation

The only way currently to add editor plugin settings is to use simpleConfigUpdate which is a common hack, but technically it is a config entity, not simple config.

Steps to reproduce

See hacky recipes like this:

config:
  actions:
    editor.editor.full_html:
      simpleConfigUpdate:
        settings.plugins.ai_ckeditor_ai.dialog.autoresize: 'min-width: 600px'
        settings.plugins.ai_ckeditor_ai.dialog.height: '750'
        settings.plugins.ai_ckeditor_ai.dialog.width: '900'
        settings.plugins.ai_ckeditor_ai.dialog.dialog_class: ai-ckeditor-modal
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_completion.provider: openai__gpt-4o
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_completion.enabled: true
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_help.enabled: false
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_summarize.provider: openai__gpt-4o
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_summarize.enabled: true
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_tone.autocreate: false
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_tone.provider: openai__gpt-4o
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_tone.tone_vocabulary: ai_tones
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_tone.use_description: 1
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_tone.enabled: true
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_translate.autocreate: true
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_translate.provider: openai__gpt-4o
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_translate.translate_vocabulary: ai_languages
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_translate.use_description: false
        settings.plugins.ai_ckeditor_ai.plugins.ai_ckeditor_translate.enabled: true

Proposed resolution

Extend AddItemToToolbar config action to provide plugin settings

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet


\Drupal\KernelTests\Core\Config\ConfigEntityValidationTestBase::testRequiredPropertyValuesMissing isn't compatible with typed properties

$
0
0

Problem/Motivation

\Drupal\KernelTests\Core\Config\ConfigEntityValidationTestBase::testRequiredPropertyValuesMissing attempts to blindly set all required properties to NULL and assert a validation error.
But if the property being set is typed (i.e enforced at a language level) then setting it to NULL makes the test fail with a TypeError and no way to reuse the base class without overriding the whole method.

Steps to reproduce

Create a config entity with a typed property e.g.

protected string $something

Attempt to add validation tests using \Drupal\KernelTests\Core\Config\ConfigEntityValidationTestBase
see testRequiredPropertyValuesMissing blow up with a TypeError

Proposed resolution

Catch TypeError and move on, validation is provided at the language level

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Remove AccessDeniedHttpException details from log messages

$
0
0

Problem/Motivation

Hi everyone,
I would like to report an issue with Drupal core routing system which provides access to users based on content publishing state. Please be inform that unpublished content on a multilingual website receives an error which is stated below:

Path: /fa/node/1. Drupal\Core\Http\Exception\CacheableAccessDeniedHttpException: in Drupal\Core\Routing\AccessAwareRouter->checkAccess() (line 118 of /var/lib/tugboat/stm/web/core/lib/Drupal/Core/Routing/AccessAwareRouter.php).

Seems that the line refers to the below function: CacheableAccessDeniedHttpException

    if (!$access_result->isAllowed()) {
      if ($access_result instanceof CacheableDependencyInterface && $request->isMethodCacheable()) {
        throw new CacheableAccessDeniedHttpException($access_result, $access_result instanceof AccessResultReasonInterface ? $access_result->getReason() : '');
      }
      else {
        throw new AccessDeniedHttpException($access_result instanceof AccessResultReasonInterface ? $access_result->getReason() : '');
      }
    }

Steps to reproduce

1- Install Drupal 9.3.2 / Drupal 9.3.0 with PHP 8 / PHP 7.3.x
2- Install localization / language module
3- Install secondary language and make the setup multilingual
4- Add a basic page and make it unpublished
5- Browse to the URL with an anonymous user

Proposed resolution

Seems that the issue is related to publish state of the article when multilingual feature is activate. Since I do not have developer side of view to this matter I could not provide a solution. In mean time, I recreated this issue with simplytest.me and advise looking at the screen-shots provided.
Please find the screens as attached.
Thank you.

Allow recipe to add multiple buttons to CKEditor toolbar

$
0
0

Problem/Motivation

When using `addItemToToolbar` currently you can only add a single toolbar item to CKEditor within one recipe. We need something like `addItemsToToolbar` that would accept an array of items.

Proposed resolution

Make the existing plugin support an addItemsToToolbar variant which is merely a pluralized version of the actual action, requiring you to pass an indexed array of toolbar items to add.

API changes

New config action, but essentially the same as the existing config action.

Regression: "Display the file download URI" on related file entity shows relative path

$
0
0

Problem/Motivation

After #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it fix, FileUriFormatter is not returning absolute URL.
As per the change record file_create_url() is supposed to be moved to \Drupal::service('file_url_generator')->generateAbsoluteString($uri)

Instead of that, it is updated with $this->fileUrlGenerator->generateString($uri)

That sounds the root cause of the regression.

Steps to reproduce

Check the FileUriFormatter before #2669074: Convert file_create_url() & file_url_transform_relative() to service, deprecate it and after the fix.

Proposed resolution

Fix the incorrect change and replace with correct method.

Remaining tasks

Needs review

User interface changes

N/A

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Original report by @joakland

Following upgrade to Drupal 9.3.0, checking the "Display the file download URI" for a "File: URI" field in Views no longer displays an absolute path; now it displays a relative path.

Only send update notification email when there is an email address

$
0
0

Problem/Motivation

After deleting the email listed under (/admin/reports/updates/settings), each time a cron run is started, the following error is created:
Error sending email (from info@website.de to with reply-to not set)

Steps to reproduce

go to: /admin/reports/updates/settings

  1. Empty the list of email addresses
  2. After the system finds a new update, based on your configuration of "Check for updates" and "Email notification threshold"
  3. Run cron

The error disappears after adding back an Email into the notify list. But will reappear if it the email is delated again.


Doing a single export on update.settings.yml results in: 

notification: 
  emails: 
    - ''



On a different website where this error doesn't appear we get: 

notification:
  emails: { }

Here the notification email was never set.

Proposed resolution

Send update email only if there is an email address.

Remaining tasks

None

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Convert views_ui.module usage of base:$path to user-path:/$path when $path is from user input

Use New installation methods for CKEditor5

$
0
0

Problem/Motivation

CKEditor5 DLL build is deprecated and will be EOL by the end of 2025 (https://ckeditor.com/docs/ckeditor5/latest/updating/nim-migration/migrat...).

The DLLs will be supported until the end of 2025.

What we will sunset on this date:

  1. The documentation for DLLs will be removed.
  2. New versions of npm packages published after this date will not have build directory. It will not be possible to import files from those destinations.

Steps to reproduce

Proposed resolution

Use the new installation method

  • Published in the 42.0.0 version (released July 2024).
  • Provide many improvements: work well with all modern bundlers (i.e. bundler-agnostic), decoupled styles from the JavaScript layer.
  • Two ways of self-hosted setup:
  • Two ways of cloud (CDN) hosting:

Remaining tasks

Decide whether to use UMD globals/ESM
Decide whether to keep webpack or use a different bundler
Migrate the import paths in ckeditor5 plugins
Update ckeditor5 libraries assets

User interface changes

Introduced terminology

API changes

Since the new installation method is not compatible with the DLL build, contrib modules need to provide plugins with the new installation method. I'm not sure how we're gonna handle this.

Data model changes

Release notes snippet


Regression: Drupal.displace() not working on new Navigation module in 11.2

$
0
0

Just pulled the latest 11.x so I could checkout the top bar.

Drupal.displace() is not running on the sidebar anymore. I checked 11.1, and it it works great there.

Doing a bit of debugging, and it looks like the JS can't find the displace element to add the appropriate attribute to.

Defining the Drupal 8 frontend gate

$
0
0

Problem/Motivation

Core changes must pass through a series of "gates" to ensure their quality is up to standards. Gates are essentially "checklists" that can be used to evaluate a patch's readiness, by both developers and patch reviewers/core committers. The currently documented gates are missing frontend specific requirements for changes.

Proposed resolution

I've started preparing the frontend gates by documenting what the committer team has been enforcing for now.

DescriptionWhen is this needed?DetailsResources

Coding standards

Changes to CSS or JavaScript

There are linters to ensure all of the CSS and JavaScript code follows Drupal coding standards.

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

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

BEM

Changes to classes or CSS

All new classes and selectors should take into account the BEM guidelines. Refrain from using overqualified selectors, for example, a.link should be just .link.

http://getbem.com/

Backwards compatibility

Changes in preprocess functions, templates or CSS

Most changes to markup or CSS will be considered as BC-breaking. Drupal core Stable and Classy themes are backward-compatible. Changes to non-backward compatible themes (e.g. Seven, Bartik) are preferable.

https://www.drupal.org/core/d8-bc-policy#themes

https://www.drupal.org/core/d8-frontend-bc-policy

Browser compatibility

Changes to markup, CSS or JavaScript

Drupal core promises to support a set of browsers. When making any changes to markup, CSS or JavaScript, ensure that the change is compatible with all supported browsers.

https://www.drupal.org/docs/8/system-requirements/browser-requirements

JavaScript Transpilation

Changes made to JavasScript

All patches with changed files must include an ES5 transpilation of ES6 code.

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

JavaScript selectors

Changes to selectors used in JavaScript

When attaching JavaScript to markup, it should be done using either js- prefixed classnames or data-drupal-selector data attribute.

https://www.drupal.org/project/drupal/issues/2431671

Existence check for JavaScript object and it's property across multi-lines can replace with optional chaining

$
0
0

Problem/Motivation

This issue is almost similar to #3492582: Replace some of obj && obj.prop with optional chaining.
In #3492582, some of obj && obj.prop in a single line was replaced with optional chaining but in multi-lines were partially. There is replaceable obj && obj.prop exist.
For example, checks object and its prop existence with below code in the /core/modules/big_pipe/js/big_pipe.js.

node.nodeType === Node.ELEMENT_NODE &&
  node.nodeName === 'SCRIPT'&&
  node.dataset &&
  node.dataset.bigPipeReplacementForPlaceholderWithId &&
  typeof drupalSettings.bigPipePlaceholderIds[
    node.dataset.bigPipeReplacementForPlaceholderWithId
  ] !== 'undefined',

If uses optional chaining expression, this code can makes code more shorter like below.

node.nodeType === Node.ELEMENT_NODE &&
  node.nodeName === 'SCRIPT'&&
  node.dataset?.bigPipeReplacementForPlaceholderWithId &&
  typeof drupalSettings.bigPipePlaceholderIds[
    node.dataset.bigPipeReplacementForPlaceholderWithId
  ] !== 'undefined',

Proposed resolution

Use optional chaining same as #3492582.

Remaining tasks

TBD

User interface changes

API changes

Data model changes

Release notes snippet

Introduce theme negotiator for mail and use it in mail manager

$
0
0

Problem/Motivation

Part of #1803948: [META] Adopt the symfony mailer component but benefits the current mail system as well. Also see #2621018: Support rendering from a manually specified theme for why we need this no matter how the mail building part is going to look in the future.

Steps to reproduce

Proposed resolution

Implement a mail theme negotiation mechanism following the pattern already known from core page theme negotiation and provide a way to execute a closure inside the scope of the negotiated mail theme.

  1. Add a Drupal\Core\MailTheme\MailTemplateId value object. The mail template id unambiguously identifies the email to be sent in the current mail manager based mail system. In addition it is forward compatible with mail templates of a different kind in the upcoming mail API based on Symfony mailer.
  2. Add a Drupal\Core\MailTheme\MailThemeManager with one method: executeInMailTheme(MailTemplateId $templateId, callable $function)
  3. Add Drupal\Core\MailTheme\MailThemeNegotiator which works analogous to theme negotiation
  4. Add Drupal\Core\MailTheme\DefaultNegotiator with a low priority which falls back to the configured theme.
  5. Switch the theme before building / sending mails from within plugin.manager.mail

This is basically cherry-picking from contrib Mailsystem.

Other approaches

Some attempts were made in the past to allow specify the theme to be used for rendering (with no resolution yet):

The Drupal Symfony Mailer project implemented this functionality in a more flexible way. However, since it is reusing patterns unique to that module, the mechanism isn't easily portable to current core architecture.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Javascript asset version disclosure

$
0
0

Problem/Motivation

We have several sites that are scanned by Invicti / Netsparker to identify potential security concerns.
They repeatedly have the following finding:

Invicti Enterprise identified a version disclosure (Jquery) in the target web server's HTTP response.This information can help an attacker gain a greater understanding of the systems in use and potentially develop further attacks targeted at the specific version of Jquery (or other javascript libraries).

After reaching out to find what they are referring to, it is this

<script src="/core/assets/vendor/jquery/jquery.min.js?v=3.7.1"></script>
  <script src="/core/misc/touchevents-test.js?v=10.4.5"></script>
  <script src="/core/assets/vendor/backbone/backbone-min.js?v=1.6.0"></script>

It is a "Low" severity described here.

Steps to reproduce

  1. Load any Drupal page with JS Aggregation disabled, or install.php or update.php regardless of JS aggregation enabled
  2. View the source of the page
  3. Observe script tags for javascript files that reveal the version of the file as "?v=nn.nn"

Proposed resolution

This version identification is baked into core's JsCollectionRenderer::render(). The current approach makes it easy to debug as well as making sure that versions get locally cached appropriately with minimal extra bandwidth needed for unnecessary downloads. We could hash the version to make it undisclosed but still prevent unnecessary downloads.
The end result would have them looking something like this

<script src="/core/assets/vendor/jquery/jquery.min.js?hv=Myta2hC6"></script>
  <script src="/core/assets/vendor/underscore/underscore-min.js?hv=OoQsK9Dv"></script>
  <script src="/core/assets/vendor/once/once.min.js?hv=1R5uyUBY"></script>

This change may not ever be something that gets merged to core, but could live as a patch here for those of us that need to prevent version disclosure.

Remaining tasks

User interface changes

None

Introduced terminology

API changes

None

Data model changes

The query parameter v for 'version' would be come hv for 'hashed version'.

Release notes snippet

Can't run tests if password contains /

$
0
0

Problem/Motivation

If a mysql password contains a slash (or presumably other special characters), you can't run tests from the command line. Instead you get an error like this:

1)
Drupal\Tests\rs\Kernel\Form\PurgeBlockFormTest::testPrefixInvalidationsData
InvalidArgumentException: Minimum requirement: driver://host/database

That error ultimately maps back to: Drupal\Core\Database\Connection:: createConnectionOptionsFromUrl ():

  public static function createConnectionOptionsFromUrl($url, $root) {
    $url_components = parse_url($url);
    if (!isset($url_components['scheme'], $url_components['host'], $url_components['path'])) {
      throw new \InvalidArgumentException('Minimum requirement: driver://host/database');
    }

Compare these two string:

  • 'mysql://my_user:SOMEPASS@my.db.host.name:3306/my_db_name' - parse_url() properly parses
  • 'mysql://my_user:SOME/PASS@my.db.host.name:3306/my_db_name' - parse_url() fails to process

^ Now while this may be a little bit obvious when you explicitly pass a --dburl into run-tests.sh, when it's loading the default password from a settings.php file, it becomes less obvious what is happening there.

Proposed resolution

As it may be hard to accurately parse that string (hence the native parse_url() function being unable to do it), it might just be worth noting in the settings.php file, and possibly the UI when you're setting up a new site/password, that /'s may not work with PHPUnit tests. Alternatively, modifying the exception message (Minimum requirement: driver://host/database) to include some sort of notice about passwords containing special characters, would probably make sense as well.

Note: I've only tested this on D8.9 (not on D9 yet). I'm unsure if the removal of simpletest from core renders this bug moot or not. But it does appear the code is the same in D9, so a slightly more expressive error message probably wouldn't hurt in either case.

Remaining tasks

Approve exception saying.

User interface changes

TBD

API changes

None

Data model changes

None

Release notes snippet

TBD

Settings is not a valid render array in navigation module

$
0
0

Problem/Motivation

Having both core Navigation module and contrib Modifiers module enabled causes an error.

The change in #3443810: Custom Navigation logo is disconnected from new Layout template introduced a 'settings' array without a preceding '#'. When the Modifiers module attempts to process this array in a template_preprocess_layout() function it causes an error in Element::children() as settings is not a valid render array.

Steps to reproduce

  1. Enable Modifiers module
  2. Enable Navigation module
  3. Observe error: InvalidArgumentException: "hide_logo" is an invalid render array key. Value should be an array but got a boolean. in Drupal\Core\Render\Element::children() (line 102 of core/lib/Drupal/Core/Render/Element.php).

Proposed resolution

I think the output of doBuildNavigation() should be a valid render array so properties such as 'settings' should have a '#' to indicate they are not intended to be rendered directly.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet


Package Manager's direct-write mode still tries to check for rsync

$
0
0

Problem/Motivation

In direct-write mode, it should be possible to configure an invalid path to rsync and Package Manager should not have a problem with that, since rsync is not used in direct-write. However, you will get a validation error because Package Manager forgets to bypass a Composer Stager precondition that checks for rsync.

Steps to reproduce

Set up Package Manager in direct-write mode (Project Browser just implemented support for it) and configure a random path in package_manager.settings:executables.rsync. It'll fail.

Proposed resolution

Bypass the PhpTuf\ComposerStager\API\Precondition\Service\RsyncIsAvailableInterface used by Composer Stager. Package Manager already has the infrastructure to do this.

Remove support for PHPUnit 10

$
0
0

Problem/Motivation

Placeholder to remove PHPUnit 10 when the right time comes.

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Introduce support for PHPUnit 12

$
0
0

Problem/Motivation

PHPUnit 12 was released in Feb 2025.

The most complex prep for Drupal to support it is converting all tests from using annotations to use attributes for the test metadata.

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Add Cristina Chumillas as UX Manager, Emma Horrell as provisional UX Manager to Drupal core

$
0
0

Problem/Motivation

#3520973: Add UX Manager as a new core maintainer role landed. Emma Horrell is a UX Manager at the University of Edinburgh ( https://edwebprofiles.ed.ac.uk/profile/emma-horrell). She has been doing great work on UX research at the Drupal CMS project and would be an amazing addition to Drupal core as a UX Manager too.

Steps to reproduce

Proposed resolution

Add Emma Horrell as a UX Manager to Drupal core.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Template preprocess functions are called for multiple scenarios

$
0
0

Please adjust the title if required.

I found out that template_preprocess_HOOK functions are called for multiple scenarios.

For example the issue I ran into:

I defined a template using a theme.layouts.yml file:

comment:
  label: Comment layout
  category: Custom
  template: templates/layouts/comment
  regions:
    user:
      label: User
    content:
      label: Content

When this layout is being rendered, the template_preprocess_comment functions is called in the comment module resulting in a fatal error.

($comment = $variables['elements']['#comment']; There is no such thing.)

While this might be the desired behaviour. I feel the outcome here is wrong.

Kind regards,
Harings Rob

Viewing all 295293 articles
Browse latest View live


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