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

Clean up unserialize() in the migration modules

$
0
0

Background information

This was originally logged as a private issue to the security team, but was cleared to be moved to the public queue

Problem/Motivation

There are several calls to unserialize() in the migration modules (migrate, migrate_drupal, and migrate_drupal_ui). We should add the optional $options parameter to most or all of these, setting allowed_classes.

Proposed resolution

Remaining tasks

User interface changes

None

Introduced terminology

None

API changes

None

Data model changes

None

Release notes snippet

N/A


Token::replace() should accept any type of callable

$
0
0

Problem/Motivation

Token replace takes a callback function, which is expected to be a string. This makes it difficult to be used for classes with methods. This problem was raised when doing the Token contrib module port to D8.

Proposed resolution

Make the argument accept a callable instead.

Remaining tasks

User interface changes

API changes

Original report by @Xano

Token::replace() accepts a callable in its $options['callback'] parameter:
1) The parameter does not clearly state what the callback should do.
2) The code keeps calling the callback a function, while it technically accepts any kind of callable, as it should.

MenuActiveTrail should ignore disabled menu links

$
0
0

Problem/Motivation

The core system for retrieving the active menu trail does not check if the matching menu link is enabled or disabled. This can lead to several problems when a menu link is disabled, such as an "active" class inappropriately set on a parent menu link, or a wrong breadcrumb if Menu Breadcrumb is used.

A similar problem can happen if the matching menu link is active but one of its parent links is disabled. But:
* this would be a very strange use case,
* I don't know what we should expect from such a configuration,
* in that case, the problem could be easily avoided by also disabling the matching menu link,
* handle this would require to load all the parents to check if they are enabled, which might harm performance.

So I guess we only need to handle the case where the matching menu link is disabled. Here's a patch.

Steps to reproduce

Create menu items with this structure in the main menu:

  • Node 1 (enabled)
    • Node 2 (disabled)

Browse to Node 2 and inspect the menu markup: the Node 1 menu item has the primary-nav__menu-link--active-trail class.

Proposed resolution

Disabled menu items should not be used to generate the active trail.

Remaining tasks

Review
Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Release notes snippet

N/A

Automatically split headers into multiple lines when they exceed 8k

$
0
0

Problem/Motivation

Drupal 8 can send HTTP headers up-to 16kb.
https://www.drupal.org/docs/8/api/cache-api/cache-tags

Downstream systems are being updated to support this. If Drupal sends a request that exceeds 16k the downstream systems will fail with inconclusive errors. For example Varnish will return "HTTP/1.1 502 Bad Gateway." Very few people will be able to debug this sort of situation. We recently encountered a situation with a 50k header!

If a request has too many cache-tags associated with it the header size could exceed 16kb. When this occurs Drupal should automatically split the header into multiple headers that fit within the maximum length.

Steps to reproduce

Enable http.response.debug_cacheability_headers: true and look for a page with many related cache tags so the X-Drupal-Cache-Tags header is larger than 8K.

Proposed resolution

  1. Limit X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers to 8K.
  2. If any header is bigger than that split the value into different header with an autoincrement: X-Drupal-Cache-Contexts-1, X-Drupal-Cache-Contexts-2 and so on.
  3. Apply this to any headers that potentially exceed the maximum length.

Update documentation.

Remaining tasks

None

User interface changes

None.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

Headers exceeding the maximum length of 8000 characters will be automatically split into multiple header lines. For example X-Drupal-Cache-Tags, X-Drupal-Cache-Tags-1, X-Drupal-Cache-Tags-2 could be in the response if the number of cache tags is very high and debug_cacheability_headers is enabled in *.services.yml

Use PHP 8 constructor property promotion for existing code

$
0
0

Problem/Motivation

PHP 8 allows us to significantly reduce boilerplate in OO classes with injected services.

