@riyas_nr

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.