Add opt-in for controlling what form elements are rendered via civictheme system

[richardgaunt]

Issue Link: https://www.drupal.org/project/civictheme/issues/3486893

Checklist before requesting a review

• I have formatted the subject to include ticket number as Issue #123456 by drupal_org_username: Issue title
• I have added a link to the issue tracker
• I have provided information in Changed section about WHY something was done if this was not a normal implementation
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have added tests that prove my fix is effective or that my feature works
• I have run new and existing relevant tests locally with my changes, and they passed
• I have provided screenshots, where applicable

Changed

1. Updated form element rendering system to opt-in to CivicTheme form element template system
2. Improved the attribute passing from 3rd party contributed modules
3. Added more test pages for testing form functionality.

[AlexSkrypnyk]

this is undoing the work that was done to make Drupal look 100% as per design system and be a true design system 😢

we had similar approach in 1.0.0 and the form elements were all over the place without any systematic control.

instead of creating an opt-in system, CivicTheme should implement support for those modules and forms where the form elements look strange.

[richardgaunt]

this is undoing the work that was done to make Drupal look 100% as per design system and be a true design system 😢

we had similar approach in 1.0.0 and the form elements were all over the place without any systematic control.

instead of creating an opt-in system, CivicTheme should implement support for those modules and forms where the form elements look strange.

@AlexSkrypnyk you make an excellent comment thank you for looking into this.

This is my current viewpoint:

By stating directly what elements CivicTheme can render correctly we are ensuring it renders those supported elements as per the Drupal design system.

For form elements that we do not know whether they work with CivicTheme we allow Drupal to takeover the render system. To me this seems like the most sensible approach.

Supporting every form element we want to in CivicTheme is a Sisyphean task, it's not desirable for CivicTheme to have civictheme implementations for 10s of form element types, the maintenance workload of keeping these form elements working is well beyond the ability of this project.

There are custom attributes, custom JS libraries, contrib module updates and fixes, core changes that would need monitoring, adapting and maintaining.

On top of that there are CivicTheme releases that every developer out there would need to keep on top of to ensure all those fixes are carried forward to their themes as those module's update. So we are asking for a lot of developer resources not just from within CivicTheme but from every project relying on CivicTheme.

By being explicit by what is directly supported and then defaulting back to Drupal core's rendering pipeline, we get to keep the great changes you have made to uikit form elements and use them when we know they are going to work and throwback up to Drupal to handle when we dont know.

By doing this I've seen that it does it quite nicely for example, the password_confirm field doesn't work with CivicTheme 1.8 and renders as a plain textfield without a password type.

Doing it the way suggested, I would need to directly support password_confirm, create a form element, create a form preprocess to map the password_confirm attributes to the custom form element, test and ensure the JS works correctly.

Then every release and drupal update we need to test this custom implementation to ensure it still works as expected.

But with this approach, we do not support password_confirm, Drupal renders the core password_confirm template, attaches the JS library correctly, it then renders two password fields which CivicTheme does support and so it then renders these two form elements as per design system.

I get a working password confirm form element out of the box through this system.

Many of the advanced form elements utilise more base form elements and so if we throw to the contrib module to provide the advanced form element template, it then utilises civictheme for the inner form elements.

This PR is still a work in progress and need to examine the effects of this change on webform.

[AlexSkrypnyk]

@richardgaunt
I appreciate the response.

And I understand where you’re coming from.

But this is not about just making it work with Drupal. This is about breaking the concept of design system. We could, as well, just render some other elements using basic styles “because CivicTheme doesn’t support it”.

The whole idea is to create a design system with as many elements as possible to cover many cases. Other ui kits do it, but not CT?!

This also sets the precedent of adding work arounds instead of addressing the problem - CT needs more components if it wants to be a world-class design system.

[richardgaunt]

@richardgaunt I appreciate the response.

And I understand where you’re coming from.

But this is not about just making it work with Drupal. This is about breaking the concept of design system. We could, as well, just render some other elements using basic styles “because CivicTheme doesn’t support it”.

The whole idea is to create a design system with as many elements as possible to cover many cases. Other ui kits do it, but not CT?!