PHP 7:

  /**
   * The entity type manager.
   *
   * @var \Drupal\Core\Entity\EntityTypeManagerInterface
   */
  protected $entityTypeManager;

  /**
   * The entity repository.
   *
   * @var \Drupal\Core\Entity\EntityRepositoryInterface
   */
  protected $entityRepository;

  /**
   * The configuration factory.
   *
   * @var \Drupal\Core\Config\ConfigFactoryInterface
   */
  protected $configFactory;

  /**
   * The typed config manager.
   *
   * @var \Drupal\Core\Config\TypedConfigManagerInterface
   */
  protected $typedConfigManager;

  /**
   * The active configuration storage.
   *
   * @var \Drupal\Core\Config\StorageInterface
   */
  protected $activeStorage;

  /**
   * The event dispatcher.
   *
   * @var \Symfony\Contracts\EventDispatcher\EventDispatcherInterface
   */
  protected $eventDispatcher;

  /**
   * The extension path resolver.
   *
   * @var \Drupal\Core\Extension\ExtensionPathResolver
   */
  protected $extensionPathResolver;

  /**
   * Creates ConfigManager objects.
   *
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager.
   * @param \Drupal\Core\Config\ConfigFactoryInterface $config_factory
   *   The configuration factory.
   * @param \Drupal\Core\Config\TypedConfigManagerInterface $typed_config_manager
   *   The typed config manager.
   * @param \Drupal\Core\StringTranslation\TranslationInterface $string_translation
   *   The string translation service.
   * @param \Drupal\Core\Config\StorageInterface $active_storage
   *   The active configuration storage.
   * @param \Symfony\Contracts\EventDispatcher\EventDispatcherInterface $event_dispatcher
   *   The event dispatcher.
   * @param \Drupal\Core\Entity\EntityRepositoryInterface $entity_repository
   *   The entity repository.
   * @param \Drupal\Core\Extension\ExtensionPathResolver $extension_path_resolver
   *   The extension path resolver.
   */
  public function __construct(EntityTypeManagerInterface $entity_type_manager, ConfigFactoryInterface $config_factory, TypedConfigManagerInterface $typed_config_manager, TranslationInterface $string_translation, StorageInterface $active_storage, EventDispatcherInterface $event_dispatcher, EntityRepositoryInterface $entity_repository, ExtensionPathResolver $extension_path_resolver) {
    $this->entityTypeManager = $entity_type_manager;
    $this->configFactory = $config_factory;
    $this->typedConfigManager = $typed_config_manager;
    $this->stringTranslation = $string_translation;
    $this->activeStorage = $active_storage;
    $this->eventDispatcher = $event_dispatcher;
    $this->entityRepository = $entity_repository;
    $this->extensionPathResolver = $extension_path_resolver;
  }

vs PHP 8:


  public function __construct(
    protected EntityTypeManagerInterface $entityTypeManager,
    protected ConfigFactoryInterface $configFactory,
    protected TypedConfigManagerInterface $typedConfigManager,
    protected TranslationInterface $stringTranslation,
    protected StorageInterface $activeStorage,
    protected EventDispatcherInterface $eventDispatcher,
    protected EntityRepositoryInterface $entityRepository,
    protected ExtensionPathResolver $extensionPathResolver,
  ) {}

Steps to reproduce

Proposed resolution

Before running rector, you need to comment out a line in the rector config class otherwise the @var docs will be copied into the constructor signature which is extremely ugly.
Comment out this line:
$this->propertyPromotionDocBlockMerger->mergePropertyAndParamDocBlocks($property, $param, $paramTagValueNode);
1. Run the following rector:

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Php80\Rector\Class_\ClassPropertyAssignToConstructorPromotionRector;

return static function (RectorConfig $rectorConfig): void {
  $rectorConfig->paths([
    __DIR__ . '/app/composer',
    __DIR__ . '/app/core',
  ]);
  $rectorConfig->ruleWithConfiguration(ClassPropertyAssignToConstructorPromotionRector::class, [
    ClassPropertyAssignToConstructorPromotionRector::INLINE_PUBLIC => TRUE,
  ]);
  $rectorConfig->parallel(processTimeout: 300, maxNumberOfProcess: 4);
};

2. Rector will put the opening brace of the constructor onto a new line. To fix this run phpcbf with just the relevant sniff:
./bin/phpcbf --standard=app/core/phpcs.xml.dist --sniffs=Drupal.Functions.MultiLineFunctionDeclaration app/[core|composer]

