🇮🇳India @jaydev bhatt

in one of the other issue i had the same thing happening ... and there was no actual error. if the pattern are not use anymore we can remove it from the phpstan-baseline-no-getExtras.neon.

Raised an MR moving this to NR for further verification.

Will work on this.

I have added an uninstall hook in the .install file to revert the Views paths back to the default admin path when the module is uninstalled. Here’s what the update does:
•It retrieves the custom admin path from the module’s configuration (rename_admin_paths.settings).
•It loads all Views in the system and iterates through their display settings.
•If a View’s path starts with the custom admin path, it replaces it with admin, effectively reverting it to the default.
•The updated View is then saved to apply the changes.
•Finally, the render cache is cleared to ensure the changes take effect immediately.

Additionally, I have fixed a couple of PHPCS issues, including enforcing stricter empty checks and adding a missing short description in the doc comment. I also replaced the deprecated invalidateAll() method with deleteAll() to ensure compatibility with Drupal 11 and future versions.

Keeping this in Review for verification for the code.

Thank you!

Sure i'll work on this.

Created the MR and Fixed all the PHPCS, PHPstan and PHPunit issues.
moving this to NR but can taken to RTBC.

Upon debugging the issue further and for writing the test properly.
found out that the issue which is mentioned in the description to run the update-countries.sh to Update the CountryManager.php

here the .sh file it self is generating the error with the 11.x code base and not updating the CountryManager.php file.

i setup the drupalsetup using ddev and was trying to run the sh file like this ddev exec php core/scripts/update-countries.sh
and got the following error

PHP Fatal error:  Uncaught Error: Call to undefined function Drupal\Core\Locale\t() in /Users/abc/Developer/DrupalProject/core/lib/Drupal/Core/Locale/CountryManager.php:45
Stack trace:
#0 /Users/abc/Developer/DrupalProject/core/scripts/update-countries.sh(43): Drupal\Core\Locale\CountryManager::getStandardList()
#1 {main}
  thrown in /Users/abc/Developer/DrupalProject/core/lib/Drupal/Core/Locale/CountryManager.php on line 45

keep this on need work as need more input on this error of the .sh file.

I am working on writing PHPUnit test cases for the update-countries script. The test currently verifies the following:
• The script correctly reads and processes the territories.json file.
• Excluded country codes (e.g., ‘EU’, ‘UN’, ‘ZZ’) are not included in the final country list.
• The updated country list is properly written to CountryManager.php.

Are there any additional test cases that should be considered to ensure full coverage? Feedback is welcome!

I have tested the updated code on Drupal 11.1.1 and reviewed the changes thoroughly. With the updates made to the script, the update-countries.sh file now runs without any issues. Additionally, I have ensured that the code aligns with the latest version of the 11.x branch.

I am moving this issue to Needs Review (NR) for further verification. However, based on my testing and review, this patch appears to be ready for RTBC (Reviewed & Tested by the Community).

Thank you!

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

I have tested the patch, and it works with Drupal 11.1.1. I’ve also updated the patch to align with the latest codebase, as the original was created 4 years ago.

Additionally, I have resolved all PHPCS and JavaScript linting issues. However, I’m encountering PHPStan errors related to missing return types.

Locally, all level 1 issues appear to be fixed, but the CI pipeline still fails due to return type errors. Despite updating all methods in the ViewUI file, the number of reported issues has increased.

I need guidance on resolving this discrepancy between local and pipeline results. Marking this as NR.

i'm working on this.

i tried to regenerate this issue on Drupal core 11.1.1 while having the only one result to select on the search page in the tag facet and "Hide facet with 1 result" enabled it hide the entire facet and only shows the title of the facets.
i have tried this wil two options Dropdown option and List with checkboxes options.

moving this to NR for further verification.

i'm working on this.

Fix the issues with the PHPUNIT test failing the issue was by default the is there is nothing selected in the flag while creating the content(node) flag it applies to all the content type present in the system. and hence the user follower flag was also not working for the same reason fixed the LinkGeneration code and fixed the PHPcs issues as well for this.

The MR is ready to merge.
Moving this to RTBC.

