🇧🇷Brazil @brandonlira

chadhester → credited brandonlira → .

brandonlira → changed the visibility of the branch 3515604-use-drupal-behaviours to hidden.

Hi everyone,
I Fixed the PHPCS issues and updated service usage with dependency injection. The code is ready for review.

Thank you!

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

Hi @aaron,
I adjusted the MR as suggested, could you please review it again.
Thanks.

aaron.ferris → credited brandonlira → .

aaron.ferris → credited brandonlira → .

Fixed broken link Reroll a patch

I'll work on this!

Hi @aaron, I am assigning this ticket to myself to work on our contrib day!

Updated the outdated/broken link to the current rerolling patches documentation page.

Sorry in my previous comment I uploaded the wrong image.

Thanks!

Hi everyone,
The "Timer Completed" message can now be translated through the User Interface Translation screen.

This MR! 17 resolves the feature request.
Screenshot attached showing the string translated to Portuguese (Brazil).

Thanks!

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

This patch replaces the preg_replace() used to locate .webp derivative files with the getWebpDestination() method to ensure consistent file naming and allow proper deletion when the image is updated (e.g., after focal point change).

Cheers!

Hi @jwilson3,

The original merge request seemed to be abandoned and the title was still incorrect.
Since there was no update, I created a new branch using cherry-pick and opened a new MR with the correct title as suggested.

Some minor adjustments were also made to fix issues that were causing test failures.

Let me know if there's anything that needs to be changed or improved.

brandonlira → changed the visibility of the branch 3436435-blockcreationtraitplaceblock-should-explain to hidden.

I’ve rebased this issue branch with the latest changes from 11.x (via merge), resolved all merge conflicts, and ensured the code is up to date. All automated tests are passing successfully.

The issue is now ready for review.

Thanks!

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

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

Hi @joachim,

I’ve updated the comment to reflect that setRebuild(TRUE) is what triggers the behavior, as you suggested, while preserving the original intention of explaining how to get this behavior from a DX perspective.

I also rebased the branch onto the latest 11.x since it was many commits behind, to ensure the pipeline runs accurately.

Let me know if anything else needs adjusting!

Hi @smustgrave

I've now added a clear Proposed resolution section to the issue summary, describing the adjustments made to the PHPDoc and how it addresses the original problem.
Let me know if anything else needs to be clarified.

Hi @quietone

The previous MR (!8124) was quite outdated and significantly behind the 11.x branch. I initially attempted a rebase, but due to a large number of conflicts, it became difficult to manage cleanly.

To ensure a clean and conflict-free update, I’ve created a new branch and opened this fresh MR (!11606) with the necessary changes, fully rebased with the latest from 11.x.

All tests are now passing. Let me know if anything else is needed!

Thanks!

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

Hi @smustgrave,

Apologies if I might be misunderstanding something here, but I just want to clarify the intent behind this change to ensure I'm following the best approach. I'm still getting started with contributing to Drupal, and I really appreciate your guidance.

The issue summary suggests that handleEntityDelete() should be updated to use isLayoutCompatibleEntity(), but after reviewing the implementation, I noticed that removeByLayoutEntity($entity) does not fail if the entity is not layout-compatible. Instead, it simply attempts to clean up inline_block_usage, setting layout_entity_id and layout_entity_type to NULL if applicable. If no matching records exist, nothing happens, which makes me wonder if the extra check is truly necessary.

I just want to make sure I'm not missing something here:

• Was there a specific issue that required adding isLayoutCompatibleEntity()?
• Is there any scenario where calling removeByLayoutEntity() directly could cause unintended side effects?

If the check is needed for a reason I’m not seeing, I’ll be happy to update it accordingly. Otherwise, removing it might help simplify the logic while still ensuring the cleanup happens.

Again, thanks for your patience and feedback—I really appreciate learning from this process!

Hi @smustgrave

I have successfully rebased the branch with the latest changes from 11.x. The MR !7106 is now up to date, and the previous changes remain intact.

Additionally, I noticed that one test failed, but it does not appear to be related to the changes made in this MR.

Please let me know if you need any additional adjustments.

Thanks!

Hi @smustgrave,

I have successfully rebased the branch with the latest changes from 11.x. The MR is now up to date, and the documentation improvements remain intact.

Additionally, I have fixed the PHPCS violations by adjusting the line lengths to conform with Drupal coding standards.

I also noticed that some tests have failed (`Drupal\Tests\package_manager\Build\PackageInstallTest` and `Drupal\Tests\ckeditor5\FunctionalJavascript\ImageUrlProviderTest`), but they do not seem to be related to the changes made in this MR.

Let me know if any further adjustments are needed.

Thanks!

