Problem/Motivation

Since #2910211: Allow computed exposed properties in ComplexData to support cacheability., implicit cacheability bubbling is deprecated, because there now finally is a way for normalizers to bubble cacheability metadata of the data they're normalizing.

As of #2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code, deprecation errors result in test failures. But any deprecation errors that result in core test failures are ignored, for now.

Proposed resolution

Let's fix all deprecation errors for the deprecation that #2910211 added. This is then also fixing REST/Serialization technical debt. That deprecation is:

Implicit cacheability metadata bubbling (onto the global render context) in normalizers is deprecated since Drupal 8.5.0 and will be removed in Drupal 9.0.0. Use the "cacheability" serialization context instead, for explicit cacheability metadata bubbling. See https://www.drupal.org/node/2918937

Remaining tasks

  1. Find all the places.
  2. Fix them.

User interface changes

None.

API changes

None.

Data model changes

None.

CommentFileSizeAuthor
#62 2922487-62.patch7.56 KBjofitz
#62 interdiff-2922487-58-62.txt1.82 KBjofitz
#58 2922487-58.patch8.47 KBjofitz
#54 2922487-54.patch9.21 KBWim Leers
#54 interdiff.txt4.4 KBWim Leers
#50 2922487-50.patch11.75 KBWim Leers
#50 interdiff.txt965 bytesWim Leers
#49 2922487-49.patch11.52 KBWim Leers
#49 interdiff.txt1.56 KBWim Leers
#46 2922487-46.patch11.28 KBWim Leers
#46 interdiff.txt3.89 KBWim Leers
#44 2922487-44.patch11.66 KBWim Leers
#44 interdiff.txt1.59 KBWim Leers
#42 2922487-42.patch11.7 KBWim Leers
#42 interdiff.txt1.06 KBWim Leers
#40 2922487-40.patch11.66 KBWim Leers
#40 interdiff.txt1.48 KBWim Leers
#35 2922487-35.patch10.98 KBWim Leers
#35 interdiff.txt895 bytesWim Leers
#34 2922487-34.patch10.59 KBWim Leers
#34 interdiff.txt2.3 KBWim Leers
#33 2922487-33.patch10.59 KBWim Leers
#33 interdiff.txt1.02 KBWim Leers
#31 2922487-31.patch10.59 KBWim Leers
#28 2922487-28.patch10.59 KBWim Leers
#28 interdiff.txt2.54 KBWim Leers
#27 2922487-27.patch8.1 KBWim Leers
#23 2922487-23.patch8.1 KBWim Leers
#23 interdiff.txt852 bytesWim Leers
#21 2922487-21.patch7.49 KBWim Leers
#21 interdiff.txt1.51 KBWim Leers
#20 2922487-20.patch8.93 KBWim Leers
#20 interdiff.txt2.77 KBWim Leers
#13 2922487-13.patch8.22 KBWim Leers
#13 interdiff.txt1.8 KBWim Leers
#11 2922487-11.patch6.49 KBWim Leers
#11 interdiff.txt2.5 KBWim Leers
#5 2922487-5.patch4.03 KBWim Leers
#5 interdiff.txt777 bytesWim Leers
#4 2922487-4.patch4.4 KBWim Leers
#4 interdiff.txt1.11 KBWim Leers
#3 2922487-3.patch3.34 KBWim Leers
#3 interdiff.txt1.8 KBWim Leers
#2 2922487-2.patch1.57 KBWim Leers
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Wim Leers created an issue. See original summary.

Wim Leers’s picture

Status: Active » Needs review
FileSize
1.57 KB
Wim Leers’s picture

FileSize
1.8 KB
3.34 KB

Most of the failures are in the HAL REST tests. Let's fix those.

Wim Leers’s picture

FileSize
1.11 KB
4.4 KB

All Comment, EntityTestLabel, Item, Media and Node REST tests are also failing, due to \Drupal\serialization\Normalizer\EntityReferenceFieldItemNormalizer::normalize() using Entity::url() (which is a deprecated API too), which calls Url::toString(), which automatically bubbles onto the global render context, hence triggering the deprecated code path.

Wim Leers’s picture

Assigned: Wim Leers » Unassigned
Issue tags: +@deprecated
FileSize
777 bytes
4.03 KB
+++ b/core/modules/hal/src/Normalizer/ContentEntityNormalizer.php
@@ -8,6 +8,7 @@
+use Drupal\rest\EventSubscriber\ResourceResponseSubscriber;

