Gender binary example on (2192175) "Creating a content entity type in Drupal 8"

Created on 3 January 2024, 6 months ago
Updated 21 February 2024, 4 months ago

Documentation location/URL

https://www.drupal.org/docs/drupal-apis/entity-api/creating-a-content-en... โ†’

Problem/Motivation

The example Contact:: baseFieldDefinitions() function on this page includes the following:

    // Gender field for the contact.
    // ListTextType with a drop down menu widget.
    // The values shown in the menu are 'male' and 'female'.
    // In the view the field content is shown as string.
    // In the form the choices are presented as options list.
    $fields['gender'] = BaseFieldDefinition::create('list_string')
      ->setLabel(t('Gender'))
      ->setDescription(t('The gender of the Contact entity.'))
      ->setSettings(array(
        'allowed_values' => array(
          'female' => 'female',
          'male' => 'male',
        ),
      ))
...

However, gender is not a binary. See https://www.drupal.org/project/gender โ†’ for a bunch of great resources about this topic, and why only 2 options for this field is not okay.

Proposed resolution

Either:

  1. Add more allowed values to be inclusive.
  2. Change this example field entirely into something where only a couple of options makes sense.

I (dww) lean towards option #2, something like:

    // ListTextType with a drop down menu widget.
    // In the view the field content is shown as a string.
    // In the form the choices are presented as an options list.
    $fields['primary_color'] = BaseFieldDefinition::create('list_string')
      ->setLabel(t('Favorite Primary Color'))
      ->setDescription(t('The favorite primary color of the Contact entity.'))
      ->setSettings([
        'allowed_values' => [
          'blue' => t('Blue'),
          'red' => t('Red'),
          'yellow' => t('Yellow'),
        ],
      ])
...

Remaining tasks

๐Ÿ› Bug report
Status

Fixed

Component

Correction/Clarification

Created by

๐Ÿ‡บ๐Ÿ‡ธUnited States dww

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @dww
  • ๐Ÿ‡ฎ๐Ÿ‡นItaly apaderno Brescia, ๐Ÿ‡ฎ๐Ÿ‡น

    Would copying part of the code from that module (with a crediting comment) a viable solution?

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    This page is intended to teach people how to create a custom entity type and define its base field properties. Itโ€™s not really intended to educate potential readers on gender politics and reality, and getting into the details of defining a custom field is out of scope.

    I think the two options I put in the summary would be best: either add a lot more allowed values here (and make the field optional), or just come up with a simple, benign example property where only 2 or 3 allowed values makes sense. Something silly like โ€œFavorite primary colorโ€ with allowed values of blue, red and yellow.

    For the sake of simplicity Iโ€™m leaning towards primary color or something, since gender is an inherently complicated topic.

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww
  • Status changed to Needs review 6 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    Added a specific proposal to the summary for consideration. I'm leaning towards option #2.

    Also, by using 'blue' => 'Blue' (with different capitalization) it hopefully makes it more clear (?) that the array index is the machine value and the array value is the human-readable label used...

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly apaderno Brescia, ๐Ÿ‡ฎ๐Ÿ‡น

    Strings shown in the user interface must be translatable. That should be enough to differentiate them. ๐Ÿ˜‰ ๐Ÿค“

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    Hehe, whoops. I was confused because they're field settings, but since they're base fields being defined in code, you're totally right. Thanks!

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly apaderno Brescia, ๐Ÿ‡ฎ๐Ÿ‡น

    Looking at the example code, I noticed it defines fields that make sense for an entity which I guess could be used for people who needs to be contacted. (I assume the difference with the User entity is that the latter contains login information.)
    In this case, would not a field like Work department make more sense than a Favorite Primary Color field? It would still be a list_string field with allowed values, like the Gender field, but it would not touch a inherently complicated topic.

  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand quietone New Zealand

    I am glad to see this issue.

    I support the "simple, benign example" or colors. The idea of "Work department" is making an assumption that everyone 'works in a department' and I don't think we should do that. Would that even make sense for a Drupal web site for an organization run by volunteers? In this case, I speak from experience. I have spent a large portion of my life in volunteer positions and have been annoyed more than once by official forms that recognize paid work but not unpaid work. And while I have never had a favorite color, it is simple and demonstrates the concept.

  • Status changed to Fixed 5 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    Great, thanks! Instead of letting perfect be the enemy of good, since there are at least 2 of us in agreement that 'Favorite Primary Color' is better, let's go with that. It's only a stale handbook page, after all. ๐Ÿ˜… Let's fix the bug and move on.

    https://www.drupal.org/node/2192175/revisions/view/13394743/13404985 โ†’

    Thanks again,
    -Derek

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States dww

    Oh whoops, I don't have perms to save credits in this queue. @quietone, would you be willing to credit all of us?

  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand quietone New Zealand

    @dww, of course.

    I've added credit.

  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand quietone New Zealand

    This really is a welcome improvement! Thanks!

  • ๐Ÿ‡ณ๐Ÿ‡ฟNew Zealand quietone New Zealand

    Arg, I can't give credit here either!

  • ๐Ÿ‡ฎ๐Ÿ‡นItaly apaderno Brescia, ๐Ÿ‡ฎ๐Ÿ‡น
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.69.0 2024