Do not try to rebase the MR, simply run the steps again.

Remaining tasks

Write a rector rule to help us with this.
Decide if we need to document constructor parameters any more or if that is also unnecessary boilerplate.
Discover any edge cases and figure out what to do with them.

User interface changes

API changes

Data model changes

Release notes snippet

Make it possible not to throw an exception when accessing a non-existing field with FieldableEntityInterface::get()

$
0
0

Problem/Motivation

There is an attempt to remove magic access for fields on content entities #3281720: [meta] Deprecate __get/__set() on ContentEntityBase

One concern mentioned there is that $entity->get('field_name') throws an exception, while $entity->field_name does not.

This results in pretty unwieldy code:

if ($entity->hasField('field_name') && $entity->get('field_name')->value)

This made sense many years ago when it was added, but since then we have nullable operator, so if we remove the exception, we can do this:

if ($entity->get('field_name')?->value)

Steps to reproduce

Proposed resolution

Add a second boolean parameter $exception_on_invalid to FieldableEntityInterface::get().

For Drupal 11.3+, use func_get_args() to get argument value. If there is no second parameter passed, default the value to TRUE, so that the same functionality is kept and an exception is thrown on an invalid field name. If the second parameter is passed as FALSE, the method will return NULL on an invalid field name.

In the follow up #3522289: [PP-1] Add typehints and $exception_on_invalid parameter to FieldableEntityInterface::get(), we can do one of two options (also see comments #20-25):

  1. In Drupal 12, add the second parameter and keep the second parameter default as TRUE. Then, going forward get('{invalid field name}') will throw an exception and get('{invalid field name}', FALSE) returns NULL
  2. In Drupal 13, add the second parameter and flip the second parameter to default as FALSE. Then, going forward get('{invalid field name}') will return NULL and get('{invalid field name}', TRUE) will throw and exception

MR 10406: $exception_on_invalid default is TRUE with the expectation it will continue to default to TRUE

MR 12123: $exception_on_invalid default is TRUE with the expectation it will be changed to default to FALSE in Drupal 13.

Remaining tasks

Decide between the two approaches.

Also, two things came up resolving tests that probably need answers:

  1. ContentEntityBase::set() calls get(). We probably either need to do the same with set() and add an optional $exception_on_invalid so it can be passed to get(), or we have set() call get() explicitly with $exception_on_invalid as TRUE, so exceptions will always be thrown for invalid fields
  2. get() is documented in FieldableEntityInterface to throw an InvalidArgumentException on invalid field names, but in ContentEntityBase::getTranslatedField, which is called by get(), it's also possible to throw an exception when "The entity object refers to a removed translation". Should this exception be suppressed as well, or only ones with message "Field $name is unknown"? Basing conditional logic on exception messages seems brittle

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Better help text for Date and Time Field

$
0
0

Problem/Motivation

Drupal saves and render Date field in certain way. However the way it does, is not very transparent looking at the available documentation. This becomes critical when we have time sensitive fields example Event Date and Time.

During content save Drupal will store Date field in UTC format, the date input by user is considered to be in timezone user belongs to at the time of saving.
During content render Drupal will convert it to viewer's user account timezone in case of logged in user, else in site default time zone in case of anonymous user.

While this works most of the times, however in case where content editor has to create multi geographical data belonging to different timezone it becomes erratic in nature and hard to understand for editor.

Steps to reproduce

1. Add a Date and Time Field in Drupal.
2. The process of Drupal storing and rendering date field is missing.

Proposed resolution

Improve documentation to explain Drupal way of maintaining the date, so site builders take more aware decisions.
documentation

Drupal Usability Meeting 2025-05-02

$
0
0

