Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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
Comment | File | Size | Author |
---|---|---|---|
Screen Shot 2013-01-27 at 8.42.36 PM.png | 40.64 KB | rurri |
Comments
Comment #1
rurri CreditAttribution: rurri commentedSubmitted bug to wrong project.
Comment #2
mallezieI 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).
Comment #3
seanberto CreditAttribution: seanberto commentedIsn't this a Commerce Registration issue? I don't know that this ticket was submitted to the correct queue.
Comment #4
rurri CreditAttribution: rurri commentedLooks 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.
Comment #5
jpontani CreditAttribution: jpontani commentedThe 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.
Comment #6
jpontani CreditAttribution: jpontani commentedSee #1787148: Undefined index: path in template_preprocess_entity() as well
Comment #7
pcorbett CreditAttribution: pcorbett commentedIt 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?
Comment #8
jpontani CreditAttribution: jpontani commentedTry 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.
Comment #9
pcorbett CreditAttribution: pcorbett commentedYes 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.
Comment #10
pcorbett CreditAttribution: pcorbett commentedIf 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.
Comment #11
djkentuckyham CreditAttribution: djkentuckyham commented@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
Comment #12
pcorbett CreditAttribution: pcorbett commentedHi @djkentuckyham: I just turned off notices for now (admin/config/development/logging). Doesn't SEEM to affect anything at this point.
Comment #13
djkentuckyham CreditAttribution: djkentuckyham commented@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
Comment #14
agileadamIs 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.
Comment #15
deanochips CreditAttribution: deanochips commentedenable "Edit any product of any type" under permissions
Comment #16
rachel_norfolkdeanochips - 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?
Comment #17
deanochips CreditAttribution: deanochips commentedyour right, i ment "View any product of any type"
thats what happens when your in a hurry & you copy and paste....
Comment #18
peter.milan CreditAttribution: peter.milan commentedThe 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.
Comment #19
retrodans CreditAttribution: retrodans commented#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'.
Comment #20
agileadam@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
Comment #21
hilrap CreditAttribution: hilrap commentedsubscribe
Comment #22
tanmaykhttps://drupal.org/comment/8383709#comment-8383709
Comment #23
blacklabel_tom CreditAttribution: blacklabel_tom at Edo commentedClosing this as it is an issue with the registrations module.