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

Prefer to replace minimist with util.parseArgs() from CSS building script

October 16, 2024, 3:53 am
$
0
0

Problem/Motivation

Current Node.js can parse command-line arguments with util.parseArgs().
/core/scripts/css/postcss-build.js uses minimist library to parse arguments but command-line arguments uses only for specific file building or script checking flag. I think Node.js native function seems to be enough for Drupal core.

Proposed resolution

Remove minimist from devDependencies in /core/package.json and use Node.js native util.parseArgs().

Note:

The minimist library is not removed from node_modules directory at this point because other libraries require minimist as a dependency.

Remaining tasks

User interface changes

No.

API changes

No.

Data model changes

No.

Release notes snippet

No.

↧
Search

Twig Filter "spaceless" is deprecated

September 27, 2024, 7:34 am
↧
↧

starterkit theme should use same fieldset template than stable9

September 25, 2024, 2:32 am
$
0
0

Problem/Motivation

starterkit theme is using a different fieldset template than stable9 (its basetheme). Especially the fieldset template in starterkit is missing the description display before/after conditionals.

Steps to reproduce

  • use a fieldset element setting description display to before with starterkit and see that the description is displayed at the end.
  • Compare with stable9

Proposed resolution

add the stable9 fieldset template to starterkit

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

↧

CKEditor5 removes commented tags

October 23, 2024, 1:13 am
$
0
0

Hi all,

Our site is in Drupal 10.3.1 and we use CKEditor5 for the text formats (basic, full_html)

When we commented out some HTML tags on the ckeditor and saved the node. The commented tags were not rendered on the page.

When back in to re-edit and all my commented content was removed from the editor.

The comment option is working fine for headings and paragraph tags. But not for <ul><li></li></ul> tags.

Sample #1

<!--<h2>Test Title</h2>-->
<!--<p>Some content</p>-->

This is working fine on the editor. When we back in to re-edit, it appears like this.

Sample #2

<ul>
    <li>
        <a href="https://example.com" target="_blank"><strong>Test 1</strong></a> content
    </li>
   <!--<li>
        <a href="https://example.com" target="_blank"><strong>Test 2</strong></a> content
    </li>
    <li>
        <a href="https://example.com" target="_blank"><strong>Test 3</strong></a> content
    </li>-->
</ul>

when we commented these <li> tags and saved the node. When we back in to re-edit, it appears like the below.

<ul>
    <li>
        <a href="https://example.com" target="_blank"><strong>Test 1</strong></a> content
    </li>
</ul>

Those 2 <li> tags were removed from the editor.

Could anyone please help on this to fix this issue?

Thanks

↧

Remove orphaned (dangling) entity references when an entity is deleted

June 9, 2018, 6:27 am
$
0
0

Problem/Motivation

Entity reference field items are not removed when the referenced entity is deleted.

E.g.

  1. Create taxonomy term with tid 123 "trees".
  2. Create node "pine" with nid 456 tagged with "trees".
  3. Delete the "trees" term. Nid 456 will still be related to tid 123 even though there is no longer such a term.

Mostly this isn't a problem. Some examples where it can cause problems:

  • Search facets with an incorrect count of results.
  • Cryptic error messages when editing entities that contain collapsed Paragraphs.
  • Null fields in GraphQL results (which is invalid GraphQL).
  • Acquia's Cohesion product (see "Why is my Cohesion layout table so large" which points to this issue)

What can I do until a patch has been created?

Why doesn't a fix for this already exist in core?

  • There are scenarios where dangling references shouldn't be automatically cleaned up (if you need a human, or some other system to take action).
  • It's a performance challenge. There may be tens of thousands (or more) dangling references to clean up.

Proposed resolution

In interactive scenarios - like the entity delete confirm form - ask the editor if they want to delete the orphaned references:

  • immediately (default)
  • in the background or
  • don't remove the references at all (not recommended)

In a non-interactive environment (PHP API, REST API) always use the second option.

Remaining tasks

  • Write code
  • ...
  • Profit

User interface changes

New radio group on the entity delete confirmation form (and bulk operations confirm form too?).

API changes

TBD

Data model changes

None

↧
↧

Problem with the q tag

