Contrib.social

Double-underscore in property name breaks enity fields API

Open on Drupal.org →
Created on 7 March 2017, over 8 years ago
Updated 30 January 2023, over 2 years ago

To reproduce:
- Implement baseFieldDefinitions for some entity
- Define fields with ids which include double-underscores like "foo__bar", "foo__bang", and "zee__bar"
- Create a new instance of the entity, e.g. using entity_create(), populating those field values

Expected behavior:
- Entity instance has fields like "foo__bar", "foo__bang" and "zee__bar"
- $entity->value("foo__bar") returns the assigned value

Observed behavior:
- Entity instance has field "zee" with column "bar", and field "foo" with columns "bar" and "bang"
- $entity->value("foo__bar") returns null

Maybe this is a "feature".
I searched the issue queue for some background, but found very little.
At any rate, I found zero documentation, and no mention of this special behavior in baseFieldDefinitions documentation.

NB. creating a field with double-underscore machine name via Fields API exhibits the expected behavior.

🐛 Bug report
Status

Needs work

Version

9.5

Component
Field  →

Last updated about 4 hours ago

Created by

🇺🇸United States AaronBauman Philadelphia

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

    Worse Than Failure. Approximates the unpleasant remark made by Drupal developers when they first encounter a particular (mis)feature.

Sign in to follow issues

Comments & Activities

Not all content is available!

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

  • Comment over 2 years ago →
    needs-review-queue-bot

    The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

    Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

  • Status changed to Postponed: needs info 10 days ago
  • Comment 10 days ago →
    🇦🇺Australia acbramley

    Tested this on HEAD by adding the following to Node::baseFieldDefinitions and running drush si standard -y, then checking the node_field_data table:

        $fields['foo__bar'] = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Foo'))
      ->setRequired(TRUE)
      ->setDisplayConfigurable('form', FALSE)
      ->setDisplayConfigurable('view', FALSE);

    The column existed as expected. The code mentioned in #13 no longer exists, instead it uses the DefaultTableMapping class to get the column names directly.

    Can this issue be closed? Or is there another way to reproduce this?

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024