This meeting takes place every Friday at 14:00 UTC (currently 6:00am PT, 9:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

List of Slack users to ping 10 minutes before the meeting:
@worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Ravi, @shaal, @ckrina, @simohell, @gauravvv, @Quynh, @yoroy, @andrei.zvonkov, @Regu.pl

This list gets copied to the issue for the next meeting. If that has already happened, then go to that issue to add/remove yourself to/from the list.

Recording of this week's meeting: https://youtu.be/nItrOu04EIo

Rough transcript of this week's meeting: Drupal Usability Meeting - 2025-05-02.txt

We discussed the following issues:

NR and RTBC issues marked Needs usability review.

The group is actively tracking progress on these issues:

Remaining tasks

  1. Add issue credits for the participants.
  2. Add the issue(s) we discussed to the issue summary and as related issues.
  3. Add a rough transcript.
  4. Add a link to the recording on YouTube.
  5. Comment on the issue(s) we discussed.

Drupal Usability Meeting 2023-09-29

$
0
0

This meeting takes place every Friday at 14:00 UTC (currently 7:00am PT, 10:00am ET). See Time.is to see what that is in your timezone.

The meetings are held using Zoom, and a link is posted in the #ux Slack channel 10 minutes before the meeting. Agenda is first come, first serve and set by attendees. Use the Needs usability review issue tag for issues that need review and/or suggest issues in comments here.

List of Slack users to ping 10 minutes before the meeting:
@Gábor Hojtsy (he/him), @worldlinemine, @lauriii, @AaronMcHale, @anmolgoyal74, @Antoniya, @Ravi, @shaal, @ckrina, @simohell, @gauravvv, @penyaskito, @Mike Gifford (CivicActions), @April, @Quynh, @yoroy, @EricRubino

Go to the issue for the next meeting to add/remove yourself to/from the list.

Recording of this week's meeting: https://youtu.be/PPD3bKtLaCI

Rough transcript of this week's meeting: Drupal Usability Meeting - 2023-09-29.txt

We discussed the following issues:

Also some related issues, such as #3356894: Make field selection less overwhelming by introducing groups and #3346539: [Plan] Improve field creation experience.

NR and RTBC issues marked Needs usability review.

The group is actively tracking progress on these issues:

Remaining tasks

  1. Add issue credits for the participants.
  2. Add the issue(s) we discussed to the issue summary and as related issues.
  3. Add a rough transcript.
  4. Add a link to the recording on YouTube.
  5. Comment on the issue(s) we discussed.

Refine labels and descriptions for field types

$
0
0

Problem/Motivation

This issue is a follow-up for #3356894: Make field selection less overwhelming by introducing groups to refine the newly added field descriptions if wanted.

Steps to reproduce

  1. Visit the "Manage fields" tab for an entity type and bundle. (For example: /admin/structure/types/manage/page/fields for the Page content type.)
  2. Use the "Create a new field" action link.
  3. Choose a type of field, such as Reference.
  4. This issue deals with the text in the resulting modal window that helps the site builder choose the correct field type.

Proposed resolution

We discussed the text for field-type descriptions during several Usability meetings, and we tracked our recommendation in a spreadsheet: https://docs.google.com/spreadsheets/d/1Lx7L40eRHotr5KQGn6au5WxQO3lFv19a.... There are a few common themes: use examples; replace "Ideal for" with "Recommended for"; use the bullet points (unordered lists) for differentiators. Most of the changes in MR !11153 are simple: they update the text, including updates to the automated tests as needed.

A few of the changes are worth explaining:

  1. Add an optional summary paragraph just above the label "Choose a field type". This requires adding the getSummary() method to Drupal\Core\Field\FieldTypeCategoryInterface and Drupal\Core\Field\FieldTypeCategory and some updates to FieldTypeCategoryManager to support the summary and a change to Drupal\field_ui\Form\FieldStorageAddForm to use the summary.
  2. Since FieldStorageAddForm::buildForm() was already very long, move the part for listing all the field types in a selected group to the new protected method buildGroupForm(). That change was done in a separate commit, so it can be reverted and moved to a follow-up issue if the refactoring makes it too hard to review the MR.
  3. In order to get different text for each of the Reference types, add the optional description key to the array returned by Drupal\Core\Field\PreconfiguredFieldUiOptionsInterface::getPreconfiguredOptions(). Provide a value for that key by implementing hook_field_ui_preconfigured_options_alter.
  4. The method Drupal\Tests\field_ui\Traits\FieldUiJSTestTrait::fieldUIAddNewFieldJS() tried to find a link containing the field-type label. It assumed that if the field type was part of a group, then none of the links would match. This MR simplifies the labels, so that assumption no longer holds. So the MR updates that method. It now checks whether the field type is part of a group before looking for a link.

As an example of (1), the modal window for selecting a Selection list field now has the summary

Each list item has a Name, with limited formatting, and a Value. Values that are in use cannot be changed, since they are stored in the database. The Names can be edited later.

See the screenshot in the User interface changes section below.

Remaining tasks

User interface changes

Before

The "Add field" modal (after Step 2 in the Steps to reproduce):

The "Add field" modal window, with "Plain text" selected, before this issue

The "Add field: Reference" modal (after choosing "Reference" in Step 3 in the Steps to reproduce):

 Reference" modal window, showing the existing descriptive text

The "Add field: Selection list" modal (after choosing "Selection list" in Step 3 in the Steps to reproduce):

 Selection list" modal window, showing the existing descriptive text

After

The "Add field" modal (after Step 2 in the Steps to reproduce):

The "Add field" modal window, with "Plain text" selected, after this issue

The "Add field: Reference" modal (after choosing "Reference" in Step 3 in the Steps to reproduce):

 Reference" modal window, showing the new descriptive text

The "Add field: Selection list" modal (after choosing "Selection list" in Step 3 in the Steps to reproduce):

 Selection list" modal window, showing the new descriptive text

API changes

Add the getSummary() method to Drupal\Core\Field\FieldTypeCategoryInterface. This is an API addition, and there is only one class that implements the interface.

Add the optional description key to the array returned by Drupal\Core\Field\PreconfiguredFieldUiOptionsInterface::getPreconfiguredOptions(). Since the return type is mixed[][], this does not really count as an API change.

Data model changes

None

Release notes snippet

Do we need one?

Convert testJail() to use expectExceptions

$
0
0

Problem/Motivation

While working on #3268809: Fix class comment doc blocks in tests for 'Drupal.Commenting.DocComment.ShortSingleLine', xjm spotted this comment in \Drupal\Tests\system\Functional\FileTransfer\FileTransferTest::testJail

    // This convoluted piece of code is here because our testing framework does
    // not support expecting exceptions.

Since we can now test expected expceptions the block of code can be updated.

Steps to reproduce

Proposed resolution

Convert testJail to use expectExceptions.

Remaining tasks

Patch
Review
Commit

User interface changes

API changes

Data model changes

Release notes snippet

Drupal Core strategy for 2025-2028

$
0
0

Many months ago, we began defining the strategic direction for Drupal Core using the "Playing to Win" framework. You can learn more about the framework in its book: https://www.amazon.com/gp/product/142218739X. A summary of the method can be found here:
https://fs.blog/playing-to-win-how-strategy-really-works/ in videos: https://www.youtube.com/watch?v=I_JnjK8sGNU or https://www.youtube.com/watch?v=DDXn2Wry_HY

The Drupal Core products strategy builds on the Drupal Starshot product strategy, which you can find at https://dri.es/introducing-drupal-starshot-product-strategy. Together, these two strategy documents aim to provide a more complete vision for the Drupal project, fostering alignment across the community and leadership.

The Drupal Core strategy document has been a collaborative effort among the Core Committers. Through a mix of in-person meetings, Zoom calls, and asynchronous discussions in Slack and Google Docs, we've worked together to shape a shared vision.

While this strategy is still a work in progress, we've reached a critical milestone: it’s time to broaden the conversation and get feedback. We're seeking input from the community to ensure the strategy resonates and aligns with the needs of everyone invested in Drupal's success. To provide feedback, download the PDF document attached to this issue and provide comments below.

A well-defined strategy is essential for accelerating innovation, creating focus, keeping Drupal relevant, and attracting new users and contributors. At its core, strategy is about making trade-offs — choosing what to prioritize and what not to prioritize. This document is designed to guide contributions and empower our community to make decisions confidently.

We're not sharing the entire strategy document today. There is more work to be done and sections that are not ready to be shared. We're sharing what we feel aligned and good about. This allows us to focus feedback on the broader ideas and overall direction before we continue to work on the finer details.

Later this week, we'll host a Zoom meeting with Core Committers and subsystem maintainers to get feedback. In the coming months, we'll also expand our outreach to include structured feedback from other key stakeholders, such as the Drupal Association staff, Board of Directors, end users, and more. In the mean time, everyone can give feedback in this issue.

Reuse element plugins as object wrappers around render arrays

$
0
0

Problem/Motivation

It's 2025. The render API suspiciously looks like form API when we added it 20 years ago.

Steps to reproduce

Proposed resolution

Note this issue is currently allowing failure of the following jobs since there are architectural explorations that need to happen before dealing with these standards:
PHPCS and CSPELL

Let's reuse the existing render element plugins as object wrappers around render arrays. To achieve this, let's add:

  1. ElementInfoManager::fromClass. It's like createInstance but it takes a class instead of a plugin id. We will see why this is good in the next point.
  2. @property documentation on the render element plugin classes based on existing documentation. This together with the previous point allows for this:
    example code
  3. ElementInfoManager::fromRenderArray() which creates an ElementInterface plugin from a render array and stores a reference to that render array.
  4. __set and __get to RenderElementBase to allow using render properties as object properties.
  5. A few methods to work with children: addChild, removeChild, getChildren. These will return objects.
  6. RenderElementBasee::toRenderArray method which returns the stored render array.
  7. FormBase::elementInfoManager() to get the element info manager.

Converted form alter. Before:

  public function formUserRegisterFormAlter(&$form, FormStateInterface $form_state) : void {
    $form['test_rebuild'] = [
      '#type' => 'submit',
      '#value' => $this->t('Rebuild'),
      '#submit' => [
        [Callbacks::class, 'userRegisterFormRebuild'],
      ],
    ];
  }

After

  public function formUserRegisterFormAlter(&$form, FormStateInterface $form_state) : void {
    $submit = $this->elementInfoManager->fromRenderArray($form)
      ->createChild('test_rebuild', Submit::class);
    $submit->value = $this->t('Rebuild');
    $submit->submit = [[Callbacks::class, 'userRegisterFormRebuild']];
  }

The time is now because

  1. plugin.manager.element_info becomes central for all things dealing with render API but all hooks now can use dependency injection to get it. Widgets always been plugins which also can use DI and forms are easily dealt with as above. Maybe various twig functionality will need it too but a) preprocess is also OOP now (yay) b) twig extensions are tagged services.
  2. PHP 8.4 -- which will likely be required soon -- introduces property hooks. So it'll be possible to have setters and getters. So it's possible to start using properties without methods and seamlessly change core to add logic to them as needed. That will also allow deprecating properties.

