"add to cart" form with new product-node-type problem

Project:Ubercart Contributions
Component:Code
Category:
Priority:normal
Assigned:Unassigned
Status:patch (needs review)
Description
Project: 
Ubercart

Hi.
The error is:

warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'uc_product_add_to_cart_form_29' was given in /srv/www/vhosts/test.localhost/httpdocs/includes/form.inc on line 218." while browsing a my custom product-node

And you can guess, there is no any "Add to cart form" form Eye-wink

You can get this error by doing this:
1. Add a new node type and fill "module" field with "uc_product" (with the help of hook_node_info())
For example, my hook-func is:

<?php
function uc_balance_node_info() {
  return array(
   
'balance' => array(
     
'name' => t('Balance'),
     
'module' => 'uc_product',
     
'description' => t('Balance is special product type which can be represent as payment gateway. This can be used for prepayment mechanisms, automatic prolongation of some service-type goods and more... Customers on your site may have several balance types'),
    )
  );
}
?>

2. Register this node type as "product" with the help of hook_product_types()
My code is:

<?php
function uc_balance_product_types() {
  return array(
'balance');
}
?>

3. Create a new node of this node type and you'll get this error.

Also i found that hook_product_types() is not documented Sad

So my solution was making custom hook_forms() for my module with this code not changing main uc sources (only one line of uc_product_forms() code was changed).
But i hope that you will just fix it if it's a really bug Smiling

Thank you.

Version: 
Ubercart 1.0
PreviewAttachmentSize
uc_product.module.patch164 bytes
Joined: 08/07/2007
Juice: 6673

I'm specifically using only uc_product's node types for those callbacks because uc_product_kit has a somewhat different Add to Cart form. Using hook_product_types() here would add product_kits to hook_forms() twice, and differently, and I don't really know what would happen then.

Joined: 08/07/2007
Juice: 15046
Assigned to:Lyle» Ryan

It looks like other modules (I checked out UC Donation Product) implemented their own version of hook_add_to_cart_form() as well. I'd like to get around this if possible, so that a module can simply implement hook_product_types() and not have to worry about anything else unless it was overriding something.

+1 for getting some documentation on that hook. *pokes Lyle*

Joined: 08/14/2007
Juice: 3867
Assigned to:Ryan» torgosPizza

+1 to the idea of being able to map other node/content types as products without writing a custom module for it Smiling

hook_product_type('custom_node_type'); or something would be awesome. Smiling

Help directly fund development: Donate via PayPal!

Joined: 06/05/2008
Juice: 19
Assigned to:torgosPizza» Riki_tiki_tavi

Oh, what i've done wasn't official functionality?
/me stunned
Well, great. By the authority committed to me i declare this patch as a hack Laughing out loud

Joined: 08/07/2007
Juice: 6673
Assigned to:Riki_tiki_tavi» Lyle

I wouldn't go so far as to say you're going about it the wrong way, it's just that you didn't take into account the completely undocumented "gotcha" with the add to cart form. You can use hook_forms() to emulate uc_product_forms() and add your module's nodes to the list of those that use uc_product_add_to_cart_form(). That would make your module a more complete implementation.

Instead of using hook_product_types(), or uc_product_node_info(), the better thing to do might be to check the node's type's module. If that is uc_product, then it should obviously use uc_product_add_to_cart_form() for its Add to Cart form. In addition, uc_product_product_types() should probably do the same thing, so that modules adding more their own product classes don't have to implement hook_product_types() themselves, either.

Or we could wait until any node type can become a product type and make this entire problem go away. *shrug*

Joined: 08/07/2007
Juice: 15046
Assigned to:Lyle» Ryan

I guess I'd be in favor of both... unless the final solution you mentioned is feasible for the Uber Tuber, why not put in the sensible defaults for 2.0 and the final solution for 3.0?