 |
Ubercart |
|
|
|
||
Adding extra fields to the product
Submitted on Sun, 02/17/2008 - 11:22
 How can I add products field and list it just below the default products fields? Hi Lyle; Thanks in advance!  What I mean is there is all this extra stuff. Like in order to not have shipping for a single content-type show up in the edit form, I have to make a hook_form_alter() and hide it. If I don't agree with the product model (I don't have 3 price fields for any products) and the client will be way overwhelmed by options that have nothing to do with their stock, then I have to do alot of tweaking. I think it would be awesome if it just added a content-type (using the default product fields as you say) and they were actually controllable in UI (CCK style) so I could remove fields I don't use. The ecommerce module uses "features" like this (which in my install of ubercart, there are no "features") to modularize the product model, but it's still not as cool as being able to just get rid of things that I really don't need, or change the labels in the UI, or make fields not required by clicking a checkbox. Ubercart already has a CCK dependency (correction: it suggests it's use), so it wouldn't add anything. This would mean that I could use the muriad of other CCK modules to play with the values, too, like attributes are just tokens for SKU, and a computed field for price. This would mean that I could use the UI to make crazy price adjustments like "if they order a comb, a brush is %50 off". Autonodetitle or pathauto on things like product-attributes? To do things like this now, I am copying values from CCK fields, and manipulating built-in fields in hook_cart_item() and hook_form_alter(). I think it'd be great if I didn't have that extra step for advanced stuff (unless, of course, there wasn't already a CCK way of doing it, in which case I could write a much smaller custom module, that could be used in many applications.) I mean, ubercart really great, don't get me wrong, but I have spent alot of time var_dump()'ing $form, and $item, and playing around with things, in order to change the way the product edit forms are displayed (the API reference is awesome, by the way.) I think it would save time, at least for me, if the product-classes were just content-type dumps to be used as defaults, but everything was manipulatable, and mapped to things the cart needs (like price, weight, and stock.) I guess I imagine my perfect shopping cart acting more like views (and alot of the functionality could actually be handled by views, as it is in ubercart) in that you can override frontpage and taxonomy_term in UI, to do whatever you want to it. I think if it were all built with sensible defaults (just like ubercart) it wouldn't be any harder to get going for new people, but it would be super-easy to customize (and have tons of cool features, out of the box) for anyone who has worked on a views/cck site. If the cart was just a node holder, or some sort of view, and shipping and payment was just a node-processor (all 3 using using mapping to the CCK fields that represent things like weight, price, and stock) then I wouldn't have write as much code. Maybe I'm just not understanding how ubercart works, so forgive me if I am missing something, but I am really addicted to the amount of cool stuff you can do with just CCK/Views, and this has been my only real frustration with ubercart. Other then that, I think it's perfect, and it's definitely more cohesive and easier to work with, for me, then the ecommerce module. Sorry for the rant...  I am using CCK to add additonal fields to the product content type. I realised that the SKU, list price, cost, and sell price are not CCK fields and therefore not manageable by CCK. I am wondering what is the best way of manipulating of the SKU field such that I am able to place the SKU field under another fieldset along with other CCK fields. Can this be done using alter form hook or do I really need to hack into the uc_product.module?  @cway: if you're adding this with hook_form_alter(), you can change its positioning using weights. If it's simply a field to enter in a year, I'd recommend the CCK module to ya. @ystanley: in order to avoid an outright dependency on CCK, these default product fields are handled separately as you've found out. However, instead of hacking the core module, you can instead write a custom module that uses hook_form_alter() to reorganize and adjust what fields are displayed to the user. That's what I was explaining above. I went this route, and it works ok, I just wish that I could've done it all without having to make a hook_form_alter (I thought ubercart does depend on CCK already, but looking at the project page, it appears it only "recommended", so this makes a little more sense to me, now) Here's what I did to hide the other price fields (in a custom module): <?phpChange YOURMODULE to the name of your custom module that you put this function in, and YOURNODETYPE to the content-type for the nodes that you want to modify. I actually have to do a bunch of other stuff to the edit form (conditional pricing on options, configurable per product, etc), so I am doing some funky copying of CCK values back and forth on hook_form, and an extra _submit function to get it to work the way I want, but this should get you started. I figured out what all needed to be edited by putting a <?phpin the hook_form_alter function. As a side-note (but still related, I think) I'd like to realize my dream ecommerce solution, based on these ideas (use CCK for as much as possible, make cart more of a "glue" layer, rather then the main thing, do everything with cck/views/triggers/actions, so you can model your own cart format/flow using standard drupal tools, etc) and would love any advice from e-commerce / ubercart contributors. My target is D6, which appears to make alot of these sort of things a bit easier (triggers/actions in core, rather then requiring workflow-ng)  thank you konsumer for your post. Since not everbody is familiar with the hook-form-alter() function, here a tutorial : And here just a stupid question from a newbie. If the product node do not meet our needs, can we just replace it ? (don't shoot please)  Just for anyone else who stumbles on this thread... I've recently the formfilter module and it seems to work quite well. It allows you to hide form elements for every form through the UI, instead of creating a module just to use hook_form_alter. Since each product class is a different node type, each will have it's own form which can be controlled by formfilter. Not what you need if your doing any heavy modifications to forms, but great for just hiding a few fields. |
|
The magical and wondrous CCK modules. It should already be in use on your site to provide image support for your products. Start by poking around the Content types page in the administration and add fields to your product types. If you need more product types for more differentiation, head over to Store administration > Products > Manage classes.