allowing ID randomization but keeping the stable selector

[PardeepSinghBali]

What does this change?

This PR addresses an issue related to form container ID randomization for improved accessibility and Address Dropdown not populating the addresses at drupal Form. Previously, the localgov_base_preprocess_container() function was appending a random suffix to the edit-actions form container ID. This introduced potential issues with JavaScript selectors that rely on the #edit-actions ID, as they were no longer able to target the element due to the dynamic nature of the ID.

This change ensures that:

1. The ID is randomized for accessibility, but we still maintain a stable selector (data-drupal-selector) to be used by JavaScript.
2. JavaScript selectors that depend on the original ID (edit-actions) will work as expected, avoiding potential breakage in behavior.
3. The random ID is applied to the id attribute, but the original ID is retained as data-drupal-selector for stable targeting.

How to test

Check the edit-actions form container element:

On the main branch, inspect the container and check the id attribute. It should be static (e.g., #edit-actions).
On this branch, inspect the same container and verify that the id has been randomized (e.g., #edit-actions--) but the data-drupal-selector remains as edit-actions.

How can we measure success?

1. No errors or broken JavaScript functionality related to the #edit-actions container ID after the change.
2. JavaScript selectors that use data-drupal-selector="edit-actions" work as expected.
3. Improved accessibility with randomized form container IDs while keeping the stable selector intact.

Have we considered potential risks?

Images

Accessibility

• Tested with screen reader
• Navigable with keyboard
• Colour contrast passed
• The change doesn't use only colour to convey meaning

[siliconmeadow]

This is in reference #325, btw.

[Adnan-cds]

I have tested this change in a webform with two address lookup elements and it worked okay.

I would request Pardeep to rename the Git branch though. I am linking to the relevant LocalGov Drupal documentation.

Mark or Maria, would you be able to test this as well? @markconroy @msayoung

[Adnan-cds]

Please also fix the coding standards errors. This should be easy: $ cd /path/to/your/localgov/site/; ./bin/phpcbf web/themes/contrib/localgov_base/localgov_base.theme

[siliconmeadow]

@Adnan-cds - I'm trying to help @PardeepSinghBali out and we're unable to rename the branch here on github. He's renamed it locally and pushed it to GH and it looks like he'll have to created yet another PR using that branch instead. Are you, or someone with greater privileges able to change the branch on this PR? What's the best way to proceed? This is the branch which has the CS fixes, btw: fix/1.x-325-fix-RandomID.

[andybroomfield]

Have also tested this with an address field in localgov_scarfolk and the address list is populating. This is on a release version of localgov_forms (beta9) so it doesn't have the previously merged code from localgovdrupal/localgov_forms#110

Localgov.scarfolk.address.lookup.fix.mp4

[PardeepSinghBali]

Have also tested this with an address field in localgov_scarfolk and the address list is populating. This is on a release version of localgov_forms (beta9) so it doesn't have the previously merged code from localgovdrupal/localgov_forms#110

Localgov.scarfolk.address.lookup.fix.mp4

we dont need this js change anymore [localgovdrupal/localgov_forms#110]

[Adnan-cds]

we're unable to rename the branch here on github.

Could you please attempt a rename from https://github.com/localgovdrupal/localgov_base/branches. Github has some instructions. If this doesn't work, I can try it on your behalf.

[PardeepSinghBali]

I can see this PR is Closed. better idea is i am creating a new PR
#731