Problem/Motivation

\Drupal\Core\Field\FieldItemBase::__get() checks whether a typed data property with the given name exists in order to decided whether to store the value in a typed data property or the internal values array. However, it checks this by using the array of already instantiated properties, rather than checking whether a property with that name should exist through its property definitions.

Proposed resolution

Use the property definitions rather than the list of already instantiated properties.

Remaining tasks

None.

User interface changes

None.

API changes

None.

Issue fork drupal-2413471

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Xano’s picture

Status: Active » Needs review
FileSize
795 bytes

This is the fix only. I'll think about how to test this when I have more time.

Xano’s picture

Xano queued 1: drupal_2413471_1.patch for re-testing.

Xano queued 1: drupal_2413471_1.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1: drupal_2413471_1.patch, failed testing.

Status: Needs work » Needs review

Xano queued 1: drupal_2413471_1.patch for re-testing.

Xano queued 1: drupal_2413471_1.patch for re-testing.

tim.plunkett’s picture

Issue tags: +Needs tests

Looks sane. Can we get some test coverage?

Xano’s picture

Thanks for the reminder. Is there a dedicated test for FieldItemBase already?

Xano’s picture

Bump.

Xano queued 1: drupal_2413471_1.patch for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1: drupal_2413471_1.patch, failed testing.

Xano’s picture

Thanks for the reminder. Is there a dedicated test for FieldItemBase already?

@tim.plunkett: I am trying to find out the right way to test this patch.

Berdir’s picture

This is by design, we explicitly avoid creating property objects to get non-computed values. This would be a considerable performance regression.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Xano’s picture

@Berdir: Do you have other ideas on how to solve this, or should we just keep the workaround from \Drupal\plugin\Plugin\Field\FieldType\PluginCollectionItemBase::__get()?

Xano’s picture

Status: Needs work » Closed (works as designed)

Talked to @berdir on IRC. He said this works as designed.

Xano’s picture

Status: Closed (works as designed) » Needs review
FileSize
1.29 KB
1.18 KB

Actually, what about this solution? This should address @berdir's performance feedback, yet allow values of computed properties to be retrieved.

Status: Needs review » Needs work

The last submitted patch, 18: drupal_2413471_18.patch, failed testing.

The last submitted patch, 18: drupal_2413471_18.patch, failed testing.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Berdir’s picture

This might work, but we need to check what the test fail there is about.

The last submitted patch, 18: drupal_2413471_18.patch, failed testing.

tedbow’s picture

Status: Needs work » Needs review
FileSize
2.31 KB
1.13 KB

This should fix the failing tests.

The problem was that the filter module wasn't being enabled for a couple of tests.

The new changes would cause the filter plugin to be loaded for instance in \Drupal\taxonomy\Entity\Term::getFormat().

The filter module is a dependency of text which a dependency of both node and taxonomy which were already be enabled for the affected tests. So in real site the filter module would already be enabled.

Status: Needs review » Needs work

The last submitted patch, 24: 2413471_24.patch, failed testing.

The last submitted patch, 24: 2413471_24.patch, failed testing.

tedbow’s picture

Status: Needs work » Needs review
FileSize
2.81 KB
513 bytes

Forgot to update MigrateTrackerUserTest as mentioned in #24

Wim Leers’s picture

I'd like to RTBC this, especially since @Berdir says in #22 that this looks good. But @tim.plunkett asked for tests in #8.

I don't know this system well enough to know what that test coverage should look like. Pinging Tim.

mlncn’s picture

Status: Needs review » Reviewed & tested by the community

Here by way of #2710421: Export URL alias configuration for nodes by way of #2649646: Normalize path fields as part of the entity: allow REST clients to know the path alias... can we make sure we do tests in that particular use case, allowing REST clients to get the path alias with an entity? Here we already make sure we don't break existing functionality with the more helpful getter.

alexpott’s picture

Status: Reviewed & tested by the community » Needs work

Still needs an explicit test.

tedbow’s picture