Note: Because I know this will come up, the current implementation creates recursion in the render array, PHP handles this gracefully in serialize and dumping too so it's not a problem any more. var_dump and print_r prints ** RECURSION **, var_export produces a warning but all three work and doesn't fall into an infinite recursion. serialize also works but to make sure it works with other serializers on sleep/wakeup the recursion is broken/rebuilt.

Remaining tasks

  1. Standardize naming. Do we call these element plugin instances, render objects or something else?
  2. Finish any deprecations
  3. Update comments
  4. Re-enable phpcs and cspell
  5. Write tests
  6. In a followup, add a traversal helper and then convert form the renderer/builder/validator/submit to visitors -- I think that'd be cleaner as it centralizes recursion
  7. In the ultimate followup, convert all core and contrib to the new API and drop render arrays. (Should be an easy, simple issue.)

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Consider allowing first stage tests to fail when an MR is in draft.

$
0
0

Problem/Motivation

While we want the first stage of tests to help keep core consistent and catch issues with phpstan. There are situations such as architectural issues you would want full tests to run even if phpcs is failing for example.

I would like to suggest that if an MR is in draft then the first stage of tests get a new rule that allows failure.
We would need to ensure that code is not committed from a draft MR as well.

Steps to reproduce

See:
https://www.drupal.org/project/drupal/issues/3525331
https://www.drupal.org/project/drupal/issues/3526388

