@riyas_nr

Add post update hook and test coverage for update hook. Moving to NR.

MR in #28 didn’t fix the actual issue where, if the same date is provided in the filter, it won’t filter the full day as expected.

As the problem lies in:

• For offset type with identical min and max (e.g., +1 day):

• $a = '***CURRENT_TIME***+86400', $b = '***CURRENT_TIME***+86400'
  

  .

• Query: $field
  

  BETWEEN ***CURRENT_TIME***+86400 AND ***CURRENT_TIME***+86400
  

  .

• Matches only the exact timestamp, not the full day, often yielding no results.
• For date type, with identical min and max (e.g., 2025-03-03):
• Both $a and $b will be same 2025-03-03 00:00:00 with no result

Solution:

• Offset Type:
• Add check:
  

  if ($this->value['min'] === $this->value['max'] && $b_original % 86400 === 0).
  

• Adjust $b to end of day (offset_days * 86400 + 86399).
• Retains behavior for offsets with time (e.g., +1 day 4 hours).
• Date Type:
• Add check:
  

  (date('H:i:s', strtotime($this->value['max'])) == '00:00:00').
  

• Adjust $b to end of the day 23:59:59

Added test for edge cases mentioned in #20.

riyas_nr → made their first commit to this issue’s fork.

Added test coverage and moving to NR.

riyas_nr → made their first commit to this issue’s fork.

Added test coverage for the change and modified the Views data type schema to include the aria-label attribute

riyas_nr → made their first commit to this issue’s fork.

Raised a new MR against 11.x. Moving to NR.

riyas_nr → changed the visibility of the branch 3504629-process-trailing-view-arguments to hidden.

@plopesc Removed redundant permission. Thanks for your review. :)

The issue arises because LayoutEntityDisplayInterface extends SectionListInterface, meaning that any display implementing LayoutEntityDisplayInterface is also an instance of SectionListInterface. This causes the condition

 ($display instanceof LayoutEntityDisplayInterface && $display->isLayoutBuilderEnabled()) || $display instanceof SectionListInterface )

to incorrectly include displays that are not layout-enabled (e.g., card/teaser displays) because they satisfy the instance of SectionListInterface check.

@plopesc Resolved PR comments. Could you please review it?

Added unit test for ConfigManager()->getEntityTypeByIdName()

riyas_nr → made their first commit to this issue’s fork.

Added a functional test to ensure that top bar navigation actions respect the original tasks weight.

riyas_nr → made their first commit to this issue’s fork.

The pipeline failed in previous approach due to a test failure caused because the interface LayoutEntityDisplayInterface extends SectionListInterface. This causes the following condition:

