Problem/Motivation

Something went wrong I think.
We ended up with a (mutable) static and I think we wanted an (immutable) constant.
Also because it's protected, can't use it elsewhere - whilst a constant is public by definition.

Proposed resolution

Fix

Remaining tasks

Review

User interface changes

None

API changes

I don't think so

Beta phase evaluation

Reference: https://www.drupal.org/core/beta-changes
Issue category Bug because API is wrong without it in my opinion (should not be mutable, should be public)
Issue priority Major because blocks #2403873: FileFormatterBase does not retain unsaved entities (files) which is major because it means data-loss
Disruption Could only possibly impact on dynamic_entity_reference (which I'm a maintainer of) - so none.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

larowlan’s picture

Status: Active » Needs review
FileSize
554 bytes
3.05 KB
dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Looks totally reasonable!

The last submitted patch, static-const.1.patch, failed testing.

larowlan’s picture

Priority: Normal » Major
Issue summary: View changes

This blocks #2403873: FileFormatterBase does not retain unsaved entities (files) which is major (data-loss) so bumping

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 4243b60 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation.

  • alexpott committed 4243b60 on 8.0.x
    Issue #2403793 by larowlan: EntityReferenceItem uses a static, but it...
plach’s picture

Status: Fixed » Needs work

Please revert this commit: the previous solution was meant exactly to avoid exposing the value outside the class, as it's an implementation detail. We have a proper API to check the value: EntityReferenceItem::hasNewEntity().

I'd use a protected constant if they were available...

larowlan’s picture

Should we set it to RTBC to get committer eyes?
thanks for explaining - should we add a comment documenting as such to prevent this happening again?

plach’s picture

should we add a comment documenting as such to prevent this happening again?

Good idea :)

alexpott’s picture

Title: EntityReferenceItem uses a static, but it was most likely supposed to be a constant » Document that EntityReferenceItem uses a static to protect access to a constant
Priority: Major » Normal

reverted

  • alexpott committed 09e8dda on 8.0.x
    Revert "Issue #2403793 by larowlan: EntityReferenceItem uses a static,...
plach’s picture

Status: Needs work » Active
dawehner’s picture

Sorry, I could have maybe known that from passive listening in ghent.

effulgentsia’s picture

Title: Document that EntityReferenceItem uses a static to protect access to a constant » EntityReferenceItem uses a static, but it was most likely supposed to be a constant
Priority: Normal » Major
Status: Active » Closed (works as designed)
jibran’s picture

Status: Closed (works as designed) » Needs review
Issue tags: +Documentation
FileSize
907 bytes

Here is the doc updated patch. Just for the record I knew this @fago told @plach in IRC why we should make this a static. I thought I could find something in #2232477: Fatal when adding new fields with NOT NULL constraints in a base table that contains existing entities but there is nothing this is the patch where @plach updated it from constant to static #2232477-104: Fatal when adding new fields with NOT NULL constraints in a base table that contains existing entities.

jibran’s picture

Status: Needs review » Closed (works as designed)
Issue tags: -Documentation

Sorry for the cross post I'll post the patch in other issue.