July 2, 2024, 12:48 am
$
0
0

Problem/Motivation

I use the q tag a lot for annotations, captions, etc.
When I insert the q tag, ckeditor 5 adds more every time it encounters another tag.

Steps to reproduce

- I write the text with ckeditor 4.
- I insert the q tag and save.
The source code has not changed:

<p>
<q>Lorem ipsum dolor sit amet consectetuer id velit dui <strong>Quisque </strong>at.<br />
Phasellus <strong>fames </strong>massa Duis urna gravida Nam elit pellentesque tempor <em>pretium</em>.<br />
Consequat id <u>Curabitur </u>sem sem Phasellus et Nulla.</q>
</p>

- I copy the same text into ckeditor 5 and save.
The source code has changed:

<p>
    <q>Lorem ipsum dolor sit amet consectetuer id velit dui <strong>Quisque </strong>at.</q><br>
    <q>Phasellus <strong>fames </strong>massa Duis urna gravida Nam elit pellentesque tempor </q><em><q>pretium</q></em><q>.</q><br>
    <q>Consequat id <u>Curabitur </u>sem sem Phasellus et Nulla.</q>
</p>

I don't know if this is intentional or a bug, but this way I can't apply the css to the q tag correctly.

Is it possible to solve it?

Thanks and best regards

↧

Update 10.3.x to ckeditor5 41.3.2

October 15, 2024, 6:45 am
$
0
0

Problem/Motivation

https://www.npmjs.com/package/ckeditor5/v/41.3.2

This is a backport of a ckeditor5 security release. The security doesn't affect any versions of Drupal because it's to do with the ckeditor5 block editor, but good to not be running a version that is technically vulnerable.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

↧

[random test failure] Drupal\Tests\ckeditor5\FunctionalJavascript\MediaLibraryTest

March 31, 2023, 9:31 am
↧
Search

The configured dialog height is overrided to be auto

October 11, 2024, 11:33 pm
$
0
0

Problem/Motivation

Found in https://www.drupal.org/project/experience_builder/issues/3471978

In dialog.position.js, in the resetSize() function we have the following logic:

          if (
            option === 'height'&&
            event.data.$element.parent().outerHeight() < adjustedValue
          ) {
            adjustedValue = 'auto';
          }

which basically makes the height option function as maxHeight. I think this behaviour is incorrect and also makes it hard to have dialog with iframes in it (because they use the height they have available and not the height it requires, so therefore respecting the set height is better)

I think we just should remove the lines above, and recommend someone to use maxHeight and height = 'auto' instead.

Happy to put this behind a BC option if that makes sense.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

↧
↧

ModuleHandler skips all hook implementations when invoked before the module files have been loaded

April 8, 2021, 8:36 am
$
0
0

Problem/Motivation

Under certain circumstances the module files are not yet loaded.

This happens for example when invoking a hook inside the constructor of a http_middleware service; theses services are constructed very early as a dependency of http_kernel service.

A more concrete example is a middleware service using the entity_type.manager. Most of the times the entity type information is retrieved from cache (stored in the discovery cache bin). When this cache however is missing, hooks like hook_entity_type_build() and hook_entity_type_alter() need to be invoked at this early stage. The modules files however haven't been loaded yet, making ModuleHanlder::verifyImplementations() skip all the hook implementations (silently!). The entity definition cache is then incomplete resulting in various hard to debug (next to impossible) exceptions like #3031598: The "paragraph" entity type did not specify a translation handler. .

Steps to reproduce

Taken from this comment.

  1. Just uninstalled the dblog module from UI here /admin/modules/uninstall
  2. Then open any menu /admin/structure/menu/manage/[menu-name] and I see an error:
    Uncaught PHP Exception Drupal\Component\Plugin\Exception\InvalidPluginDefinitionException: "The "menu" entity type did not specify a "edit" form class." at /core/lib/Drupal/Core/Entity/EntityTypeManager.php line 211
  3. Then click to Flush views cache on another admin page (Flush all caches > Flush views cache via admin menu).
  4. After #3 I can see the error:
    Uncaught PHP Exception Symfony\Component\Routing\Exception\RouteNotFoundException: "Route "entity.path_alias.collection" does not exist." at /core/lib/Drupal/Core/Routing/RouteProvider.php line 206