Working on it.

Attaching a patch for this issue fix.

Issue: The CookieProConfigFormBase constructor was not properly implementing Drupal\Core\Form\ConfigFormBase which requires both ConfigFactoryInterface and TypedConfigManagerInterface as constructor arguments.

Fix: Updated the constructor to:
1. Inject the required TypedConfigManagerInterface service
2. Pass both required arguments to the parent constructor
3. Update the create() method to properly inject all required services

This resolves the ArgumentCountError that was occurring due to missing constructor arguments.

Moving this to NR for further verification

i was able to replicate this issue using the above description what is happening is let's say if one flag is attached to 2 content types and one is set to only 1 content type ... the flag was still showing/generating the false link and when the link was in the view is was rendering but not actually flagging the content.

Steps to Replicate
1. Set Up Flags:
Create two flags in your Drupal site:
Flag A: Configure it to apply to content types ContentTypeA and ContentTypeB.
Flag B: Configure it to apply only to content type ContentTypeA.
2. Create Content Types:
Ensure you have at least two content types:
ContentTypeA
ContentTypeB
3. Create Content:
Create at least one node of each content type:
Node 1: Content type ContentTypeA.
Node 2: Content type ContentTypeB.
4. Add Flag Links to a View:
Create a View that displays nodes of both content types (ContentTypeA and ContentTypeB).
Add fields for both Flag A and Flag B links to the View.
5. Render the View:
Render the View and observe the flag links:
For Node 1 (ContentTypeA):
Both Flag A and Flag B links should appear and work correctly.
For Node 2 (ContentTypeB):
Only Flag A should appear and work. Flag B should not appear or should be disabled.
6. Identify the Issue:
If the Flag B link appears for Node 2 (ContentTypeB) (even though it should not), this is the issue you’re trying to replicate.

the patch above work but update attaching my version for the patch ...
here is the explanation for the changes in the patch ::

The code has been updated to improve its functionality and maintainability. Instead of using $entity->get('type')->getString(), we now use $entity->bundle() to make the code work for any entity type, not just nodes. Early returns have been added for invalid cases, such as missing entities or flags, to make the logic clearer. The return type has been standardized to an empty array ([]) for consistency with Drupal's rendering system. Additionally, the $view_mode parameter has been included in the getAsFlagLink() call to ensure the flag link respects the view mode. These changes make the code more generic, reusable, and aligned with Drupal best practices.

with the patch that i'm attaching it will generate the flag link as per the content type if the flag is not attached to any content type it will not generate the link itself.

Also attaching the before and after screenshots for the issue for the reference
Moving this to needs Review
for the further verification of the attached patch.

i'm checking this issue.

i have checked this issues on Drupal 11.1.1
with the steps mention above. double checked it. but was not able to replicate this issue.

Steps for testing.

1. Download and enabled the gin theme and cleared the cache.
2. Enable the dark mode and activated the focus colors mode
3. tried giving it the different colors
4. Checked on the contnet type page as well.

Attaching the screenshot for reference.

Moving this to Needs Review.
After the verification can be moved to RTBC.

i'm checking this issue.

Issue Analysis: Form Validation in Content Type and Role Creation

I have thoroughly tested this reported issue in Drupal versions 10.4.1 and 11.1.1, focusing on two key scenarios:

1. Content Type Creation
- Access Path: /admin/structure/types/add
- Test Methodology: Attempted to create a content type with an empty "Name" field
- Observed Behavior:
* Form validation is handled through HTML5 attributes
* The system successfully prevents submission with empty required fields
* When a name is provided, the machine name is automatically generated

2. Role Creation
- Access Path: /admin/people/roles/add
- Test Methodology: Attempted to create a role with an empty "Name" field
- Observed Behavior: Similar validation behavior as content type creation

Conclusion:
The reported issue is not reproducible in current versions. The form validation is functioning as expected through HTML5 form validation attributes, preventing submission of empty required fields.
Attaching a screenshot for the reference for the testing done on drupal 10.4.1 and 11.1.1

Recommendation:
- Status can be updated to "Needs Review"
- If validation confirms these findings, status can be moved to "Ready to be Committed" (RTBC)

