I get the following errors on my order review page:

Notice: Undefined index: path in template_preprocess_entity() (line 865 of C:\wamp\www\faj\sites\all\modules\entity\entity.module).
Notice: Undefined index: path in template_preprocess_entity() (line 866 of C:\wamp\www\faj\sites\all\modules\entity\entity.module).

After some debugging I found that the array returned from entity_uri($entity_type, $entity) when $entity_type = 'commerce_customer_profile', only has the 'options' key with entity and entity_type and variables.

Files: 
CommentFileSizeAuthor
#18 custom_profile_uri-1392654-1.4-18.patch679 bytesDeciphered
PASSED: [[SimpleTest]]: [MySQL] 3,570 pass(es).
[ View ]
#1 1392654-customer-profile-uri.patch671 bytesmr.baileys
PASSED: [[SimpleTest]]: [MySQL] 3,553 pass(es).
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new671 bytes
PASSED: [[SimpleTest]]: [MySQL] 3,553 pass(es).
[ View ]

If registered, an uri callback should always return an associative array with 'uri' and 'options' as keys.

From hook_entity_info():

uri callback: A function taking an entity as argument and returning the uri elements of the entity, e.g. 'path' and 'options'. The actual entity uri can be constructed by passing these elements to url().

Commerce_customer registers an uri callback, but then relies on modules implementing commerce_customer_profile_uri to provide the actual data. If no module implements this hook, the uri callback just returns NULL (which is not a valid return value in this case), and the entity_uri adds the 'options' but the 'uri' value remains missing, resulting in the notices you are seeing.

Since commerce_customer_profile_uri only uses the result of the first hook implementation it encounters, and disregards the rest, it seems that this should not be a hook, and this might be better implemented by removing commerce_customer_profile_uri, not registering an uri callback, and allowing modules to register an uri callback via hook_entity_info_alter(). This is an api change though, so probably not considered for 1.x.

An alternative approach is to only register the uri callback if there is at least one module actually implementing hook_commerce_customer_profile_uri. The patch attached (untested) should take care of this.

Surely you could have a hook, but pass the return array by reference &$return . Any modules implementing the hook can then ignore it if its not their bundle, or change it if it is. Surely some default should be provided anyway?

Status:Needs review» Needs work

Surely you could have a hook, but pass the return array by reference &$return . Any modules implementing the hook can then ignore it if its not their bundle, or change it if it is.

The problem is that in your case, it seems that not a single module is implementing the hook, causing commerce_customer_profile_uri to return an invalid value to entity_uri(), which in turn causes the notices you are seeing. I don't think the return-by-reference is required, since modules can already act on specific bundles by only returning an uri from their hook_commerce_customer_profile_uri() implementation for the profiles they're interested in.

Surely some default should be provided anyway?

Well, I thought that commerce_customer_ui was implementing the hook_commerce_customer_profile_uri, but I was wrong. Instead, commerce_customer_ui alters the entity info to replace the uri callback. Note that in some cases (when a user does not have access to view the profile), commerce_customer_ui_customer_profile_uri also returns NULL (so this could also be causing the notices you are seeing? Is commerce customer UI enabled? Do you encounter the issue when logged in as admin?)

The more I look into this, the more confused I'm getting. The patch in #1 won't address the fact that commerce_customer_ui_customer_profile_uri returns an invalid value, so setting back to needs work.

Maybe this should be fixed in core rather that in commerce (allow entity_uri callbacks to not return an uri)?

Somewhat related:

Status:Needs work» Active

I agree that this problem should be addressed in the Entity module issue referenced in #3. But here are some possible workarounds you could try:

