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

Term migrations should set revision IDs

$
0
0

Problem/Motivation

The d6_taxonomy_term and d7_taxonomy_term migrations preserver term IDs (tid) but do not set revision IDs (revision_id). At best, this leads to an odd situation: revision IDs for some terms may be smaller than their entity IDs.

Proposed resolution

Since taxonomy terms in Drupal 6 and Drupal 7 do not support revisions, set the revision ID to the same thing as the term ID.

This is consistent with updating a site to Drupal 8.7+ from an earlier version. The update function seems to set the revision ID to the term ID for existing terms.

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/A


[11.x] [meta] Requirements for tagging 11.0.0-alpha1

[DrupalHtmlEngine] HTML-reserved characters (>, <, &) in <script> and <style> tag are converted to HTML entities

$
0
0

Problem/Motivation

<script> tag
Javascript operators (>, &&, ...) in <script> tag are converted to html entities.

Steps to reproduce

Paste this test code in a <script> tag in ckeditor, you will get a syntax error: Uncaught SyntaxError: Unexpected token ';'. This is caused by the operators that have been converted to html entities: if(y &lt; x){

<script type="text/javascript">
let x = 10;
let y = 5;
if(y < x){
console.log('is smaller')
}
</script>
<style> tag
The site administrators are using the CKEditor 5 FULL HTML text format to provide custom stylings using tags with the source editing. But when the css is used with the '>' syntax, ex:
<style type="text/css">
.sections > h2 {
</style>

the > symbol (the child combinator selector: https://developer.mozilla.org/en-US/docs/Web/CSS/Child_combinator) gets replaced into html entities and shown as

<style type="text/css">
.sections &gt; h2 {
</style>

Nightwatch test job does not fail on WebDriver errors

$
0
0

Problem/Motivation

Both on the Drupal CI and GitLab end of test-things the nightwatch job has (for an unknown period) a WebDriverError in Tests/ckEditor5CodeSyntaxTest.js:

│   Error   Error while running .setElementValue() protocol action: element    │
│   not interactable                                                           │
│   (Session info: headless chrome=106.0.5249.103)                             │
│   (Driver info: chromedriver=106.0.5249.61 (511755355844955cd3e264779baf0d   │
│   d38212a4d0-refs/branch-heads/5249@{#569}),platform=Linux                   │
│   5.4.241-150.347.amzn2.x86_64 x86_64)                                       │

However both environments report that every test passes.

Steps to reproduce

Proposed resolution

Make the total job fail when a WebDriverError occurs.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

CKEditor 5 balloons invisible when CKEditor 5 is used inside a modal

$
0
0

Problem/Motivation

Modal dialogs (such as the link dialog) in the CKEditor 5 WYSIWYG toolbar do not activate when CKEditor is within a modal. This may be a regression of #3274937: Get CKEditor 5 to work in (modal) dialogs

Steps to reproduce

  1. Create a content type (eg: Article) with a Media field that references the Image media type
  2. Add a rich text field to the Image media entity type (eg: Caption) and configure it to use a text format that supports links and uses CKEditor 5.
  3. Add a new node (eg Article) and add a new Image.
  4. Try to link text in the rich text field.

Screen recording trying to link image caption text.

Cause

This is a CSS z-index issue. The z-index of the CK5 balloon modals is 1000. While the z-index of the jQueryUI Dialog modals is 1260. The z-index needs to be set to a minimum of 1261.

Proposed resolution

Fix the bug that is preventing text from being linked.

Remaining tasks

  1. Identify cause of bug
  2. Submit merge request
  3. Test
  4. Get maintainer approval

Fix spelling of some words with 'un' prefix

$
0
0

Problem/Motivation

These words are used in comments, except for unixepoch. There are also only once or twice.

Steps to reproduce

Proposed resolution

  1. unaliased
  2. unallowed
  3. unconfigured
  4. undelayed
  5. undraggable
  6. unextracted
  7. unflagged
  8. unhashed
  9. unhides
  10. unindented
  11. uninstantiatable
  12. uninstantiated
  13. unixepoch This is an SQLite function
  14. unixtimestamp
  15. unkeyed
  16. unmatch
  17. unpermissioned
  18. unpreloaded
  19. unrendered
  20. unshortened
  21. unsimplified
  22. untarring
  23. untrustable

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The entire site crashed after upgrade to D10.2.1

$
0
0

The entire site crashed after being upgraded to D10.2.1 from D10.2

I am in the middle of testing my site of migrating from D7 to D10. Then I was prompted with new update reminder. First I updated Ecommerce on site, then I encounter an error when updating database. But I was able to check status report and other pages. Then I used terminal to upgrade to D10.2.1, the entire site crashed with an error message of "The website encountered an unexpected error. Try again later."

Unable to get to any page, so I cannot provide additional error messages.

This is devastating. I don't know what to do. Although it is not a production site, but with lots of work done here. In addition, it really concerns me that updating modules or core is so unstable, really fear to go to production.

If anyone could help me how to get back to my site, really appreciate!!!!

[10.2 regression] RSS feeds invalid due to &nbsp;

$
0
0

Problem/Motivation

Since upgrading to Drupal 10.2, my RSS feeds have been failing to validate due to &nbsp; non-breaking space tokens.

Validation is failing on: https://validator.w3.org/feed/check.cgi with the following error:

This feed does not validate.

    line 13, column 57: XML parsing error: <unknown>:13:57: undefined entity [help]

        &lt;span&gt;Drupal Advent Calendar day 18 - The Mentoring&nbsp;Initiative&lt ...
                                                                 ^

I use the Typogrify module, which inserts &nbsp; in certain conditions, which makes this problem worse, but there are lots of reasons it might be necessary to have non-breaking spaces in content.

I have looked at the list of changes in 10.2, but haven't spotted any that obviously point to a cause for this.

Steps to reproduce

On both 10.1 and 10.2 test sites, I created a node with "Hello", a blank line, and "Goodbye" using CKEditor, and published the article on both.

I could not test local sites with the above validator, but when I open the 10.1 rss.xml file in Firefox, it displays as valid XML. On opening the 10.2 file, Firefox displays the following:

XML Parsing Error: undefined entity
Location: file:///home/james/Downloads/rss.xml
Line Number 20, Column 258:

Under 10.1, the RSS feed contains the following:

&lt;p&gt;Hello&lt;/p&gt;&lt;p&gt; &lt;/p&gt;&lt;p&gt;Goodbye&lt;/p&gt;

However under 10.2 the feed contains:

&lt;p&gt;Hello&lt;/p&gt;&lt;p&gt;&nbsp;&lt;/p&gt;&lt;p&gt;Goodbye&lt;/p&gt;

The first one contains a space character, while the second contains the &nbsp; token.

Proposed resolution

Identify if this behaviour is caused by a change in 10.2, and whether the new behaviour is intentional. Consider whether the previous behaviour should be reinstated.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Page cache should strip unnecessary data from the response

$
0
0

Problem/Motivation

The page cache caches Symfony responses, this includes cacheabilityMetadata and attachments keys which aren't used by the page cache (cache tags for example are already in the headers).

If we strip these before we set the cache item, we should be able to reduce the size of cache entries, and the insert / get / unserialize might get a bit cheaper too.

Found while trying to figure out #3412641: OpenTelemetryNodePagePerformanceTest::testNodePageHotCache() is not hot enough but this isn't related.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

InvocationMocker::withConsecutive() is deprecated in PHPUnit 9.6 and removed from PHPUnit 10

$
0
0

Problem/Motivation

InvocationMocker::withConsecutive() is removed from PHPUnit 10. It was previously meant to be deprecated in that branch but this commit actually removed it.

In PHPUnit 9.6, using withConsecutive() will yield a deprecation error, https://github.com/sebastianbergmann/phpunit/issues/5035

Therefore the use of the method needs to be replaced.

See https://github.com/sebastianbergmann/phpunit/issues/5063

Steps to reproduce

Proposed resolution

Use this approach. See #61 -> #63.

Also considered, https://github.com/symfony/symfony/commit/431b6ef44c57a45c36146dd440a5f7...

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Support serialization of private properties

$
0
0

Problem

Because DependencySerializationTrait uses get_object_vars() to collect serializable service properties, but that function cannot access private properties. Because of that, the code below fails, because $entityTypeManager becomes null when deserialization happens.

<?php

final class MyForm extends \Drupal\Core\Form\FormBase {

  private $entityTypeManager;

  public function __construct(\Drupal\Core\Entity\EntityTypeManagerInterface $entityTypeManager) {
    $this->entityTypeManager = $entityTypeManager;
  }

  public static function create(\Symfony\Component\DependencyInjection\ContainerInterface $container) {
    return new static(
      $container->get('entity_type.manager')
    );
  }
}

This seems to be a known limitation for 2 years or so: https://www.drupal.org/project/drupal/issues/2727011#comment-12619886

Proposed solution

Use Reflection or Clousers instead of get_object_vars().

Related

https://www.lambda-out-loud.com/posts/accessing-private-properties-php/

PS.: We are using this fix since patch 1 was submitted here in production without noticeable unexpected sideeffects.

ElementInfoManagerInterface::getInfo() should document which properties apply only to forms

$
0
0

Problem/Motivation

The docs for ElementInfoManagerInterface::getInfo() list various standard properties for render element definitions.

This should state that some of them only apply when the element it used in a form, and has no effect when used in a render array.

It's (probably) all the ones that have a $form_state parameter in the callback.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

make it easier to instantiate ConfigImporter

$
0
0

The ConfigImporter needs a ton of services injecting to its constructor.

This is a pain because anything wishing to use it (such as the config UI provided by core's config module, or Drush, or the Config Devel contrib module) has to instantiate that class taking care of getting all the services.

Proposed resoution: add a factory class

Add string context and location filters to the translate interface

$
0
0

Currently we can filter by string, but not by context.

With a context filter you can easily list, for example, all translatable strings in the "Node types" group for some node bundle (e.g. page) by using the "type:page:" context filter.

The use-case which actually prompted this was using the webform localization contrib module, which incorporates the webform node ID into the context of each translatable string. It's really useful to be able to list strings for a specific webform, and omit the others, as things get really crowded really quickly.

Transaction autocommit during shutdown relies on unreliable object destruction order

$
0
0

Problem

Upstream issue: https://bugs.xdebug.org/view.php?id=2222

Drupal does auto-commit transactions on shutdown, as discussed at #1608374: Database autocommit disabling at shutdown. At the moment, quite some code relies on that behavior.

For that to work, Drupal\Core\Database\Transaction::__destruct must run before Drupal\mysql\Driver\Database\mysql\Connection::__destruct. If the order is reversed, this results in nasty fatal errors like the following:

Fatal error: Uncaught Error: Call to a member function inTransaction() on null in /var/www/web/core/modules/mysql/src/Driver/Database/mysql/Connection.php on line 483

Error: Call to a member function inTransaction() on null in /var/www/web/core/modules/mysql/src/Driver/Database/mysql/Connection.php on line 483

Call Stack:
15.7059 86985504 1. Drupal\Core\Database\Transaction->__destruct() /var/www/web/core/lib/Drupal/Core/Database/Transaction.php:0
15.7059 86985504 2. Drupal\Core\Database\Connection->popTransaction($name = 'drupal_transaction') /var/www/web/core/lib/Drupal/Core/Database/Transaction.php:71
15.7059 86985504 3. Drupal\mysql\Driver\Database\mysql\Connection->popCommittableTransactions() /var/www/web/core/lib/Drupal/Core/Database/Connection.php:1447
15.7059 86985880 4. Drupal\mysql\Driver\Database\mysql\Connection->doCommit() /var/www/web/core/modules/mysql/src/Driver/Database/mysql/Connection.php:415

As a result the transaction is not committed. In our project, this suddenly (=zero change) popped up and reliable killed every "drush cr" or simple drush commands like "drush user:unblock".

According to https://www.php.net/manual/en/language.oop5.decon.php the object destruction order during shutdown is random:

PHP possesses a destructor concept similar to that of other object-oriented languages, such as C++. The destructor method will be called as soon as there are no other references to a particular object, or in any order during the shutdown sequence.

Steps to reproduce

Unclear.

We ran into this at drunomics on a rather large project, on CI builds, suddenly without changes to code or the docker-controlled environment. The error only happened during CLI invocations, but was reproducable also without drush.

It turns out that most of the time the object destruction order is correct and no problems arise. But somehow for CLI invocations the order can become reliable different, thus causing the problem.

Proposed resolution

Do not rely on a object destruction order that is a random. Make code work in both situations, regardless which one runs first.

Note: This appear on 10.1.x-dev so first we need to verify whether the problem can happen on 10.2.x-dev as well, since there is a new transaction manager.

Workarounds

- ensure that develop is not in your xdebug.mode value
- pin xdebug in CI image to xdebug 3.2.2

API changes

-

Data model changes

-


claroAutocompleteTest passes, but log shows a 404

$
0
0

Problem/Motivation

core/tests/Drupal/Nightwatch/Tests/claroAutocompleteTest.js passes in our Nightwatch job on GitLab.
Yet, when we look at it's console log in the saved artifact after the test, we see:
"http://localhost/subdirectory/form-test/autocomplete-1?q=123 - Failed to load resource: the server responded with a status of 404 (Not Found)"

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Update Nightwatch to 3.x

$
0
0

Problem/Motivation

We are currently on Nightwatch 2.3.9 but the latest version is 3.0.1.

Proposed resolution

Update to Nightwatch 3.0.1 on Drupal 10.0.x. Evaluate what's the impact of backporting this to 9.4.x since the core Nightwatch is provided as an API by DrupalCI.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The Nightwatch testing library has been updated to version 3.0.1. Reference the Nightwatch developer guide for a list of high-level changes in the 2.0.0 release.

Add option to show only start or end date in the DateTime Range custom formatter

$
0
0

Problem/Motivation

Currently, date range fields are always displayed with start and end date.

There are situations where only one of these values should be displayed, e.g. when creating a view for upcoming events where we only want to show the start date.

Proposed resolution

Add an option to the date range formatter to select both start and end date (default), only start date or only end date.
Show the separator field only when the first option is selected.

Remaining tasks

  • Address patch review in #30
  • Issue Summary update (#75)

User interface changes

Content type display:

Content type display

Views:

Views

API changes

Data model changes

New from_to configuration setting.

Release notes snippet

You can now customize the way date ranges are displayed to match your specific needs. The new display option offers three choices:

  • Start and End Date (Default): This is the default behavior, displaying both the start and end dates in your date ranges, just as you've always seen.
  • Start Date Only: Choose this option to display only the start date in your date ranges. This is perfect for situations where you want to highlight the beginning of an event or a period.
  • End Date Only: Opt for this format if you wish to showcase only the end date in your date ranges. It's ideal when you want to emphasize the conclusion of an event or a time frame.

This new feature offers increased flexibility, making it easier to tailor your date range presentations to your site's unique requirements.

trim(): Passing null to parameter #1 ($string) of type string is deprecated in _responsive_image_build_source_attributes()

$
0
0
Deprecated function: trim(): Passing null to parameter #1 ($string) of type string is deprecated in _responsive_image_build_source_attributes() (line 414 of core/modules/responsive_image/responsive_image.module).
·         _responsive_image_build_source_attributes(Array, Object, Array) (Line: 173)
·         template_preprocess_responsive_image(Array, 'responsive_image', Array) (Line: 287)
·         Drupal\Core\Theme\ThemeManager->render('responsive_image', Array) (Line: 422)
·         Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
·         Drupal\Core\Render\Renderer->render(Array) (Line: 479)
·         Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 50)
·         __TwigTemplate_b0521e86aaa2ccb2263d138013ee9ad9->doDisplay(Array, Array) (Line: 405)
·         Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
·         Twig\Template->display(Array) (Line: 390)
·         Twig\Template->render(Array) (Line: 55)
·         twig_render_template('core/themes/stable/templates/field/responsive-image-formatter.html.twig', Array) (Line: 384)
·         Drupal\Core\Theme\ThemeManager->render('responsive_image_formatter', Array) (Line: 422)
·         Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
·         Drupal\Core\Render\Renderer->render(Array) (Line: 479)
·         Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 44)
·         __TwigTemplate_7f89780e69a1d2ac98482da07a3293ff->doDisplay(Array, Array) (Line: 405)
·         Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
·         Twig\Template->display(Array) (Line: 390)
·         Twig\Template->render(Array) (Line: 55)
·         twig_render_template('themes/custom/klesia_extranet/templates/field/field.html.twig', Array) (Line: 384)
·         Drupal\Core\Theme\ThemeManager->render('field', Array) (Line: 422)
·         Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
·         Drupal\Core\Render\Renderer->render(Array) (Line: 479)
·         Drupal\Core\Template\TwigExtension->escapeFilter(Object, Array, 'html', NULL, 1) (Line: 44)
·         __TwigTemplate_f09ca4698c8f32f6a8ab2822b02b331c->doDisplay(Array, Array) (Line: 405)
·         Twig\Template->displayWithErrorHandling(Array, Array) (Line: 378)
·         Twig\Template->display(Array) (Line: 390)
·         Twig\Template->render(Array) (Line: 55)
·         twig_render_template('themes/custom/klesia_extranet/templates/user/user.html.twig', Array) (Line: 384)
·         Drupal\Core\Theme\ThemeManager->render('user', Array) (Line: 422)
·         Drupal\Core\Render\Renderer->doRender(Array, ) (Line: 201)
·         Drupal\Core\Render\Renderer->render(Array, ) (Line: 241)
·         Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}() (Line: 564)
·         Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 242)
·         Drupal\Core\Render\MainContent\HtmlRenderer->prepare(Array, Object, Object) (Line: 132)
·         Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse(Array, Object, Object) (Line: 90)
·         Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray(Object, 'kernel.view', Object)
·         call_user_func(Array, Object, 'kernel.view', Object) (Line: 142)
·         Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object, 'kernel.view') (Line: 163)
·         Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 80)
·         Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
·         Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
·         Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 48)
·         Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
·         Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
·         Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
·         Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Deprecated function: trim(): Passing null to parameter #1 ($string) of type string is deprecated in _responsive_image_build_source_attributes() (line 414 of core/modules/responsive_image/responsive_image.module).

Workaround:
If your theme.breakpoints.yml file has an empty value for a mediaQuery, just add empty quotes and this warning will go away.

So this:

theme.xsmall:
  label: xsmall
  mediaQuery:
  weight: 0
  multipliers:
    - 1x
    - 2x

Changed to this:

theme.xsmall:
  label: xsmall
  mediaQuery: ""
  weight: 0
  multipliers:
    - 1x
    - 2x

Add return types to SessionHandler

$
0
0

Problem/Motivation

Follow up from #3377256-27: Correctly implement SessionHandlerInterface from @catch

I feel like we could probably check if contrib extends this class, and then go ahead and add return types in a minor release, based on the fact that non-base-classes are not considered @api (per https://www.drupal.org/about/core/policies/core-change-policies/bc-polic...).

As per @quietone in #3377256-28: Correctly implement SessionHandlerInterface

A search for SessionHanlder in contrib didn't find any case where it was extended.

Steps to reproduce

Proposed resolution

Remove #[\ReturnTypeWillChange] attribute and add return types to session handler methods.

Remaining tasks

User interface changes

API changes

The SessionHandler class uses the correct PHP \SessionHandlerInterface method signatures for return types.

Note: This will break subclasses of SessionHandler if they do not specify the correct return types. However, since non-base classes are not considered public API, this isn't considered a BC break. Also a code search revealed no subclass of SessionHandler in contrib.

Data model changes

Release notes snippet

Viewing all 291349 articles
Browse latest View live


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