15 replies [Last post]
Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15459
Was this information Helpful?

Ahh, yes, a productive day is always nice. I got cracking on the product features system I brainstormed about in this thread. The end result is something that looks a lot different and is much simpler. I really like the interface, too. Eye-wink

So, what is the product features system? Well, it is a handy new API that lets modules declare new product features that may be added to individual products in your catalog. These features are things like a role assignment, a file download, a gift card, etc. The API is very lightweight and simply provides an easy way for users to attach features to individual product nodes. You can see the form that gets generated when product feature modules are enabled in the screenshot attached to this post.

In this initial version, the rest of the work (like detecting this product purchase on checkout) should be handled by the module itself using the normal Ubercart hooks (like hook_order()).

Please note that product features should not be confused with:

  • Product attributes which let customers specify the details of a product and then modify the price and other product info based on their choice.
  • CCK fields which let administrators store custom data to the product nodes.

So, the API is very simple to use. First, there is hook_product_feature() which your module should implement to tell Ubercart that it defines a product feature type. This should return an array of product feature arrays like so:

<?php
function ucpf_example_product_feature() {
 
$features[] = array(
   
'id' => 'example',
   
'title' => t('Example feature'),
   
'callback' => 'uc_example_feature_form',
   
'delete' => 'uc_example_feature_delete',
   
'settings' => 'uc_example_feature_settings',
  );
  return
$features;
}
?>

The keys are pretty straightforward - a unique id string, a display title, a callback for the add/edit form, a delete function to call when a feature gets deleted from a product, and a settings function to define form elements for the settings page in the product configuration.

Your callback form should receive two arguments, a node object and a feature array. It should present the form elements required for your feature to be added to this project (like a set of checkboxes to specify which product role should be granted when this project is purchased). You can use the arguments passed to the callback to fill in default values when a feature is being edited. There is a helper function called uc_product_feature_form() that adds form elements for the nid, feature id, submit button, and cancel link that should be used. The submit function should also make use of the function uc_product_feature_save() to create/update the feature when it is saved. This includes providing a meaningful description to display on the features overview page (the screenshot attached below).

The delete function doesn't need to return anything... it should simply be used to delete any appropriate info from the database pertaining to that feature. A module isn't required to implement this function if it isn't necessary (for example, if a product feature saves all its data in the description field).

The settings function should simply return an array of form elements that will be added to a fieldset for that product feature. If the module doesn't require any settings, well... then this isn't necessary.

I have attached an example module that create a feature by implementing the hook and callbacks. Feel free to check it out and start using the API. I'm holding off till tomorrow to put up Alpha 7e so this can go in. Look for role purchasing in Alpha 8 thanks to Shawn. Cool

Go ahead and update to the development version to test it out. Post any bugs or ideas up here. And... have a nice evening. Eye-wink

PreviewAttachmentSize
example_product_feature.tar5 KB
features-form.jpgfeatures-form.jpg26.92 KB
Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15459
Re: Product features system now in core

Real briefly, some may be wondering why this system is even necessary. The short answer is that this creates a simple way for module developers to add optional data and features to products without having to add more and more fieldsets and form elements to the already long product node edit form. Having a simple review table makes it easy for administrators to see the features at a glance, and using a separate form for each feature makes it easier to have complex features and multiple features in a single product.

What your feature does is totally up to your module, along with what actions should fire off its code. For example, a multiple purchase discount module may use this system to administrators can go edit a product, go to its features tab, and click the add button for a quantity discount. That would then display the form from the module that lets them specify what discount to offer for what quantity (say 10% off for 5 or more, and another for 20% off for 20 or more). When the user proceeds to checkout, the quantity discount module would simply check the node IDs of product in the cart against the product features table and see if any quantity discounts have been applied to it. It would handle the logic to know how much of a discount to show on the line items section or elsewhere.

This should be used by modules looking to add any sort of per product feature. For example, a role promotion or a file download may be attached to a product. Depending on the module, they may let you add the feature to any purchase of that product or only to a purchase of that product with a particular SKU (think of a product that can either be a physical CD or a download in mp3 format).

I'm looking for early adopters to help refine the system, so consider using product features if you have any per product need.

StephenGWills's picture
Offline
Uber DonorBug FinderEarly adopter... addicted to alphas.Getting busy with the Ubercode.Not Kulvik
Joined: 08/07/2007
Juice: 415
Re: Re: Product features system now in core

I have a lot on my plate this week for some reason. I hope that means I'm coming into my own finally! Anyway, another requirement we have is certain products that are Buy two, get one free. You specifically mention this as one of the applications of Product features?

Anybody else need a B1G1 Free discount?

torgosPizza's picture
Offline
Bug FinderEarly adopter... addicted to alphas.Getting busy with the Ubercode.
Joined: 08/14/2007
Juice: 4111
Re: Re: Re: Product features system now in core

Could definitely use a B1G1 discount - but would that be more of an application of the Discounts module than Product Features? Although it would be beneficial to ONLY apply that discount to certain products. This could maybe be solved using taxonomy as well.

--
Help directly fund development: Donate via PayPal!

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15459
Re: Re: Re: Re: Product features system now in core

Interesting idea... I could see this going either way... where you add 2 to the cart and the discounts module knows to decrease the price or where you simple add 1 and a B1G1 product feature updates the order details post-checkout. I'm curious how you'd plan on displaying this deal to the customer... like should the QTY in cart and checkout screens show the free one? Or should it just be a nice little message on screen somewhere?