Why does it happen?

After #3, a lot of items were removed from router table from the database. You have to launch drush cr twice to fix such error.

Proposed resolution

If a hook is invoked before the modules being loaded, load all modules.

Remaining tasks

Update issue summary
Address #12 and #17

↧

Replace use of whitelist/blacklist in core/misc/autocomplete.js and LinkWidget.php

June 12, 2020, 1:15 am
$
0
0

Problem/Motivation

Lets remove usage of "blacklist" and "whitelist" in core/misc/autocomplete.es6.js and core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php. This is likely to need a deprecated BC layer.

They are:

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

Proposed resolution

Convert options.firstCharacterBlacklist to options.firstCharacterDenyList

Remaining tasks

Add deprecations as needed for the javaScript changes
Review

User interface changes

None

API changes

@todo

Data model changes

@todo

Release notes snippet

@todo

↧

Allow tokens to be used in Text Editor/CKEditor 5 image upload directory path

November 24, 2016, 2:24 am
$
0
0

Allow Drupal date tokens to be used in the "Upload Directory" path, much like they are used for the upload path in Image fields of Content Types.

That way instead of inline-images one could have inline-images/[date:custom:Y]/[date:custom:m]

↧

Use DrupalPractice.CodeAnalysis.VariableAnalysis for Kernel and Unit tests

November 29, 2021, 12:45 pm
$
0
0

Problem/Motivation

In #3106216: Remove unused variables from core we introduced the sniff DrupalPractice.CodeAnalysis.VariableAnalysis to detect unused variables in Drupal Core.
To narrow the scope the decision was made to exclude all the test-classes.

This issue is created to make that sniff run without errors on all test-classes.

Steps to reproduce

Proposed resolution

Fix reported errors in Kernel and Unit tests

Remaining tasks

Careful review of the changes to core/modules/migrate/tests/src/Unit/MigrateExecutableTest.php, especially where it is testing an a thrown exception.

User interface changes

API changes

Data model changes

Release notes snippet

↧
↧

Use DrupalPractice.CodeAnalysis.VariableAnalysis on Functional* tests

September 26, 2024, 9:04 pm
$
0
0

Problem/Motivation

Fixes for Functional, FunctionalJavaScript tests and tests in core/profiles.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

↧

Use DrupalPractice.CodeAnalysis.VariableAnalysis in core/tests

September 27, 2024, 1:24 am
$
0
0

Problem/Motivation

Fixes for the sniff in core/tests

Steps to reproduce

Proposed resolution

Remaining tasks

Review

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

↧
Search

BreadcrumbManager ignores cacheability when no builders apply

October 23, 2024, 3:07 am
$
0
0

Problem/Motivation

Since #2719721: BreadcrumbBuilder::applies() mismatch with cacheability metadata, the cacheability of whether breadcrumb builders should apply is now gathered. That's great - but in custom cases where it's possible for no breadcrumb builder to apply, that cacheability is not merged.

Currently core's path-based breadcrumb builder service that the system module provides (system.breadcrumb.default) always applies, but it's a service that can be decorated or removed.

Steps to reproduce

1. Remove the path-based breadcrumb builder service, e.g. by decorating it with a class that doesn't always return TRUE from its applies() method, or by using a service provider's alter method.
2. Visit a path on which it, and no other builder, would apply (e.g. a 404 page).
3. The breadcrumb is now cached as empty, and with no cacheability metadata.
4. Visit another path on which other breadcrumb builders might apply - the cached empty breadcrumb is now used because there was no cache context etc on it, so core assumes it is valid to use.

Proposed resolution

Merge any cacheability immediately after calling every breadcrumb builder's applies() method.

Remaining tasks

Provide test, fix and review.

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

↧

Deprecate comment_uri()

June 2, 2013, 7:28 am
$
0
0

Problem/Motivation

Part of #2010184: [meta] convert ‘uri_callback’ entities param to EntityInterface::uri() method

Current state: the functions is not used after #1970360-78: Entities should define URI templates and standard links

Needs to implement Plugin\Entity\Comment.php uri() method and deprercate comment_uri() function replacing it's calls to $comment->uri() and clean-up Comment annotation uri_callback

