Calling uriRelationships() on an unsaved entity will cause an exception, as toUrl() is called.

The line about needing an ID can be copied from the docs for toUrl().

Comments

joachim created an issue. See original summary.

ioana apetri’s picture

Assigned: Unassigned » ioana apetri
ioana apetri’s picture

Assigned: ioana apetri » Unassigned
Status: Active » Needs review
StatusFileSize
new590 bytes

Here is the documentation added. Please review. Thanks:)

joachim’s picture

Status: Needs review » Reviewed & tested by the community

Looks good.

Thanks!

wim leers’s picture

Title: EntityInterface::uriRelationships() should document you can't call it in a new entity » EntityInterface::uriRelationships() should document you can't call it on a new entity
Status: Reviewed & tested by the community » Needs work

Thanks for helping to improve our documentation!

+++ b/core/lib/Drupal/Core/Entity/EntityInterface.php
@@ -230,6 +230,9 @@ public function hasLinkTemplate($key);
+   * The entity must have an id already. Content entities usually get their IDs

s/id/ID/

("IDs" later in the sentence gets it right.)

dhirendra.mishra’s picture

Assigned: Unassigned » dhirendra.mishra
dhirendra.mishra’s picture

StatusFileSize
new590 bytes
dhirendra.mishra’s picture

joachim’s picture

Status: Needs work » Reviewed & tested by the community

Thanks!

alexpott’s picture

Status: Reviewed & tested by the community » Needs review

If we're going to document this behaviour couldn't we do it with an @throws?

However thinking about this conceptually should we catch the exception in \Drupal\Core\Entity\Entity::uriRelationships i.e do something like:

      // It's not guaranteed that every link relation type also has a
      // corresponding route. For some, additional modules or configuration may
      // be necessary. The interface demands that we only return supported URI
      // relationships.
      try {
        $this->toUrl($link_relation_type)->toString(TRUE)->getGeneratedUrl();
      }
      catch (RouteNotFoundException $e) {
        return FALSE;
      }
      catch (EntityMalformedException $e) {
        return FALSE;
      }

The text at the top is interesting as it says

The interface demands that we only return supported URI relationships.

and what we're saying is that until the entity has an ID it doesn't support any URI relationships so this returns an empty array - rather than throwing an exception.

alexpott’s picture

Component: documentation » entity system
Issue tags: +Needs subsystem maintainer review

Tagging for subsystem maintainer review.

hchonov’s picture

#2924338: Entity::uriRelationships() throws exceptions if an URL cannot be generated because of missing mandatory parameters is a similar issue and even has a patch.

@alexpott, shouldn't the thrown exception here be of type MissingMandatoryParametersException like in the other issue?

However thinking about this conceptually should we catch the exception in \Drupal\Core\Entity\Entity::uriRelationships

Yes, I think we should catch the exceptions that are thrown if we could not generate a URL because of missing parameters. I think the solution for both issues has to be the same, as \Drupal\Core\Entity\Entity::uriRelationships() should not throw exceptions, but instead filter out the URI relationships that couldn't be automatically generated.

If you are fine with this I would close the current issue as a duplicate and move the discussion to the referenced one.

alexpott’s picture

@hchonov yep I agree this is a duplicate of that.

s.messaris’s picture

Assigned: dhirendra.mishra » Unassigned
Status: Closed (duplicate) » Needs review
Issue tags: -Novice, -Needs subsystem maintainer review
StatusFileSize
new475 bytes

I don't know if this is the right place for this, but the patch commited in #2924338 only catches MissingMandatoryParametersException , but there is also the case where an EntityMalformedException is thrown, so I am reopening this so we can fix it. In the spirit of #2924338, I am attaching a patch that catches that as well.

dhirendra.mishra’s picture

Looks ok..

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

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.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.

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

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

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

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

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should 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.

needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new177 bytes

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.

Version: 9.5.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. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.