Personally, I'd love to see this as a stand alone product feature for sites that don't need the whole discounts module.. but it would be nice to have it in both places. Sticking out tongue

StephenGWills's picture
Offline
Uber DonorBug FinderEarly adopter... addicted to alphas.Getting busy with the Ubercode.Not Kulvik
Joined: 08/07/2007
Juice: 415
Re: Re: Re: Re: Re: Product features system now in core

On our current site, a late 90's PERL roll yer own, this feature was implemented as a separate SKU. Of course this results in confused customers trying to buy their 2 and having 6 arrive! Smiling

My preference would be that someone buys qty 2, we add a line item at no charge.

qty desc tot
2 DigStim $20.00
1 DigStim $ 0.00

Something tells me this is going to require a little more logic than the B1G1 would since there is a qty threshold test to meet before feature kick off.

Abey's picture
Offline
Joined: 07/25/2011
Juice: 6
Dynamic website designing

Dynamic Web Designing, New Delhi - Noida - Gurgaon

If you are looking for professional dynamic website solution,dynamic website designing then it’s time to lighten up and relax since you have landed up at the right place. We are a leading web development company located in New Delhi, India, offering quality dynamic website solutions to clients from varied industries and varying budgets. Blessed with strong and commendable attributes of in-depth knowledge and laudable creativity, our talented designers competently design and develop quality dynamic websites using diverse scripting language, preferably PHP/Mysql. From using right set of tools to adhering to W3C guidelines, indusWebi takes care of every little thing that helps in delivering attractive-looking, traffic-oriented, simple to navigate, seamless websites.

pyrello's picture
Offline
Joined: 08/26/2008
Juice: 13
Using the product feature api

Hello,

I am in the process of trying to figure out a solution for adding webforms to products. The two most important aspects of this is that the forms have to be presented before or at the time that the user is adding the item to the cart -and- the information collected in the form is tied to that particular transaction, such that reports can be run later on. I have already articulated most of the details in this post: http://www.ubercart.org/forum/ideas_and_suggestions/6448/productrelated_...

Anyways, after doing some research, I am thinking that the best way to do this is to make the webform a product feature. Ideally, it would integrate with the current webform module, but that module is more complex than I am going to be able to understand in the time that I have to figure this out.

Could you elaborate a little about the API as it relates to this particular project? I am very open to any ideas of how I might be able to make this work within the next two weeks.

Thanks,

Sean

Ryan's picture
Offline
Joined: 08/07/2007
Juice: 15459
Re: Using the product feature api

Hey Sean, not sure how this could best tie into the product feature system or if it really needs to. You might try contacting Kris (EclipseGc @ drupal.org) of The Worx Co. about his Ubercart + Webform work. He may have already done something extremely similar to what you mentioned.

activelyOUT's picture
Offline
Joined: 04/20/2009
Juice: 70
Re: Re: Using the product feature api

can I apply product features per attribute sku?

torgosPizza's picture
Offline
Bug FinderEarly adopter... addicted to alphas.Getting busy with the Ubercode.
Joined: 08/14/2007
Juice: 4111
Re: Re: Re: Using the product feature api

Yes.

--
Help directly fund development: Donate via PayPal!

activelyOUT's picture
Offline
Joined: 04/20/2009
Juice: 70
Re: Re: Re: Re: Using the product feature api

Yeah. I should have been more specific. can i apply userpoints features per product sku?

I don't think I can. I think it is an issue with that module

strae's picture
Offline
Joined: 02/08/2010
Juice: 13
Thanks for the example

Looking at the example provided in this thread and at module uc_roles shipped with ubercart, i've been albe to set-up my module for a custom feature to products.

My goal is to create a feature where the administrator can associate a Simplenews Taxonomy term to the products, and when the customer buy the produce should be subscribed to that newsletter.

I've been able to set up the module to crate, edit and delete the feature (pretty simple with the example provided), but now I dont understand what hooks are available when a user buy the product, in order to subscribe him to the newsletter.. any help?

arskipaski's picture
Offline
Joined: 02/17/2010
Juice: 99
Hey there, It seems that in

Hey there,

It seems that in D7 the "settings" attribute is required for any feature definition, otherwise Notice: Undefined index: settings in uc_product_feature_settings_form() is thrown. Is that so by design and what is the proper way to _not_ have settings in this scenario? I've set 'settings' => FALSE but I'm not sure if that's the most elegant/appropriate thing to do here.

Thanks in advance for your help.

TR
TR's picture
Offline
Bug FinderFAQ ModeratorGetting busy with the Ubercode.
Joined: 11/05/2007
Juice: 3297
Re: Hey there, It seems that in

Bug reports belong in the Ubercart issue queue at http://drupal.org/project/issues/ubercart Please use the issue queue for things like this rather than post on ubercart.org.

PHP Notices are turned on by default in Drupal 7 (they were off by default in Drupal 6), which is why you see this notice in D7 and not D6. I've committed a change to check the existence of the 'settings' key before using it, which should eliminate the notice. The notice doesn't affect the operation of the code.

<tr>.
arskipaski's picture
Offline
Joined: 02/17/2010
Juice: 99
Re: Re: Hey there, It seems that in

yup, should've moved http://drupal.org/node/1216518 over to your issue queue straight away, but this just happened to look very related.

Thanks for fixing!