I could only reproduce this error with commerce_customer_ui turned off. Try turning customer UI module on (if it isn't already). If this doesn't solve it, then your user must be failing the access check in commerce_customer_ui_customer_profile_uri() on commerce_customer_ui.module line 244. Maybe you can tweak your permissions so that this doesn't happen and thus avoid returning null.

Status:Active» Postponed

I think we should postpone this on the core issue. (#1275902: Allow URI callbacks to return FALSE)

Title:Commerce Customer Profile Entity URI Returns BadlyCommerce can return invalid return values for uri callbacks.
Component:Customer» Other

Status:Postponed» Needs review

#1: 1392654-customer-profile-uri.patch queued for re-testing.

Status:Needs review» Postponed

Status:Postponed» Needs work

Not sure postponing is the right approach: *if* #1275902: Allow URI callbacks to return FALSE lands in the near future, it is extremely unlikely that it will be back-ported to D7, as it is an API change: contrib modules such as "Entity" and "Path" call entity_uri() and are currently not able to deal with a missing or "FALSE" return value.

I am also getting this error when deleting products, it would be great to get this resolved, thanks.

Applied the patch from #1 but still getting the error message.

I am encountering another manifestation of the same problem: running userpoints, if I create a userpoints transaction with an entity link to a commerce order, then the user viewing his own points will get "Undefined index: path in userpoints_create_description" if he does not have access to view the associated order.

I think the only solution is changing entity_uri() to catch the case where the uri callback exists but returns FALSE or NULL. I don't understand the concern expressed in #10: anyone who calls entity_uri() needs to handle a NULL return, since it can happen anyway if there is no uri callback.

I posted a D7 patch in #1578208: Allow URI callbacks to return FALSE.

@amateescu and @mr.baileys: Did you come to a conclusion whether this should be dealt with or still being postphoned for a core change?

Hi all, the problem still exists, does anybody have any advice on what the best way is to resolve this? Thank you.

thx, work for me

I like mr.baileys' approach in comment #1, but the same won't work to solve the related problem in the Order modules since the Order UI implementation of the callback sometimes doesn't return a URI if the user doesn't have access to view the order.

It seems like we might just need to update the Order UI module to always return a value, disregarding access, and trust other parts of Drupal to monitor the user's access to an entity before displaying a link to it.

And yeah, with #1275902: Allow URI callbacks to return FALSE stalled out on D8, I don't see any reason to wait around for this to be solved in core if we can solve it ourselves.

StatusFileSize
new679 bytes
PASSED: [[SimpleTest]]: [MySQL] 3,570 pass(es).
[ View ]

Patch attached for 1.4 so I can patch this issue via Drush for an active project.

Status:Needs work» Needs review

I purposely didn't mark it as 'Needs review' as it;'s a patch for 1.4, so regardless of how good the patch is it can never be committed.

We are having the same issues with latest kickstart.

Is it possible for us to implement the hook with some dummy data?
If yes what data do we neeed to provide to prevent these errors without hacking commerce.

@aspilicious: I'd imagine that you can implement hook_entity_info_alter, replace the "uri callback" with your own, call the original "uri callback" in your override and return dummy info if the original callback returns NULL/FALSE. This should at least prevent the notices from occuring.

I'm not sure what I can return as dummy data without breaking the flow.

Coming from #1929630: Calling entity_view on a product causes permissions errors if no "View Product" permissions.

I copied what commerce_product_ui did, but instead of returning NULL I returned the current path:

<?php
array('path' => current_path())
?>
.

In my case this is OK. It doesn't break anything and since I never link to the product entity directly, this dummy URL isn't too bad. If you use the rdf module it's going to output the HTML about attribute pointing to the current page. I don't know if this is really an issue, but it can be removed in hook_preprocess_entity.

Basically I'm duplicating the code of product_ui. This is not an ideal solution, but I don't expect product_ui to change too much in its uri callback, so for now this will work.

Status:Needs review» Active

I found this because of an error described in #1317742: Deleting an order from the order list causes Undefined index: path in redirect_delete_by_entity_path() error

Correct me if I'm wrong, but the pretense of this issue and #1317742: Deleting an order from the order list causes Undefined index: path in redirect_delete_by_entity_path() error is that entity_uri must return an array with 'path' and 'options' keys, and commerce isn't doing this.

It appears that this structured-array-return is no longer required. From http://api.drupal.org/api/drupal/includes!common.inc/function/entity_uri/7:

Return value

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.

In some cases, the function now seems to return NULL, just like commerce does.

So doesn't this then pass the resulting errors in the redirect module (#1317742: Deleting an order from the order list causes Undefined index: path in redirect_delete_by_entity_path() error) and the profile module down the line from commerce? (i.e. the fix should originate in the redirect module for #1317742: Deleting an order from the order list causes Undefined index: path in redirect_delete_by_entity_path() error, not commerce)

I had the same problem, but I had disabled Customer UI module, enabling of it should fix the problem.

Update:
#1275902-15: Allow URI callbacks to return FALSE seems to fix the issue in D7. Let's see if we can get the D8 patch over there applied and start working to get the D7 patch committed. That's really the root problem. Otherwise commerce_shipping (see above), commerce_product_reference (my issue is with commerce_product_reference_commerce_product_uri), and #2015341: entity_uri is not returning 'path' properly for commerce products all seem to need to implement their own (slightly different) solutions.