1 usage in contrib found http://grep.xnddx.ru/search?text=comment_uri&filename=

Proposed resolution

- deprecate comment_uri() in favor of Comment::toUrl()
- probably it needs to update docs because Comment::permalink() should be deprecated too #2113323: Rename Comment::permalink() to not be ambiguous with ::uri()

Remaining tasks

- add deprecation test
- review, commit

User interface changes

no

API changes

deprecated comment_uri()

Data model changes

no

Release notes snippet

no

↧
↧

ConfigEntity based lists with items containing non-ascii characters are not sorted correctly

May 12, 2014, 8:09 am
$
0
0

Problem/Motivation

Many efforts have been made to make Drupal 8 a great multilingual system. However, content types are never properly sorted when translations contain accentuated characters.

Content types are sorted using asort. Maybe we could set the locale beforehand.

Steps to reproduce

Install Drupal 8
Enable the following modules

  • Configuration Translation
  • Content Translation
  • Interface Translation
  • Language

Add a language (French in the example)
Add a two content types (Show and Zone)
Translate the Show content type to Émission
Switch languages (fr/admin/structure/types)

Expected behavior

To have a list in this order

  • Article
  • Basic page
  • Émission
  • Zone

What happened instead

List was in this order:

  • Article
  • Basic page
  • Zone
  • Émission

Proposed resolution

Use PHP Collator class to sort the items with a fallback when PHP intl extension is not installed

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Dependency evaluation

Symfony polyfill for intl's ICU-related data and classes

Repositoryhttps://github.com/symfony/polyfill-intl-icu
Release cycleSymfony Roadmap
Security policies

Symfony security policies

Symfony generally provides 8 months of security coverage for minor releases other than their LTS version. Two of the Drupal core framework managers (alexpott and larowlan) are members of the Symfony Security Team in order to facilitate backports of security issues that affect supported versions of Drupal when necessary.

Security issue reportingsecurity [at] symfony.com
Contact(s)fabpot, MichaelCu (security)
Other dependenciesnone
↧

Allow per-site configuration of 'Notify user of new account' default setting

October 17, 2024, 11:45 pm
$
0
0

Problem/Motivation

When creating a new user account, you have the option to notify the user of the account, but it defaults to off. The checkbox is easy to miss as it sits underneath roles, and if you forget to check it you can't resend the email (well, you can via the reset password feature but this is pretty unintuitive).

Many sites would prefer the default to be on, so that you could optionally not send the email, but sending the email would be the majority use case for these sites and it saves you a step every time.

Proposed resolution

Many years ago in #691294: Change Notify user of new account default it was proposed to update the default to be on, but this was rejected. Instead of hardcoding it to be off (as now) or on (as proposed then) it would be ideal to have this available as a configuration option in the 'Account settings' so that you could set the default for your site.

Revisited this briefly with xjm who agrees that a global config setting would be good, and core would keep it off by default. But Drupal CMS may opt to enable it by default, since it serves a different use case (and will have HTML email support OOTB!).

Remaining tasks

  1. Agree this is a good idea
  2. Implement the feature
  3. Add tests
  4. Review
  5. Commit

User interface changes

  • New setting at /admin/config/people/accounts for "Enable 'Notify user of new account' setting on user creation by default" (the setting would be disabled by default)
  • If enabled, the 'Notify user of new account' box would be checked by default on the user creation form

Introduced terminology

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

↧

Investigate ModuleHandler::add

October 18, 2024, 8:34 am
$
0
0

Problem/Motivation

After the introduction of ModuleInstaller::invoke() the ModuleHandler::add* method family likely belongs to ModuleInstaller. In the current state it's a total lie: it picks up procedural implementations only because OOP implementations would need a container rebuild. Likely it's loaded only so hook_install can call helper functions in .module. This somehow should be deprecated in favor of static methods in classes.

Steps to reproduce

Proposed resolution

  1. Copy ::add* over to ModuleInstaller, deprecate them in ModuleHandler
  2. Investigate how it would be possible to deprecate all calls to procedural functions and as such deprecate add*.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

↧
Viewing all 296540 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>