entity_uri() currently uses
$entity->uri for caching purposes, which is neither namespaced nor otherwise protected. In core, this clashes with the file entity, which has its own
uri property. This leads to the return value of
entity_uri() being wrong for file entities in a rather critical way (string instead of array).
Remove the undocumented caching for now to maybe later replace it with something more thought-out. A patch for that is in #15.
Review and commit the patch.
User interface changes
None. (Fixes code to comply to currently documented API.)
Original report by drunken monkey
I don't know why there isn't a bug report for this already, but basically calling
entity_uri() for file entities simply doesn't work.
entity_uri() docs state that the return value will be:
An array containing the 'path' and 'options' keys used to build the uri of the entity, and matching the signature of url(). NULL if the entity has no uri of its own.
However, internally the function uses a
$object->uri field for caching (instead of something more distinct and sensible, like
$object->entity_uri). Since the file entity already has a
$uri field set, this is automatically used, even though it is a string and not an array suitable for an uri callback /
I don't really know how this can be fixed in D7 without either breaking existing behaviour (at least for the undocumented
$object->uri field) or removing the
entity_uri() caching (thereby possibly causing considerable performance drops), but this is a serious flaw when handling file entities generically.
|#15||1057242--entity_uri-15.patch||2.65 KB||drunken monkey|
PASSED: [[SimpleTest]]: [MySQL] 35,982 pass(es). View
|#12||1057242--entity_uri-12.patch||1.84 KB||drunken monkey|
PASSED: [[SimpleTest]]: [MySQL] 32,930 pass(es). View
|#11||1057242--entity_uri-11-D8.patch||1.84 KB||drunken monkey|
|#11||1057242--entity_uri-11-D7.patch||497 bytes||drunken monkey|
|#3||drupal.file-uri.patch||489 bytes||drunken monkey|
PASSED: [[SimpleTest]]: [MySQL] 29,395 pass(es). View