Hi all,
I have resolved the conflicts and reverted the method's argument definition as suggested MR! 5052. Let me know if any further adjustments are needed.

Thanks!

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

Hi all,
I removed the isLayoutCompatibleEntity($entity) check before calling removeByLayoutEntity($entity), as suggested.

Tests performed:

PHPUnit: All tests passed successfully, with no errors found. Only pre-existing skipped tests remained unchanged.

The change has been committed and submitted in the Merge Request. Awaiting feedback for any necessary adjustments!

Thank you!

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

I have created a new MR !11528 with the necessary documentation update.

This is now ready for review. Let me know if any further adjustments are needed.

Thanks!

Hi @smustgrave ,

I can confirm that my changes are included in the latest pipeline (#449876), even though the commit history might not explicitly show my name due to the rebase process.

The updates focus solely on documentation improvements for EntityDisplayRepositoryInterface.php MR !9637 , and all unrelated changes have been removed.

Please review and let me know if any further adjustments are needed.

Thanks!

Hi everyone,

I have updated the merge request to remove unrelated changes in the composer/ directory and keep only the documentation improvements for EntityDisplayRepositoryInterface.php.

Now, the MR focuses solely on clarifying the return values for the getAllViewModes(), getViewModes(), getAllFormModes(), and getFormModes() methods, following the previous feedback.

Please review the changes and let me know if any further adjustments are needed.

Thanks!

Hi @adamps,

I have moved the fix to ContactMailer.php (line 100) for 2.x MR (!144) and added a check to ensure $sender is not NULL before calling setReplyTo().

Please review and let me know if any adjustments are needed.

Thanks!

Hi everyone,

I checked the "Add this event to your calendar" link and it redirects to Google Calendar, but I also get the error:
"Could not find the requested event."

Suggested solutions:

If the event link is incorrect but the event still exists, we should update the documentation with the correct Google Calendar link.

If the event is not publicly accessible, we can update the text to guide users to request access via the Drupal Accessibility Slack channel, as previously suggested.
Let me know the best approach, and I’d be happy to submit an update!

Thanks!

Hi @mondrake,

I have updated the code according to the deprecation guidelines for method parameters in Drupal:

The $root parameter is marked as deprecated, but the method itself remains functional.
A @trigger_error() has been added following the documentation.
The @see annotation references the correct change record.
However, I noticed that some tests fail due to deprecation warnings related to passing $root. These warnings appear in multiple functional JavaScript tests, such as:

ToolbarActiveTrailTest
RegistrationWithUserFieldsTest
ClickSortingAJAXTest
FilterTest
FieldDialogsTest
ViewsWizardTest

Would you recommend updating these tests to avoid passing $root, or should we add an explicit handling for this in the code? Let me know the best approach so I can make the necessary adjustments.

Thank you!

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

Hi everyone,

I have updated the fix to target the correct version (1.4.0) by creating a new branch based on 1.x. The previous merge request was for 2.x, but after reviewing the issue and its comments, I realized that the correct fix should be applied to 1.4.0.

I have now submitted a new Merge Request (!143) for this version. Please review the changes and let me know if anything needs to be adjusted.

Additionally, I noticed that some PHPStan checks have failed. From my understanding, these errors seem to be pre-existing and unrelated to this MR. Could someone confirm if I should address them, or if they can be handled separately?

Thanks!

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

Update:
I have worked on this issue and created a Merge Request to make the Google API Key configurable through the theme settings.

🔹MR !4

Changes Implemented:

• Added google_maps_key to the theme settings schema.
• Created a UI field in Appearance > Guesthouse Lite Theme Settings.
• Ensured the key is retrievable via theme_get_setting('google_maps_key').

This allows users to configure the Google Maps API Key easily without modifying code.
Let me know if any improvements are needed!

I’ve adjusted the docblock formatting to ensure compliance with Drupal coding standards.

Thank you for your help!

Thanks for the feedback! I’ve removed the unsupported @note tag, kept the explanation in the standard comment format and fixed the coding standards.

Hey everyone,
I've already made the initial changes and tested locally.Now I'm preparing the fork and will push the changes shortly.

brandonlira → changed the visibility of the branch 3366061-improve-readme.md-and to hidden.

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

Hi,
I’ve updated the inline documentation in processForm() (in FormBuilder.php) to clarify the usage of isRebuilding() and setRebuild(). The changes now specify that isRebuilding() is a getter that returns TRUE when the rebuild flag is set (via setRebuild(TRUE)), rather than implying that it can be directly set.

I hope this addresses the feedback from earlier comments. Please review my changes in MR ![!9319] and let me know if further adjustments are needed.

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

Hello everyone,

I noticed that this issue is currently marked as 'Needs work' due to some unresolved comments regarding CSS ordering and linting errors. I would like to contribute, but I want to confirm the best approach before making any changes.

Could someone clarify what exactly needs to be addressed at this point? Should we focus only on removing @nest, or is there a need to revert the CSS order changes as well?

Any guidance would be greatly appreciated. Thanks!

I've updated the documentation for the defaultStorageSettings() and defaultFieldSettings() methods to specify that setting names must be unique between them, as requested.

Thanks!

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

I have pushed my changes for Issue #3422919, which restore the "(optional)" note in the docblock of the getComponentNames() method. Please review my changes in MR and let me know if further adjustments are needed.

I updated the troubleshooting documentation for the Webform GoogleSheets module to provide a clear, step-by-step guide for resolving common issues. The changes include:

• A general overview of the module’s installation and configuration requirements.
• Detailed troubleshooting sections covering:
  • Authentication errors: Instructions for verifying JSON credentials and ensuring the service account is properly shared as an editor.
  • Spreadsheet data issues: Steps to check and correct the Spreadsheet ID and sharing settings.
  • Permission errors (HTTP 403): Guidance on ensuring the service account has Editor rights.
  • Data mapping problems: Recommendations for verifying the field mapping between the Webform and the Google Sheet.
• A section with general troubleshooting tips (e.g., clearing caches, reviewing logs, updating modules).
• A call to action inviting community contributions to further improve the documentation.

Status update / Question: It looks like the docblock has been updated to address the visibility and region defaults. Is there anything else that needs to be done for this issue? If not, I can help test or review the current changes.

Thanks!

Hi everyone,

I've updated the issue summary in my comment (#22) with the correct documentation details for the getComponentNames() method. It seems I don't have permission to edit the main issue summary directly. Could someone with the necessary permissions please update the issue summary with my changes?

Thank you!

Error in docs for getComponentNames()

Problem/Motivation

The docs say:

@param array $components
  (optional) Array of component lists indexed by type. If not present or it
  is an empty array, it will update all components.

The use of the word "update" is incorrect, as the method actually returns configuration names rather than updating anything.

Steps to reproduce

1. Open core/modules/locale/src/LocaleConfigManager.php.
2. Locate the getComponentNames() method.
3. Check the docblock and see that it mentions “update” when the method is only returning configuration names.

Proposed resolution

• Remove the word “update” from the docblock.
• Clarify that if $components is empty or not provided, the method returns all configuration names.
• Retain that the parameter is (optional).

Remaining tasks

• Update the docblock and push changes to the issue fork.
• Review and test the updated documentation.
• Await merge request approval.

User interface changes

None.

API changes

None; this is purely a documentation fix.

Data model changes

None.

Release notes snippet

Not applicable.

I’ve created a merge request to remove VocabularySerializationTest since it’s no longer needed. You can find it here: https://git.drupalcode.org/project/drupal/-/merge_requests/11296.

Let me know if any feedback or additional changes are required.

Thank you!

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

I applied the latest patch from comment #25 🐛 Autologout can log out out from other tabs/windows Active and it successfully resolved the issue where users were being logged out when working with multiple tabs.

Steps to reproduce before applying the patch:
Enabled Autologout with a timeout of 60 seconds.
Opened multiple tabs and actively worked on one of them.
After some time, inactivity in one tab triggered the logout, even though I was still active in another tab.

Results after applying the patch:
✅ The issue of being logged out when working in multiple tabs was resolved.
✅ The session remained active as long as activity was detected in any tab.

I didn't have the JS error mentioned in other comments.

Thank you for the patch!

The best solution for me was to use solution #17, adding a preprocess in my custom theme and adding the following code along with that solution: $variables['#cache']['max-age'] = 0;

#45 workaround works for me, too.

I tested patch #176 for version 10.2.5 and it worked correctly.

brandonlira → changed the visibility of the branch 3352943-unknown-named-parameter to active.

brandonlira → changed the visibility of the branch 3352943-unknown-named-parameter to hidden.

The patch #69 works well for me on D10.1.4

The last patch #100 didn't work for me because https://www.drupal.org/project/drupal/issues/2722319 🐛 s using Text Editor always fail HTML5 validation when "required" is added via #states Needs work CKEditor removed the "required" attribute from the textarea during startup. So I adjusted the patch with these changes.

The last patch #100 didn't work for me because https://www.drupal.org/project/drupal/issues/2722319 🐛 s using Text Editor always fail HTML5 validation when "required" is added via #states Needs work CKEditor removed the "required" attribute from the textarea during startup. So I adjusted the patch with these changes.

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

I've tested the patch in #4 with Drupal 10.1.6 and Redirect 8.x-1.9.It resolves the issue for me.

brandonlira → created an issue.