i'm working on this issue.

i have tested this again just now with drupal version 11.1.1 and followed the steps Given in the #2.
after entering the different password and selecting the different timezone rather than the default one. with this error occurs (for password) but it goes back to the default timezone for my area. for me it goes to " Kolkata ".
attaching the Screenshot after the password error.

Moving this to NR for further verification.

I've tested this issue, i was able to reproduce this issues and with the added path this issue is getting resolve below are the steps to reproduce this issues.

1. Install the Quiz module.
2. Set up a quiz and quiz question.
3. Run a test quiz at /quiz/1/results/edit.
4. Enable any language on the site (for this test, Spanish was used).
5. After enabling the language, go to User Interface Translations and search for the word "Enter Score". It will not show as a translatable string.
6. Apply the page, clear the cache, and reload /quiz/1/results/edit.
7. Now, you should see the string appearing as a translatable string.

Attaching the screenshots as well.
Moving this to RTBC.

Moving this to needs review and checking the patch is working or not.

Updating the patch file for the views namespace issue

I attempted to recreate this issue on Drupal 11, and the problem persists.

When the admin path is changed via the “Rename Admin Paths” module, the “Files” link in the Content menu no longer appears. This issue seems to be tied to the admin path alteration, which causes a routing mismatch, preventing the “Files” link from being displayed.

After further investigation, I found that the menu links for managing Files were closely tied to the default admin path. Altering this path caused the routing issue.

To resolve this, I implemented a function that dynamically handles path changes based on a flag (revert) and a dynamic prefix. When updating the path, the “admin” prefix is replaced with a dynamic prefix (e.g., “backend”). When reverting, it switches back to “admin”. This ensures that paths are updated consistently based on the current configuration.

By implementing this function, whenever the admin route is altered, the function ensures that all related view paths are updated accordingly to the user’s specified prefix.

I’m attaching the patch file for the fix and moving this to “Needs Review.”

i have checked this issue on two version for the drupal core 10.3.3 and 11.0.0 with the steps provided in #2 but not able to replicate this we can move this to NR and moved this to RTBC if the issues do not reappear.

Passing this to Needs Review.

I have reviewed and tested the patch #4, and it successfully resolves the issue where multiple auto-refresh timers were being triggered upon applying exposed filters. The patch correctly clears the previous timer before setting a new one, ensuring that the view only refreshes once per interval, as expected. Everything works as intended during my tests with no adverse effects on the view's functionality. I believe this patch is ready for RTBC.

Great! Moving this to RTBC

@yhe

i have tested this ... i used Drupal version 10.3.3

The Steps to Add the Timeline blocks are:

1. Download module Using composer
2. Install and Go To Block Layout
3. Place the block in the any region For Eg: content region and Hit Save
4. Configure the Time Block and Add Timeline Title, Time and Description [ Reference SS - 1 ]
5. Select the desired Layout
6. Hit save once again and refresh the page where the block is placed. Reference SS - 2

Attaching some Screenshots for references.
Moving this to Needs Review and can be Moved to RTBC.

Kristen Pol → credited Jaydev Bhatt → .

The issue you're experiencing with the `is-active` class on the `` links is due to Drupal's behavior of automatically applying this class when you are on the front page and the menu items are linked to ``. This is expected behavior for Drupal, as observed in several cases.

To test the is-active functionality correctly, ensure your menu links point to different URLs rather than . When the links point to unique pages, the is-active class will apply appropriately based on the current page URL.

For more information on this behaviour, you can check discussions and solutions on Drupal forums and StackExchange​ (Drupal Answers)​.

Reviewed/ Verified the merge request and found no new PHPCS errors. Moving this issue to RTBC status.

i have Fixed the Listed issues and Raised a MR.
Setting this to Needs Review Please do the needful and Move this to RTBC.

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

Jaydev Bhatt - Floor Management / assistance Volunteer.

i have tried and tested this patch in the Drupal upgrade status module as per that it solve all the Drupal 10 compatibility issue.
also attaching the upgrade status module results screenshot for reference.

also, marking this issue as RTBC.

i'm reviewing this patch