Status: Needs work » Needs review
FileSize
5.06 KB
2.35 KB

as per @alexpott's request here is a test.

andypost’s picture

+++ b/core/tests/Drupal/Tests/Core/Field/FieldItemBaseTest.php
@@ -0,0 +1,72 @@
+    $data_definition = $this->prophesize('\Drupal\Core\TypedData\ComplexDataDefinitionInterface');
...
+      ->willReturn($this->prophesize('\Drupal\Core\TypedData\DataDefinitionInterface')->reveal());
...
+      '\Drupal\Core\Field\FieldItemBase',
...
+    $typed_data = $this->prophesize('\Drupal\Core\TypedData\TypedDataInterface');
...
+    $data_definition = $this->prophesize('\Drupal\Core\TypedData\ComplexDataDefinitionInterface');
...
+      '\Drupal\Core\Field\FieldItemBase',

would be great to replace that with Classname:class instead of strings

tedbow’s picture

@andypost thanks for the review

fixed

Wim Leers’s picture

Pinged @Berdir for a review. I don't feel qualified to review this.

Berdir’s picture

I'll try to review this soon, but the exact use case isn't really clear anymore to me. I don't think this approach works for what Xano wanted to do initially, not if there is a value. I think we need at least an updated issue summary with the problem this solves and probably also an integration/kernel test to show how it can actually work.

Because it is *not* needed for computed fields like path, we are solving that differently now.

andypost’s picture

Version: 8.2.x-dev » 8.4.x-dev
Status: Needs review » Reviewed & tested by the community

Looks great to me, just no idea about backport to 8.2 because latest patch release is out

Berdir’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs issue summary update

Wondering if you crossposted with my comment? As I said, I'm not sure right now about the exact use case this solves and we definitely need a better issue summary and IMHO also better and "real" tests.

andypost’s picture

@berdir yep, sorry xposted.

+++ b/core/lib/Drupal/Core/Field/FieldItemBase.php
@@ -134,14 +134,21 @@ protected function writePropertyValue($property_name, $value) {
+    // Instantiate the property if it exists, and return its value. We do this
+    // last, because property instantiation is often slower than the previous
+    // retrieval methods.
+    elseif ($this->definition->getPropertyDefinition($name)) {
+      return $this->get($name)->getValue();
+    }

I'm using this because affected by #2563981: ContentEntityBase get and __get() works differently

Berdir’s picture

Yes, but I this will not fix much about that, because it only gets called *if* there is no value *and* the property is not computed. But if it's not computed then I'm not sure that getValue() should be doing anything except.. returning the value.

I'd like to see how exactly that affects real use cases. It will definitely not help #2649646: Normalize path fields as part of the entity: allow REST clients to know the path alias in any way as far as I see.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

tim.plunkett’s picture

Issue tags: +Blocks-Layouts

This soft-blocks #2905922: Implementation issue for Layout Builder, but the last patch works great.

tedbow’s picture

re @Berdir's comment in #39

I'd like to see how exactly that affects real use cases.

@tim.plunkett can you explain how this affects #2905922: Implementation issue for Layout Builder
I didn't see this issue mentioned there. It might give us a better idea of a "real" bug this is solving.

tim.plunkett’s picture

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

geek-merlin’s picture

> Is #2934192: FieldItemBase::getValue() returns partial or full values depending on state a dupe of this?

@tim, On first sight it looks so. But this patch changes FieldItemBase::__get(), while the other changes TypedData//Map::getValue(). Also the symptoms are quite different so i don't see how one might fix the other.

andypost’s picture

andypost’s picture

Hardik_Patel_12’s picture

Patch failed to applied for 9.1.x , re-rolling for the same . Kindly review.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

catch’s picture

Status: Needs review » Needs work
Issue tags: +Needs tests

Still applies but I agree with Berdir this could use a kernel test to show the actual situation that this helps, which isn't at all clear.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

bradjones1 made their first commit to this issue’s fork.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Mingsong made their first commit to this issue’s fork.

jackwrfuller made their first commit to this issue’s fork.