Unused.

Wim Leers’s picture

Wim Leers’s picture

Issue summary: View changes

This should come back green, and should be ready for final review.

The last submitted patch, 2: 2922487-2.patch, failed testing. View results

The last submitted patch, 3: 2922487-3.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

Status: Needs review » Needs work

The last submitted patch, 5: 2922487-5.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
2.5 KB
6.49 KB

Status: Needs review » Needs work

The last submitted patch, 11: 2922487-11.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
1.8 KB
8.22 KB

I forgot to fix one.

tedbow’s picture

+++ b/core/modules/rest/tests/src/Functional/EntityResource/Media/MediaResourceTestBase.php
@@ -154,7 +154,6 @@ protected function getExpectedNormalizedEntity() {
-          'url' => $file->url(),

@@ -166,7 +165,6 @@ protected function getExpectedNormalizedEntity() {
-          'url' => $thumbnail->url(),

I am confused because this issue seems to be about just removing deprecation warnings. So not using a deprecated code path.

But here we are actually changing what is expected in a the normalized entity. If are just fixing the use of deprecated code shouldn't the REST responses not change?

dawehner’s picture

+++ b/core/modules/hal/src/Normalizer/ContentEntityNormalizer.php
@@ -179,17 +179,22 @@ public function denormalize($data, $class, $format = NULL, array $context = [])
-  protected function getEntityUri(EntityInterface $entity) {
+  protected function getEntityUri(EntityInterface $entity, array $context = []) {
...
+    $generated_url = $url->setRouteParameter('_format', 'hal_json')->toString(TRUE);
+    $this->addCacheableDependency($context, $generated_url);
+    return $generated_url->getGeneratedUrl();

How is that working? Right now, $context is not passed by reference. \Drupal\serialization\Normalizer\NormalizerBase::addCacheableDependency manipulates $context, but then nothing happens? I'm a bit confused ...

tedbow’s picture

re #15 my understanding is you don't actually need to pass the $context by reference.

$context[ResourceResponseSubscriber::SERIALIZATION_CONTEXT_CACHEABILITY] contains an instance of \Drupal\Core\Cache\CacheableMetadata. So since it is object you always have reference to it(unless you explicitly clone it).

So in \Drupal\serialization\Normalizer\NormalizerBase::addCacheableDependency()
$context[ResourceResponseSubscriber::SERIALIZATION_CONTEXT_CACHEABILITY]->addCacheableDependency($data);
does affect the $context that \Drupal\rest\EventSubscriber\ResourceResponseSubscriber::renderResponseBody will have access to.

If \Drupal\serialization\Normalizer\NormalizerBase::addCacheableDependency() added or removed keys from the $context array itself then that would not affect the $context variable that the caller had because arrays are not passed by reference by default.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Oh nevermind, PHP is, well, not the nicest language :)

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 13: 2922487-13.patch, failed testing. View results

Wim Leers’s picture

I am confused because this issue seems to be about just removing deprecation warnings. So not using a deprecated code path

Right :/

+++ b/core/modules/rest/tests/src/Functional/EntityResource/Media/MediaResourceTestBase.php
@@ -154,7 +154,6 @@ protected function getExpectedNormalizedEntity() {
-          'url' => $file->url(),

@@ -166,7 +165,6 @@ protected function getExpectedNormalizedEntity() {
-          'url' => $thumbnail->url(),

This is a BC break.

+++ b/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
@@ -51,8 +51,9 @@ public function normalize($field_item, $format = NULL, array $context = []) {
-      if ($url = $entity->url('canonical')) {
...
+      if ($entity->hasLinkTemplate('canonical') && $url = $entity->toUrl('canonical')->toString(TRUE)) {

This is the root cause.

The old code calls ::url(), the new code calls ::toUrl(). Why? Because \Drupal\Core\Entity\Entity::url() calls Url::toString(), which bubbles onto the global render context, which is the thing that is deprecated.

Unfortunately, \Drupal\file\Entity\File::url() is overridden to have completely different behavior. File entities do not actually have a canonical URL, but File::url() was effectively hacked in #2277705: Files don't have URI nor href (kinda "you're not hacking core if core is already hacked").

And that hack is now broken.

There is sadly only one work-around AFAICT: special case the File entity in the normalizer.

Wim Leers’s picture

Status: Needs work » Needs review
Related issues: +#2277705: Files don't have URI nor href
FileSize
2.77 KB
8.93 KB

Added a terrible work-around which spreads #2277705: Files don't have URI nor href's bad decision further, but that's the only way to retain BC AFAICT.

Wim Leers’s picture

FileSize
1.51 KB
7.49 KB

Status: Needs review » Needs work

The last submitted patch, 21: 2922487-21.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
852 bytes
8.1 KB
UnexpectedValueException: External URLs do not have route parameters.

because as of #20, we're passing/storing an absolute external URL to \Drupal\Core\Url.

The last submitted patch, 21: 2922487-21.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 23: 2922487-23.patch, failed testing. View results

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.

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
8.1 KB

No longer applied. Rebased.

Wim Leers’s picture

The changes in File with the crazy work-arounds for BC actually caused all these test failures. AFAICT #2277705: Files don't have URI nor href really has put us in an impossible situation… :(

This introduces work-arounds so that the REST test coverage is aware of the lying that \Drupal\file\Entity\File has to not break BC, but in not breaking BC, it must continue to return invalid values … and hence it breaks the REST test coverage! So we need to make the REST test coverage aware of the brokenness of File after all.

AFAICT this is the best possible solution…

The last submitted patch, 27: 2922487-27.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 28: 2922487-28.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
10.59 KB

Rebased #28.

Status: Needs review » Needs work

The last submitted patch, 31: 2922487-31.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
1.02 KB
10.59 KB

A 10-minute round of debugging didn't reveal the root cause. I'm quite confused how this could cause entity_test tests to fail. But I did spot one stupid mistake I made in #28 that surely cannot help…

Wim Leers’s picture

It'd help if I made #33's change consistently… and now suddenly most tests should pass!

Wim Leers’s picture

This just might be green… 💪

The last submitted patch, 34: 2922487-34.patch, failed testing. View results

The last submitted patch, 33: 2922487-33.patch, failed testing. View results

Status: Needs review » Needs work

The last submitted patch, 35: 2922487-35.patch, failed testing. View results

Wim Leers’s picture

Assigned: Unassigned » Wim Leers

So close! Three failures left, all three about 406s instead of 403s.

Wim Leers’s picture

Assigned: Wim Leers » Unassigned
Status: Needs work » Needs review
FileSize
1.48 KB
11.66 KB

borisson_’s picture

+++ b/core/modules/file/src/Entity/File.php
@@ -78,12 +79,42 @@ public function setFileUri($uri) {
+    // Lie because we must provide BC.
...
+    // Lie because we must provide BC.

This comment doesn't really provide a lot of value.

This might be better, but I'm not sure.
To provide BC, we provide the old value for canonical links.

Wim Leers’s picture

Fair!

borisson_’s picture

Sorry for not finding this earlier:

+++ b/core/modules/file/src/Entity/File.php
@@ -78,12 +79,42 @@ public function setFileUri($uri) {
+    // REST support for file entities. https://www.drupal.org/node/2825487 makes
+    // this obsolete.
...
+    // @todo Remove in https://www.drupal.org/node/2825487.
...
+    // @todo Remove in https://www.drupal.org/node/2825487.

The issue linked to from here is already closed (also, both that issue and this one end on 487 just to make things extra confusing).

Wim Leers’s picture

Good catch; clarified the comments.

Berdir’s picture

  1. +++ b/core/modules/file/src/Entity/File.php
    @@ -78,12 +79,42 @@ public function setFileUri($uri) {
        */
    +  public function toUrl($rel = 'canonical', array $options = []) {
    +    // To not break BC, the old behavior is retained for 'canonical'.
    +    // @see ::url()
    +    // @todo Remove in Drupoal 9.0.0.
    +    if ($rel === 'canonical') {
    +      return Url::fromUri($this->url());
    +    }
    +    return parent::toUrl($rel, $options);
    +  }
    +
    

    Seems like this is heavily overlapping with #2402533: Provide File::createFileUrl() as a replacement for the deprecated File:url() implementation, as you also commented there.

    I'm not too happy about adding more code that's already deprecated, also without doing any deprecation messages.

    We have the already deprecated \Drupal\hal\Normalizer\FileEntityNormalizer, could we override getEntityUri() there and deal with file like that? Then it's all in one place and in 9.x, we can just remove that file. I think that's what we should have done from the beginning instead of overriding url() like that in the file entity class.

    An argument could be made that another entity type has a similar special override of url() and this would break it, but that's already kind of broken, you already have the url() call above that you call *despite* not having a canonical link template. The whole thing is a special case for file.

    And now we rely that file does lie about implementing the canonical link template so that we skip the condition that we befor e had specifically for file :)

  2. +++ b/core/modules/hal/src/Normalizer/ContentEntityNormalizer.php
    @@ -179,17 +179,25 @@ public function denormalize($data, $class, $format = NULL, array $context = [])
         // out to ->url().
         if ($entity->isNew() || !$entity->hasLinkTemplate('canonical')) {
           return $entity->url('canonical', []);
         }
         $url = $entity->urlInfo('canonical', ['absolute' => TRUE]);
    -    return $url->setRouteParameter('_format', 'hal_json')->toString();
    +    if (!$url->isExternal()) {
    

    This is still calling urlInfo(). which is deprecated, just doesn't trigger a warning yet, does it make sens to fix that here too?

Wim Leers’s picture

  1. Seems like this is heavily overlapping with [#2402533: No], as you also commented there.

    I know this overlaps with #2402533: Provide File::createFileUrl() as a replacement for the deprecated File:url() implementation — see your comment #2402533-83: Provide File::createFileUrl() as a replacement for the deprecated File:url() implementation and my response #2402533-84: Provide File::createFileUrl() as a replacement for the deprecated File:url() implementation from 6 months ago.

    We have the already deprecated \Drupal\hal\Normalizer\FileEntityNormalizer, could we override getEntityUri() there and deal with file like that? Then it's all in one place and in 9.x, we can just remove that file. I think that's what we should have done from the beginning instead of overriding url() like that in the file entity class.

    I like that proposal a lot! But AFAICT it'd still result in deprecation warnings. Far fewer, but they'd still be there. Which would mean we won't be able to do this:

    +++ b/core/tests/Drupal/Tests/Listeners/DeprecationListenerTrait.php
    @@ -153,7 +153,6 @@ public static function getSkippedDeprecations() {
    -      'Implicit cacheability metadata bubbling (onto the global render context) in normalizers is deprecated since Drupal 8.5.0 and will be removed in Drupal 9.0.0. Use the "cacheability" serialization context instead, for explicit cacheability metadata bubbling. See https://www.drupal.org/node/2918937',
    

    But, nonetheless, I did try to implement what I think you mean. I do think it's the better approach. It also means this issue doesn't need to make any changes to \Drupal\file\Entity\File anymore, which makes this issue far simpler!

    Can you please review the changes? :)

  2. I tried to keep the scope as tight as possible, but you're probably right. Done.
Berdir’s picture

  1. +++ b/core/modules/hal/src/Normalizer/ContentEntityNormalizer.php
    @@ -179,17 +179,25 @@ public function denormalize($data, $class, $format = NULL, array $context = [])
        * @return string
        *   The entity URI.
    

    we should probably improve the return documentation a bit and mention that it can be a string (deprecated?) or a GeneratedUrl object?

  2. +++ b/core/modules/hal/src/Normalizer/FileEntityNormalizer.php
    @@ -69,4 +70,16 @@ public function normalize($entity, $format = NULL, array $context = []) {
    +   * {@inheritdoc}
    +   */
    +  protected function getEntityUri(EntityInterface $entity, array $context = []) {
    +    // https://www.drupal.org/project/drupal/issues/2277705 introduced a hack
    +    // in \Drupal\file\Entity\File::url(), but EntityInterface::url() was
    +    // deprecated in favor of ::toUrl(). The parent implementation now calls
    +    // ::toUrl(), but this normalizer (for File entities) needs to override that
    +    // back to the old behavior because it relies on said hack.
    +    return $entity->url('canonical', []);
    +  }
    

    can't you do the same here as you did in getEntityUri() ?

    Convert that string again to a url object and add the option?

    That means the deprecation message that you want to get rid of here won't go away.

    We can't make the one from url() go away once we actually add that but we'll have to figure that out when we add that and want to get rid of the deprecation messages then.

    Actually... you could just call file_create_url($this->getFileUri()) directly here if we want to avoid the (future) deprecation messages.

    I'm actually not 100% sure what the final behavior in 9.x will be now for file in a REST response.

    We now have the file URL in a separate computed field, so overriding uri is already deprecated. IMHO, I would also expect that the file then would not have a top-level self link anymore, like I suggested in the issue referenced above. which means...

  3. +++ b/core/modules/hal/src/Normalizer/ContentEntityNormalizer.php
    @@ -179,17 +179,25 @@ public function denormalize($data, $class, $format = NULL, array $context = [])
    -  protected function getEntityUri(EntityInterface $entity) {
    +  protected function getEntityUri(EntityInterface $entity, array $context = []) {
         // Some entity types don't provide a canonical link template, at least call
         // out to ->url().
         if ($entity->isNew() || !$entity->hasLinkTemplate('canonical')) {
           return $entity->url('canonical', []);
         }
    

    I'm not quite sure where this part should go, we can possibly figure it out as part of removing/really deprecating url(), but a separate issue for it probably makes sense, again based on comment that it is valid that an entity does not have a self link, so instead of returning url(), we should just return NULL and the caller should then allow that.

Status: Needs review » Needs work

The last submitted patch, 46: 2922487-46.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
1.56 KB
11.52 KB

#46 failed because it removed work-arounds that were necessary for this:

--- a/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
+++ b/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
@@ -55,8 +55,9 @@ public function normalize($field_item, $format = NULL, array $context = []) {
       // Add a 'url' value if there is a reference and a canonical URL. Hard
       // code 'canonical' here as config entities override the default $rel
       // parameter value to 'edit-form.
-      if ($url = $entity->url('canonical')) {
-        $values['url'] = $url;
+      if ($entity->hasLinkTemplate('canonical') && $url = $entity->toUrl('canonical')->toString(TRUE)) {
+        $this->addCacheableDependency($context, $url);
+        $values['url'] = $url->getGeneratedUrl();
       }
     }

And we need to make that change to fix the deprecation warning.


#48:

  1. Convert that string again to a url object and add the option?

    AFAICT we can't because then file_create_url() won't be called.

    Actually... you could just call file_create_url($this->getFileUri()) directly here if we want to avoid the (future) deprecation messages.

    That's indeed a way make future removal even easier. Good call :)

    I'm actually not 100% sure what the final behavior in 9.x will be now for file in a REST response.

    We now have the file URL in a separate computed field, so overriding uri is already deprecated. IMHO, I would also expect that the file then would not have a top-level self link anymore, like I suggested in the issue referenced above. which means...

    Right, but we can only remove that self link in Drupal 9, right? Or do you see a way to do that without breaking BC?

  2. Again: we can't return NULL today, right? Because that'd be a BC break.

Implemented @Berdir's suggestion, but this patch will still fail in the exact same way due to the reason provided at the top of this comment.

Wim Leers’s picture

Here's a work-around attempt for the problem described in #49 in EntityReferenceFieldItemNormalizer.

The last submitted patch, 49: 2922487-49.patch, failed testing. View results

Wim Leers’s picture

That worked :) Back to @Berdir for review!

Berdir’s picture

  1. +++ b/core/modules/hal/src/Normalizer/ContentEntityNormalizer.php
    @@ -179,17 +179,25 @@ public function denormalize($data, $class, $format = NULL, array $context = [])
        * @return string
        *   The entity URI.
    

    #47.1

  2. +++ b/core/modules/hal/src/Normalizer/ContentEntityNormalizer.php
    @@ -179,17 +179,25 @@ public function denormalize($data, $class, $format = NULL, array $context = [])
         // Some entity types don't provide a canonical link template, at least call
         // out to ->url().
         if ($entity->isNew() || !$entity->hasLinkTemplate('canonical')) {
           return $entity->url('canonical', []);
         }
    

    and #47.3 ;)

  3. +++ b/core/modules/rest/tests/src/Functional/EntityResource/EntityResourceTestBase.php
    @@ -419,6 +419,8 @@ protected function getExpectedCacheContexts() {
       public function testGet() {
         $this->initAuthentication();
         $has_canonical_url = $this->entity->hasLinkTemplate('canonical');
    +    // @todo Remove in https://www.drupal.org/node/2825487.
    +    $has_canonical_url = $has_canonical_url && static::$entityTypeId !== 'file';
    

    as far as I see, these changes are not necessary anymore? hasLinkTemplate() is already FALSE, so this isn't doing anymore anymore.

    I reverted all changes in this file and at least FileHalJsonCookieTest passed just fine.

  4. +++ b/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
    @@ -55,8 +55,14 @@ public function normalize($field_item, $format = NULL, array $context = []) {
    +      // @todo Remove in Drupal 9.
    +      // @see \Drupal\hal\Normalizer\FileEntityNormalizer
    +      else if ($entity->getEntityTypeId() === 'file') {
    +        $values['url'] = file_create_url($entity->getFileUri());
           }
    

    Why can't we handle this with a setting, just like bc_file_uri_as_url_normalizer?

    I guess we can't do this until we resolve #2925520: Add a computed 'file_url' property to FileItem (for exposing file URL in file field normalization). what about instead of a @todo on 9, make it a @todo pointing to that issue and there we add file_url and deprecate this?

Wim Leers’s picture

  1. Isn't this still always returning a string? I must be overlooking something. Sorry :(
  2. That means the deprecation message that you want to get rid of here won't go away.

    That's indeed why. Getting rid of that deprecation warning is the goal of this issue. So, I kept this.

  3. Fewer changes FTW! (Possible since #46, thanks to your suggestions in #45 ❤️)
  4. 😍👌 Why didn't I think of that?

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.

Wim Leers’s picture

Ping @Berdir

Berdir’s picture

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

Huh, where exactly did all those months go since the last update here :)

1. No I did, I missed the getGeneratedUrl() call. All good.

I think this looks great now, pretty small patch in the end, without any change to the outside and fewer deprecated method calls. Would have set this to RTBC, but apparently the patch needs a reroll for 8.7 according to #54?

jofitz’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
8.47 KB

Re-rolled.

Wim Leers’s picture

Status: Needs review » Reviewed & tested by the community

Huh, where exactly did all those months go since the last update here :)

😃 I know, time flies!

1. No I did, I missed the getGeneratedUrl() call. All good.

Great!

I think this looks great now, pretty small patch in the end, without any change to the outside and fewer deprecated method calls. Would have set this to RTBC, but apparently the patch needs a reroll for 8.7 according to #54?

🎉

Thanks, @Jo Fitzgerald for the reroll! Per @Berdir's feedback, moving to RTBC :)

The last submitted patch, 54: 2922487-54.patch, failed testing. View results

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
  1. +++ b/core/modules/rest/tests/src/Functional/EntityResource/EntityResourceTestBase.php
    @@ -1470,7 +1470,8 @@ protected function makeNormalizationInvalid(array $normalization, $entity_key) {
    -    if ($this->entity->hasLinkTemplate('canonical') && ($this->account && static::$auth !== 'cookie')) {
    +    $has_canonical_url = $this->entity->hasLinkTemplate('canonical');
    +    if ($has_canonical_url && ($this->account && static::$auth !== 'cookie')) {
    

    This change is unnecessary - no?

  2. +++ b/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
    @@ -55,8 +55,14 @@ public function normalize($field_item, $format = NULL, array $context = []) {
    +      // @todo Deprecate in https://www.drupal.org/project/drupal/issues/2925520
    +      // @see \Drupal\hal\Normalizer\FileEntityNormalizer
    +      else if ($entity->getEntityTypeId() === 'file') {
    +        $values['url'] = file_create_url($entity->getFileUri());
           }
    

    Are we deprecating or removing?

jofitz’s picture

Status: Needs work » Needs review
FileSize
1.82 KB
7.56 KB

Addressed comments in #61.

Wim Leers’s picture

Status: Needs review » Reviewed & tested by the community

Right; that contained logic changes in an iteration from long ago. But now it indeed can be dropped altogether. Great! :) Thanks, Alex and Jo! 👌

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 68c0fd8 and pushed to 8.7.x. Thanks!

diff --git a/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php b/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
index e1cef84817..c5b869cb86 100644
--- a/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
+++ b/core/modules/serialization/src/Normalizer/EntityReferenceFieldItemNormalizer.php
@@ -61,7 +61,7 @@ public function normalize($field_item, $format = NULL, array $context = []) {
       }
       // @todo Remove in https://www.drupal.org/project/drupal/issues/2925520
       // @see \Drupal\hal\Normalizer\FileEntityNormalizer
-      else if ($entity->getEntityTypeId() === 'file') {
+      elseif ($entity->getEntityTypeId() === 'file') {
         $values['url'] = file_create_url($entity->getFileUri());
       }
     }

Fixed coding standards on commit.

  • alexpott committed 68c0fd8 on 8.7.x
    Issue #2922487 by Wim Leers, Jo Fitzgerald, Berdir, tedbow, borisson_,...

Status: Fixed » Closed (fixed)

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