Neither of those are really in a position to be even in needs review, but it would be valuable to see a full test run even if there is a spelling mistake. This would have the potential to increase resources used by the DA, but we could be cognizant of when an issue uses Draft MRs

Proposed resolution

Rule to allow failure for most jobs in the first column when the MR is in Draft

Remaining tasks

Determine if there is a better way to do this.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Contextual filter not working with views path alias

$
0
0

Problem/Motivation

I have a views list of names. The listing is filtered by an alphabetical glossary attached to the view. Default language of the site is French but available in both French and English. The view is accessed in the url "/noms". I added an alias through admin/config/search/path so the English page is accessed at "/en/names".

Everything works fine and filtering is executed as expected in both languages if Ajax is disabled.

If Ajax is enabled, only the French (default language) works. The English aliased page is no more filtering. When I pass the mouse over the glossary letters display correctly, for example: "noms/d" and "/en/names/d"

If I manually enter the aliased url with a contextual filter (i.e. /en/names/d), of course it works as this way it doesn't call ajax.

No errors appear in browser's dev console nor in Drupal's dblog report.

Steps to reproduce

Configure site as multilingual with French as default and English as additional language
Create some pages (simple nodes with a title)
Create a Views page listing the titles of the nodes created above. Set a contextual filter to filter by Content:title. Set it's path to '/noms'
Create an attachment listing the titles. Add contextual filter "content: title" and set "When the filter value is NOT available" to "Display a summary" and in "More" set "Glossary mode" and "Character limit" to 1. Finally attach the attachment to the previous page.