This also sets the precedent of adding work arounds instead of addressing the problem - CT needs more components if it wants to be a world-class design system.

Thanks @AlexSkrypnyk I also appreciate where you are coming from and I appreciate you taking the time to write this feedback.

And I agree "this is not just about making it work with Drupal" which is why I would argue we are not attempting to support every form element in Drupal at some point there are elements we do not want to support as they are not in line with CivicTheme so even if we attempt to support all the form elements we do not want to which is why we opt-in, so 3rd party modules can provide the missing support.

This PR is not being rushed in without community feedback once complete I will be raising in DO to attempt to get feedback.

The feedback I have received however from a series of community members is they want CT to integrate smoothly with Drupal.

[AlexSkrypnyk]

@richardgaunt maybe you could please add some information about the purpose of this pr to a description so that others in the community would know the context

[richardgaunt]

Adding markup handling in this function

[joshua-salsadigital]

@richardgaunt This breaks the admin menu when logged in

[mwjansen]

Here are some thoughts from a current 'downstream' user: I'm working on a new website for my company with a Civictheme based subtheme (quite a lot of tweaks & extra components in the subtheme). Also, unsurprisingly I think, there are a fair number of other modules doing their stuff that our Civictheme subtheme needs to coexist with.

The current approach with its discarding of class attributes in civictheme_convert_attributes_to_modifier_class() :

// Remove class from attributes to avoid duplicated 'class' attribute on
// the element.
unset($variables['attributes']['class']);

this has been a problem for me: yes, there's an opt-out but it's effectively undocumented and has cost me time:
first to even notice that another module isn't doing what it intended and then to trace it to missing class attributes.
Adding the opt-out to a preprocess function isn't so much of an issue for me but might be for anybody who wasn't
expecting to have to add programmatic tweaks to get things to coexist.

For interoperability I definitely support an approach where the class attributes are left alone.

[richardgaunt]

Here are some thoughts from a current 'downstream' user: I'm working on a new website for my company with a Civictheme based subtheme (quite a lot of tweaks & extra components in the subtheme). Also, unsurprisingly I think, there are a fair number of other modules doing their stuff that our Civictheme subtheme needs to coexist with.

The current approach with its discarding of class attributes in civictheme_convert_attributes_to_modifier_class() :

// Remove class from attributes to avoid duplicated 'class' attribute on
// the element.
unset($variables['attributes']['class']);

this has been a problem for me: yes, there's an opt-out but it's effectively undocumented and has cost me time: first to even notice that another module isn't doing what it intended and then to trace it to missing class attributes. Adding the opt-out to a preprocess function isn't so much of an issue for me but might be for anybody who wasn't expecting to have to add programmatic tweaks to get things to coexist.

For interoperability I definitely support an approach where the class attributes are left alone.

@mwjansen yes there is a balancing act going on between a site builder not knowing why a module is not working as intended and a site builder not knowing why CivicTheme is not working as intended when a module changes the styles of an element.

This PR is attempting to find that balance regarding form elements within CivicTheme and integrate with the wider Drupal Form API.

The issue you are mentioning is something we are actively thinking about. If you have examples of modules that didn't work with CivicTheme that would be great. If they are form related problems - does this PR fix those issues?

[mwjansen]

Instances where I've had to add a
['modifier_class'] = FALSE;
instruction to ensure operability with Civictheme:

• https://www.drupal.org/project/swiper_formatter
• Webform's 'Flexbox' field type, as mentioned in an 'issue' I raised
• Setting any custom class in a webform field (also on the issue tracker)

Haven't tried the PR yet.

[richardgaunt]

Instances where I've had to add a ['modifier_class'] = FALSE; instruction to ensure operability with Civictheme:

* https://www.drupal.org/project/swiper_formatter

* Webform's 'Flexbox' field type, as mentioned in an 'issue' I raised

* Setting any custom class in a webform field (also on the issue tracker)

Haven't tried the PR yet.

This PR should fix those issues.

The flex layout though you may need to add as your own custom template in your theme to give you what you want. That's a specialised layout form element that we don't have plans to implement directly but if you get something that works and would work for everyone would consider discussing and adding it