if (($display instanceof LayoutEntityDisplayInterface && $display->isLayoutBuilderEnabled()) || $display instanceof SectionListInterface) {

to be true for both Layout Builder enabled displays and displays without it, leading to test failures.

To fix this, I updated the code to get the default view display for the node's content type directly, instead of relying on the Layout Builder field list display object (Drupal\layout_builder\Field\LayoutSectionItemList).

$display_repository = $this->container->get(EntityDisplayRepositoryInterface::class);
$listing_page_display = $display_repository->getViewDisplay('node', $listing_page->bundle());

riyas_nr → made their first commit to this issue’s fork.

Reordered content type form fields to match the display order for better consistency and clarity.

Modified test files to verify the reorder change.

riyas_nr → made their first commit to this issue’s fork.

Added a functional test to verify sitemap module plugins are enabled by default.

riyas_nr → made their first commit to this issue’s fork.

I tried the config action createForEachIfNotExists for the recipe SEO tools and when installing the SEO Tools recipe, I encountered this error:
ConfigActionException: Cannot determine a config entity type from simple_sitemap.bundle_settings.default.node.blog
Debugging shows that in core/lib/Drupal/Core/Config/Action/Plugin/ConfigAction/EntityCreate.php, the line:

$entity_type_id = $this->configManager->getEntityTypeIdByName($configName);

returns null. Although the config entity types simple_sitemap.sitemap and simple_sitemap.type exist, getEntityTypeIdByName() isn’t returning a config entity type for simple_sitemap.bundle_settings.default.node.blog, which seems to be causing the exception.

I added test coverage for the bug.

riyas_nr → made their first commit to this issue’s fork.

phenaproxima → credited riyas_nr → .

Moved the Views exposed filter test to the Search integration test file, as this test verifies that when the search role is assigned to the Views exposed form, the aria-describedby attribute is correctly set without a TypeError. This issue occurs only when the Views exposed form label is rendered as an array.

As per the MR comment, I have also added test coverage for the Block module by adding the role attribute for a standard block and verifying the normal label scenario.

I have implemented a fix to ensure that when $variables['label'] is an array, it gets rendered into a string before assigning it to title_attributes['id']. This prevents the TypeError when setting form attribute $form['#attributes']['role'] = 'search';

Additionally, I have added a PHPUnit test to verify this.

riyas_nr → made their first commit to this issue’s fork.

riyas_nr → made their first commit to this issue’s fork.

Since validation is explicitly defined in the getInfo() method through #element_validate => [[$class, 'validateManagedFile']] (source), it is clear that validation is intended for the ManagedFile element. Therefore, there is no need to create an empty validation method to disable it, as validation is required and should not be bypassed.

I initially raised a MR with a proposed solution to disable validation, but the pipeline failed due to test case failures related to text and the ManagedFile element. This indicates that validation is indeed expected and required for this element. We might need to analyze the test failures to determine if they highlight an actual issue or if the approach needs further refinement.

riyas_nr → changed the visibility of the branch 3503297-managedfile-validation-is to active.

riyas_nr → changed the visibility of the branch 3503297-managedfile-validation-is to hidden.

riyas_nr → made their first commit to this issue’s fork.

This patch addresses an additional scenario where adding a block with a View reference field containing a contextual filter in Layout Builder results in the preview displaying 'Placeholder for the name Views block.'

Adding a re-rolled patch to make it compatible with "2985168: Allow media items to be edited in a modal when using the field widget": https://www.drupal.org/files/issues/2023-12-18/2985168-172.patch → .

This patch works with Drupal 10.2.x.

The previous solution failed for the following test case:
Drupal\Tests\taxonomy\Functional\Views\TaxonomyIndexTidUiTest::testFilterGrouping

The logic cannot be changed to the = operator since it is used for views with group filters combined with the NOT operator.

$join->extra[] = [
                'field' => $this->handler->realField,
                'operator' => '!=',
                'value' => $value,
                'numeric' => !empty($this->handler->definition['numeric']),
              ];

Fixed the issue. Please review this.

riyas_nr → made their first commit to this issue’s fork.

riyas_nr → made their first commit to this issue’s fork.

Tried reproducing issue using steps mentioned in #28 and patch applied but failed test for 11.x

In /core/tests/Drupal/Tests/Core/Config/Entity/ConfigEntityStorageTest.php

$this->moduleHandler->getImplementations('entity_load')->willReturn([]);

The method getImplementations() is deprecated in drupal:9.4. 0 and is removed from drupal:10.0.0

Added patch against 11.x

1. Added typehints for method parameters and properties
2. Changed method name updateImport to getStagedConfigByName()
3. Changed access modifier of helper functions to protected
4. Moved optional parameters to end of the constructor arguments

Updated remaining files with the constant ROOT_TERM_ID.

1. Added below parameters as optional.
1. $sync_storage in constructor of \Drupal\config\Form\ConfigSingleImportForm
2. $entity_type_manager in constructor of \Drupal\config\Form\ConfigSync
2. Updated deprecation warning for both parameters.
3. Added change records for above parameters.

Refactored the code and removed 'Import this config' link for configs under Removed section.

1. Fixed phpcs issue regarding unused use statement.
2. For removed configs, single "Import this config" link leads to 'false' text in the import text area because the config doesn't exist. Added config exists check on the singe import page.
3. Added test coverage for 'Import this config' link.

I have renamed ID_ROOT to ROOT_TERM_ID and updated few more places with new constant.

I see parent term id hardcoded in many test files. Do we need to replace those test files?

The constant name 'TERM_ROOT_ID' can be misleading as it might be interpreted as the ID for the root term itself.

However, the constant actually holds the ID for the parent of the root term.
It would be more accurate to name the constant something like "ROOT_TERM_PARENT_ID."

I have identified other scenarios where this constant needs to be used, and I am currently working on it.

Corrected the issue where the configuration type entity did not exist.

I have added test coverage for the changes. The merge request is ready for review now.

I have created a patch that adds the following link to the 'View Differences' drop-down button on the /admin/config/development/configuration page:

• "'Export this config' with a target URL of /admin/config/development/configuration/single/export/{{type}}/{{name}}

I have omitted the 'Import this config' link because there is no option for single config selection on the import page.

riyas_nr → created an issue.

riyas_nr → created an issue.

I couldn't reproduce this issue as the patch mentioned in the parent issue has already been merged with the previous version.