Add a widget setting to select fieldset or container as the address wrapper

Created on 3 March 2017, over 7 years ago
Updated 10 January 2024, 6 months ago

See #2857538: Logic in ProfileSelect::processForm() only applies to default address field

The "don't render in a fieldset" bit sounds like something that should be a setting on the AddressDefaultWidget.

Feature request
Status

Fixed

Version

2.0

Component

Code

Created by

🇨🇭Switzerland Berdir Switzerland

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Merge request !34rebase for 2.x → (Closed) created by heddn
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update 6 months ago
    34 pass
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update 6 months ago
    34 pass
  • 🇷🇸Serbia bojanz

    Thanks everyone, this is almost ready. I gave it a whirl on a test install and it works great.

    Here are the last points worth discussing:

    1) We are calling the setting "render" and labeling it "Render element". Are we convinced this is the most intuitive naming? Views and Field Group tend to talk about "wrappers" and "wrapper elements" instead. Perhaps it would make more sense to rename "render" to "wrapper" and have the label be one of: "Wrapper"/"Wrapper element"/"Wrapper type"? Thoughts welcome.

    2) Since the setting has only 3 possible options, we should use radios instead of a select. There is no need to save space.

    3) We have wrong indentation in defaultSettings() and renderOptions() is missing a docblock such as:

      /**
       * Gets the options for the "Render element" setting.
       *
       * @return string[]
       *   The available options.
       */
    
  • 🇬🇷Greece vensires

    @bojanz, you are correct in that we usually meet the "Render element" terminology in Drupal documentations or in hook_theme() implementations. Site builders at least, I think, wouldn't expect this term in Drupal's UI - I am not sure if webform uses this anywhere. In any case, the "Wrapper" is more Drupal UI-friendly.

    As for the rest, for (3) you are correct. For (2) I don't really have an opinion. Whatever matches the best UX (aka. DX in our case).

  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 8.0 & MySQL 5.7
    last update 6 months ago
    34 pass
  • 🇷🇸Serbia bojanz

    Here's my attempt to illustrate #32. Renamed the setting, its label, and its options.

    I am still unsure about the "Wrapper type" label.

    I did try to rename the options so that both people intimately familiar with Drupal and causal users could figure out what each option does. I haven't used Drupal at my day job for a few years now, and I had to remind myself that "details" is "fieldset, but collapsible", so I was my ideal test user.

  • heddn Nicaragua

    Are we supposed to review the patch or the MR now? I like what I see in the screenshot. Is that different then the MR or just a PoC and we still need to roll back into the MR? I'm confused.

  • 🇷🇸Serbia bojanz

    My patch is newer than the MR and contains the renames I proposed in #32. i can commit it directly if we agree on the points, we don't need to keep updating the MR.

  • Status changed to RTBC 6 months ago
  • Status changed to Fixed 6 months ago
  • 🇷🇸Serbia bojanz

    Renamed the setting to be "wrapper_type" so that it matches its label and committed. Right in time for 2.0.0!

    Thanks, everyone.

  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024