After Clicking Checkout I get the following error:

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

Screenshot attached

CommentFileSizeAuthor
Screen Shot 2013-01-27 at 8.42.36 PM.png40.64 KBrurri
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

rurri’s picture

Project: Commerce Registration » Entity Registration
Version: 7.x-2.x-dev » 7.x-1.0-beta3
Component: Code » Registration Core

Submitted bug to wrong project.

mallezie’s picture

I had the same message. This is caused by a permission problem. If you give the necessary roles to view the products, the message is handled correct.

I don't think it's a bug, since you should be able to view the products you can buy. (Although registration is some special case).

seanberto’s picture

Isn't this a Commerce Registration issue? I don't know that this ticket was submitted to the correct queue.

rurri’s picture

Project: Entity Registration » Commerce Registration
Version: 7.x-1.0-beta3 » 7.x-2.x-dev
Component: Registration Core » Code
Priority: Normal » Minor

Looks like it was a permission issue, and in fact was correctly assigned to commerce registration originally.

Sounds like commerce registration needs to do some friendlier access checks in deciding which registrations to show.

Moving back to commerce registrations project, and downgrading priority to minor.

jpontani’s picture

The issue is due to the 'path' attribute of the URI not being set for a Commerce Product, and in Entity API there is no sanity check, as for a URI, the path must be set. I'll see what I can figure out.

jpontani’s picture

pcorbett’s picture

Priority: Minor » Normal

It seems this is traceable all the way back to registration_form() line 15 in the registration module where $host has a value and thus on line 132, it builds the $form lacking an #href for what seems to be a cancel button. I'm not positive what form is being manipulated/built at this point, however, but I can only assume it is some kind of admin form since this page loads fine for admins.

This issue is coming up for us when we try to register on a COD D7 site as an anonymous user for an event. I can "fix" this issue by giving the $uri['path'] some value.

Can you help shed some light on this and perhaps I can help patch?

jpontani’s picture

Try enabling the Commerce Customer UI module, and see if this issue disappears. I've heard, from other sources, that enabling this module remedies the problem.

pcorbett’s picture

Yes I had thought that too but it turns out that module has always been enabled. I can start debugging this but didn't know if anyone had some insight as to the specific cause.

pcorbett’s picture

If it helps you, I've traced this particular issue (for me it's using this module in conjunction with COD) first on line 137 of registration.forms.inc, which eventually calls line 283 in commerce_product_ui.module, which makes a call to commerce_product_uri(). Because commerce_product_uri() returns null in my case (due to the lack of a $product->dislplay_context on line 14 of commerce_product_reference.module), it falls back and assumes that if no URI is provided that it can return the URI for an admin (if they have permission). In my case, the user is anonymous and thus on line 137 of registration.forms.inc, no path is given and it throws the notice in question.

What should probably happen is that there is else clause that catches the alternate case where a user is not an admin and a path is not given so that a notice isn't thrown.

I haven't quite debugged down to the level where we can see WHY the display_context doesn't exist (since, it seems we did everything necessary to make that happen in the COD distribution).

If you think it would be helpful, I can dig a bit deeper, but at this point, it's just a notice and doesn't actually affect the bottom line.

djkentuckyham’s picture

Issue tags: +registration

@pcorbett, #10
Hi, I too am experiencing this issue and was wondering if you ever implemented a working solution. In my case the Registration module works find (as long as I am an authenticated user). Not the case for 'anonymous'. I am experiencing the following screen error at submission of populated cart after "Check out" button is selected. Error repeats for each item in cart. I am not using or am familiar with COD.

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

Any help or direction would be greatly appreciated.

Essentially, I want anonymous users to be able to begin checkout process. I will invoke an account creation rule later in checkout process.

Thanks in advance
R

pcorbett’s picture

Hi @djkentuckyham: I just turned off notices for now (admin/config/development/logging). Doesn't SEEM to affect anything at this point.

djkentuckyham’s picture

@pcorbett
Thank you, that worked for me. Because I will need logging, I am going to look into a way to fix this (hopefully hook form alter). If/when I do? I will post here. For now? Much more to get done to go live. thank you very much for the tip.

DJ

agileadam’s picture

Is there any reason we cannot just check for $uri['path'] before trying to render a Cancel link? I too am trying to let users register for commerce_product entities that do not have paths. Let me know if this is just wrong. I'd provide a patch but it doesn't seem like a fix that would be universally-accepted.

--- a/registration/includes/registration.forms.inc  (7.x-1.1)
+++ b/registration/includes/registration.forms.inc (7.x-1.1)
@@ -131,11 +131,13 @@ function registration_form($form, &$form_state, Registration $registration) {

   if ($host) {
     $uri = entity_uri($registration->entity_type, $host);
-    $form['actions']['cancel'] = array(
-      '#type' => 'link',
-      '#title' => t('Cancel'),
-      '#href' => $uri['path'],
-    );
+    if (isset($uri['path'])) {
+      $form['actions']['cancel'] = array(
+        '#type' => 'link',
+        '#title' => t('Cancel'),
+        '#href' => $uri['path'],
+      );
+    }
   }
deanochips’s picture

enable "Edit any product of any type" under permissions

rachel_norfolk’s picture

deanochips - surely you don't mean that for the people purchasing things? Wouldn't that mean they could edit the products??

I'm a fan of checking for the value as mentioned in #14. Any reason this would not be acceptable?

deanochips’s picture

your right, i ment "View any product of any type"

thats what happens when your in a hurry & you copy and paste....

peter.milan’s picture

The solution to allow permission "View any product of any type" did not work form me. I also agree with solution #14, but this fix is located in another module registration.

retrodans’s picture

#14 worked nicely for me too, "agileadam" did you want to create a patch so this can be reviewed? If not, I am happy to, but looks like you already have, just need to save as a .patch and attach to a comment marked 'needs review'.

agileadam’s picture

@retrodans, looks like someone posted a very similar patch to the Registration module issue queue (where this actually belongs). I believe isset() is faster than array_key_exists(), so maybe I'll suggest that to the author of that patch.

I'm leaving the status of this issue alone.

Anyhow, anyone still interested in this issue, please redirect your attention here: #2015341: entity_uri is not returning 'path' properly for commerce products

hilrap’s picture

subscribe

tanmayk’s picture

blacklabel_tom’s picture

Issue summary: View changes
Status: Active » Closed (works as designed)

Closing this as it is an issue with the registrations module.