user_uri() should not return an invalid path (user/0) for the anonymous user object

Agreed. We're running into this as part of the Drupal.org D7 upgrade. It's part of the problem we're trying to solve at #1983294: Special-case the display of field_issue_assigned to handle unassigned issues. But this is definitely a wider problem. It's evil that user_uri() returns an invalid path in this case.

For argument, here's a trivial D7 patch that fixes it.

And here's a D8 version.

Sorry, here's a valid D7 patch for the end of the 7.x branch.

Oh, except entity_uri (D7) and Entity::uri() (D8) always inject $uri['options'], even if there's no path, so all the places that assume they can safely test if the returned $uri is empty are broken (e.g. in entityreference) since the $uri always has ['options'] even if there's no path. Fun.

Okay, that's a legit test failure. Just not sure what's the right solution.

- rdf.module is incorrectly assuming that users always have a uri + path. Previously, those paths for anonymous sent you to a 404, but apparently no one ever cared.
- TrackerAttributesTest.php is explicitly checking for RDF attributes on a page created by an anonymous user.

So, if we fix rdf.module to not inject broken links into the RDF output for anonymous users, we also need to fix this test to only inspect the RDF tags on the anonymously posted article for attributes that make sense for anonymous users.

Can someone who understands RDF more than I take a look?

Thanks,
-Derek

Meanwhile, here's the D7 patch from #6 again to see what the bot thinks there.

In Drupal 7, hook_preprocess_user() was only invoked on user profile pages, but in Drupal 8, user_view() is called more frequently, such as on each node view to display the user picture. The issue came from a scenario in the tracker RDF tests where a node is posted as the anonymous user. I've updated the patch to solve this issue.

Sweet, thanks! Looks good to me, but since it's mostly my code, I probably shouldn't RTBC...

This patch is ready, but I wonder why we still need to provide both entity and entity type in the $uri['options'] array. That would be subject of a different patch though.

$uri['options']['entity_type'] = $this->entityType;
$uri['options']['entity'] = $this;

This looks eminently testable

#10: 1991464-10.user-uri-only-for-valid-users.d8.patch queued for re-testing.

The point wasn't that it needs to be retested by the bot, but that someone needs to write automated tests for this.

I'm not entirely clear what kind of tests we actually want here. A unit test to make sure that user_uri() returns NULL when given UID 0? Do we want a functional test that tries to follow links to profile pages and somehow asserts that the one for Anonymous isn't really a link?

I think better get rid of user_uri() in favour of $user->uri() and extend user test

#1275902: Allow entity URI callbacks to indicate that the entity has no URI, and make the User module use that for anonymous users looks very similar to this issue. haven't had the time to see which one is more advanced and which one should be marked as dup.

I think better get rid of user_uri() in favour of $user->uri() and extend user test

good idea, but this would out of scope of this issue (an API change too). please file a new issue.

Filed #2008616: Convert user_uri() to $user->uri()

@scor: thanks for the link. Agreed these are basically duplicate. Convention says we should continue there, since that's the older issue (even though the code here is better).

Just commented at:
#1275902: Allow entity URI callbacks to indicate that the entity has no URI, and make the User module use that for anonymous users

However, that issue includes a link to:
#1803586: Give all entities their own URI
which is depressing, since it intentionally undoes part of what this patch is trying to accomplish. :/

Updated issue summary.

I'm going to go ahead and mark this a duplicate of the above-mentioned issue. That issue is older and has had more recent work on it, and it now incorporates pretty much everything from this issue.