entity_uri is not returning 'path' properly for commerce products

Hey choicelildice,

Looks like you came to the same conclusion as me! I suggest updating your patch to use isset() instead of array_key_exists() for a slight efficiency/performance increase.

#1900618: Undefined index: path in registration_form()

Cheers!

Attached is a patch using isset. DO NOT USE! Re-rolling to make it so it will work from the module's directory.

Here is a properly formatted patch using isset.

Keep an eye on this related core issue that may render this patch obsolete: https://drupal.org/node/1275902

Commerce product module defines uri callback (commerce_product_uri) for product but doesn't actually define any menu items. If we observe the code for commerce_product_uri, it checks for hook_commerce_product_uri implementations. If there are no implementations, it returns NULL hence only 'options' are set in entity_uri().

I implemented that hook and warning disappeared. We will no longer need to implement it if #1275902: Allow entity URI callbacks to indicate that the entity has no URI, and make the User module use that for anonymous users is getting fixed. Hope this helps.

This will also fix #1900618: Undefined index: path in registration_form()

@tanmayk
I confirm this fixes the 'Registration' module. I was receiving the following notice:

Notice: Undefined index: path in registration_form() (line 153 of .../sites/all/modules/contrib/registration/includes/registration.forms.inc).

Patch at #3 worked for me, but then I found another very similar issue. Using the same approach I have added another check for uri path to avoid having any more warnings appear. I have also included the patch from #3 here aswell

The patch looks good jbabiak. For completeness, can you tell me what I need to do to replicate the notice?

This issue still occurs with version 1.5 of entity registration using Commerce Registration 2.1.

Patch in #8 removes the notice.

Thank you!

LeDucDuBleuet,

Were you getting the notice from patch 8 or patch 3 or both? Was the notice on 154 or 73 or both?

Yes the issue occurs when using the commerce_registration module.

The issue is that the registration form is being included and displayed directly on the checkout forms, so there is no need for a cancel link that needs to redirect back to anywhere else or a link to the host entity. Patch in #3 fixes the cancel link case and #8 extends that to fix both the issue with the cancel link and the link back to the host entity. In the case of commerce_registration there isn't really a path to view a product entity. The patches fix these cases by not building the links within the form if no uri parameters have been provided.

Like @leducdubleuet, I can also confirm that patch #8 fixes the issues listed here.

Took the changes from #8, made them work for Entity Registration module version 7x.-1.6

Applies nicely to latest code

works great for me.
re-rolled to remove "sites/all/modules/registration" from paths.

I applied the patches for 7.x-1.6 and now the event name is not displaying. And I get this error:

This registration is for: field is required.

@pwsherman Are you sure you applied the patch correctly?

It works well up here.

Here is a newer version of the patch that removes hard coded "sites/all/modules/registration" from 'b' as well. Previous patch had removed it from 'a' only on diff lines.

This has been committed and will be in the next 1.x release.

UPDATE: As of April 18, 2018, the patch from #19 DID RESOLVE the issue for me, patching against the 7.x-1.6 recommended/stable release, from 7 October 2015.

For me, I was seeing the issue when adding registration fields in views (such as edit/delete registration). In my case, these registrations were tied to commerce transactions, through the commerce registration module.