 |
UbercartOne cart to rule them all... |
|
| Donate | Affiliates | Sponsors | ||
Adding extra fields to the product
Submitted by sajt on Sun, 02/17/2008 - 12:22
Hello, I like to add some extra fields to the products in a laptop store. For example: memory, processor type etc. Some is text field and some is checkbox. I like to store it, show it to the user, and search on it, if it is possible. How can I make it?
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. Thanks. Later I find this. I forget to check some checkbox. I really wish that "classes" were just content-types. I feel like this would make using CCK alot easier. They are content types. The difference is that they're using the uc_product module to handle the default product fields. Go ahead and use CCK on any extra fields you need. Then you can use Contemplate to display all the fields any way you like. 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, too, am trying to create additional products fields for my products. cway, did you add this field using CCK? If so, it should be on the form automatically... Ryan, thanks for the quick response. Actually, the field IS on the new product page. It's at the very bottom. I didn't see it before. Thanks, Ryan. 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 <?phpAs 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) Not sure what needs it wouldn't meet, but it can't be replaced anyways b/c of the way the code looks for product information. 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.
|
|
Joined: 02/17/2008