Go to "admin/config/search/path" and add alias: English, system path '/noms', url alias '/names'

Visit '/noms' and '/en/names' to verify that everything works. Click on glossary letters and also enter manually some filters, like: '/noms/b' and '/en/noms/b'

In Views page, set Use Ajax to Yes. Visit again the pages in French and English. French pages work as expected. On English pages, manually entering '/en/noms/b' works but clicking on the glossary letters has no effect even if the ajax spinner turns.

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet


Composer is not noticing Drupal updates

$
0
0

Drupal shows that updates are availables but composer update doesn't updates anything.

"Unsaved changes" message incorrectly appears on layout builder

$
0
0

Problem/Motivation

After the initial load of a layout builder edit page (either per-entity overrides or the per-display defaults), any subsequent visits to the page will trigger a "You have unsaved changes" message, even when no changes have been made.

(this bug was introduced by #3144010: New pseudo-fields cannot be removed, InvalidArgumentException thrown)

Steps to reproduce

Scenario 1:

  1. Enable layout builder for a content type.
  2. Click the "Manage layout" link.
  3. Refresh the page.

Scenario 2:

  1. Enable layout builder for a content type, and allow each content item to have its layout customized.
  2. Create a node.
  3. Click the "Layout" tab.
  4. Refresh the page.

Actual result: "You have unsaved changes" message appears.
Expected result: The message should not appear, since there are no unsaved changes.

Proposed resolution

Update LayoutTempstoreRepository so that it can explicitly keep track of whether any given SectionStorage in the repository has unsaved changes.

Remaining tasks

Review

User interface changes

The "You have unsaved changes" message will only appear when you have unsaved changes

API changes

LayoutTempstoreRepositoryInterface has a new public hasUnsavedChanges() function. Note that this interface has a one-to-one correspondence with the LayoutTempstoreRepository class, so we can add functions without breaking any BC rules.

In addition, LayoutTempstoreRepositoryInterface::set() has a new optional boolean argument called $has_unsaved_changes, which is used to track whether there are unsaved changes in the SectionStorage being set.

Data model changes

N/A

Release notes snippet

N/A

Update Coder to 8.3.30

$
0
0

Problem/Motivation

Coder 8.3.30 will be released soon and requires some changes to comments, let's fix them here and backport to all branches for consistency.

Steps to reproduce

Update Coder to 8.3.x git checkout and run phpcs.

Proposed resolution

Update straight to Coder 8.3.30.

Remaining tasks

1. Make phpcs pass locally with git version of Coder
2. Make a new Coder 8.3.30 release
3. Use that Coder version with composer

User interface changes

none

Introduced terminology

none

API changes

none

Data model changes

none

Release notes snippet

not needed

Add support for Sequentially constraint

$
0
0

Problem/Motivation

Let's start with a very usefull contraint: Sequentially. Which allows us to layer contraints. Which could help in only reporting errors which are usefull instead of walking through all the contraints.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver of core\lib\Drupal\Core\Asset\AssetResolver.php

$
0
0

Problem/Motivation

Warning: Undefined array key 1 in Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies() (line 67 of core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php) #0 core/includes/bootstrap.inc(166): _drupal_error_handler_real()
#1 core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(67): _drupal_error_handler()
#2 core/lib/Drupal/Core/Asset/LibraryDependencyResolver.php(41): Drupal\Core\Asset\LibraryDependencyResolver->doGetDependencies()
#3 core/lib/Drupal/Core/Asset/AssetResolver.php(117): Drupal\Core\Asset\LibraryDependencyResolver->getLibrariesWithDependencies()
#4 core/lib/Drupal/Core/Asset/AssetResolver.php(175): Drupal\Core\Asset\AssetResolver->getLibrariesToLoad()
#5 core/lib/Drupal/Core/Ajax/AjaxResponseAttachmentsProcessor.php(149): Drupal\Core\Asset\AssetResolver->getCssAssets()
#6 core/lib/Drupal/Core/Ajax/AjaxResponseAttachmentsProcessor.php(117): Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor->buildAttachmentsCommands()
#7 core/lib/Drupal/Core/EventSubscriber/AjaxResponseSubscriber.php(66): Drupal\Core\Ajax\AjaxResponseAttachmentsProcessor->processAttachments()
#8 [internal function]: Drupal\Core\EventSubscriber\AjaxResponseSubscriber->onResponse()
#9 core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111): call_user_func()
#10 symfony/http-kernel/HttpKernel.php(214): Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch()
#11 symfony/http-kernel/HttpKernel.php(202): Symfony\Component\HttpKernel\HttpKernel->filterResponse()
#12 symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#13 core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#14 core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#15 core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#16 core/modules/page_cache/src/StackMiddleware/PageCache.php(116): Drupal\Core\StackMiddleware\ContentLength->handle()
#17 core/modules/page_cache/src/StackMiddleware/PageCache.php(90): Drupal\page_cache\StackMiddleware\PageCache->pass()
#18 core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Drupal\page_cache\StackMiddleware\PageCache->handle()
#19 core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#20 core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#21 core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#22 core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#23 index.php(19): Drupal\Core\DrupalKernel->handle()
#24 {main}.

Steps to reproduce

  1. With a Views page with "Use AJAX" enabled:
  2. Bare minimum query parameters: https://example.org/views/ajax?ajax_page_state[libraries]=ajax&view_name=example_view

Proposed resolution

A patch has been provided that addresses the issue by checking if the array key exists before accessing it, thereby preventing the warnings.

Currently, the warnings appear because the code attempts to access an array key that may not be set, because they are missing the slash. A patch has been provided that prevents this by checking for the existence of the key before accessing it.

Alternatively, instead of suppressing the warning, we could throw a RuntimeException when this occurs, triggering a 4xx client error. This would indicate that the request was invalid rather than failing silently, making it clear that unexpected input has been provided.

Original Issue Summary

•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getCssAssets() (line 133 of core\lib\Drupal\Core\Asset\AssetResolver.php).
•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsAssets() (line 239 of core\lib\Drupal\Core\Asset\AssetResolver.php).
•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsAssets() (line 251 of core\lib\Drupal\Core\Asset\AssetResolver.php).
•	Warning: Undefined array key 1 in Drupal\Core\Asset\AssetResolver->getJsSettingsAssets() (line 199 of core\lib\Drupal\Core\Asset\AssetResolver.php).
Viewing all 295142 articles
Browse latest View live


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