improving how we turn non-products into products

Ok, it took me a couple minutes to track down where to re-enable products on my node types. One thing I hadn't thought about until now. This new method allows only one type of product to be associated with a node type. I know I have a client that will be selling a nodes that can be any of several products types depending on the situation. This would really be a pain as I'd have to make a super product and combine these product types or something similar. Is there a way we can add the ability to enable multiple/all product types?

Nice work!

The approach of selecting from existing product types to apply to a node type was something I hadn't picked up from our previous conversations. It's a great idea, as it enables something we can't readily do with product.module--extend existing product types.

Please take the time to use Drupal coding standards (two-space indents, comments as full capitalized sentences, boolean FALSE and TRUE in uppercase, etc.).

You're right about the comment here:

		// system_settings_form should do this for us:
		$form['buttons']['#weight'] = 99;

If there isn't one already, please consider submitting a patch on Drupal core.

Somehow the define being a string with spaces looks awkward to me, but not sure what else makes sense. The integer 1?

Altogether this is looking very good. I'd say push ahead and include a patch to remove the current product_to_product stuff. With this in place, no one will miss it!

I'm just slightly worried that product module is getting watered down a bit. To get something useful out of product now, you need to load addons modules. It might be more efficient, and perhaps even easier on the user by only having to enable 1 module.

Robin

Here are a few test cases we discusses on IRC:

1) Make a fexinode type, set it to always be a product.
2) Make a fexinode type, set one created node to be a product
3) Configure a blog/page/forum to be a product
4) Un-productize a flexinode
5) Make a product, buy a product, then unproductize it's node.

Robin

The standard way to create products which have images has been for each product to be an "image" node. Then, you productize this image into any of several product types; e.g file, tangible, parcel, or other custom product types which you have created.

If each node type only maps to one product type, then if you want your products to have images, you have to create new node types which inherit behavior of the image module. E.g. using something like http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/jareyero/modu...

I have looked at the peaceful co-existance and it looks good that we have lots of fine grain control over productizing content types and individual pieces of content. I'd like to ensure that with works in practice.

1) audio types are are set to be type coupon in admin/settings/content-types/audio
2) ?q=node/add/audio configure as product
3) ?q=node/13/product turns to ?q=node/13/product/tangible

So now we have a ambiguous product types, which is the flexibility we wanted. However, I think node/#/edit should display the product type in the product fieldset.

I can't commit with the node type to product type being fixed. I have some sites where they create story nodes and then turn them into different product types, depending on what is being sold.

Also I am a bit reluctant to add another module to the ecommerce core. Esp, for a function that is used by most sites, and is happy to live in the product module.

Also if you are wanting to move this functionality out of the product module, I need the patch to remove all the existing functionality from the product module.

Where I would like to see this kind of change going is to put product features (like stock control, gift certificates, etc) into CCK, so a user can build a product with all the features that they require.

I've got some updates to this that show another option. This adds the ability to have multiple ptypes associated with a node type.

Changes:
1) update the content type form to allow selection of multiple ptypes. right now if not a product is selected it overides the other types.
2) update the create form to show checkboxes of the ptypes. Also has a collapsed field set for each ptype. Only the selected ptype will be validated/saved(not done. ui evalution only. add products to nodes the old way). not a product can be selected to not create a product with the node.
3) update and edit look the same as create if no ptype is attached to the node. if a ptype is attached to the node we show only that types options and add a checkbox to delete the product information from the node. this makes more sense now than the make product used before.

Reading through this.

1) I don't get the idea of having one node sold as different product types. Case-study?

2) If I was asked to decide which product types linked to which node types, then I'd like to define the connections I need in the product settings or via some sort of configurable taxonomy tree.

3) Over-all, I like yogadex's approach - improve the UI of an existing function.

I mentioned a use case applicable to me that I should probably put here for everyone else. A site sells games and the game can be a file product or a custom drm/serial number product depending on the developer. Developing seperate node types for the same content just so we can attach different products doesn't really make sense.

Also, there are sites making use of the previous functionality that wouldn't be able to be updated(I ran into this when I tested the module as I use story nodes to test the node_to_product functionality for products I'm working on).

Its really a functionality I don't think we should loose. I'm all for the rest of it though. I love the added granular attachment of products. I see how most sites will only have one product type attached to a node so this makes a lot of sense. Better permission handling is great! Also, the UI modifications look really good to me. Integrating product creation and node creation was on my wishlist so a big plus there.

Anyways, that's my 2cents for what its worth :)

I am not sure we want product selection to occur during editing. But I do see it useful to indicate what product type is the default for the node type or what product type have been selected for this particular node.

Kieran

I haven't finished looking over it but one quick issue. I can't remove all product types from a node in the content-types admin. If we are going to not use the 'not a product' option then checkboxes might be better.

I haven't had time to thoroughly review this yet. The general approach looks good. I have one question/request.

Ideally we would be putting in place an extensible model where we can define new product types that receive attributes. For example, each new node type defined as a product will need its own shipping settings (through the shipping module changes I'm working on). I foresee us rewriting most of the existing product types as sets of attributes. E.g., tangible, file, etc.

For this to work, we need the node types here to register as new product types. E.g, ptype='audio' (or, perhaps, ptype='node_audio'). product_get_ptypes() should return these new node types as well as 'traditional' ones.

I know that this comment comes a bit late in the game. Possibly we'll have to do this as a subsequent patch.

I have taken a quick look at the patch and I have found a few issues.

1. Do not put an entire node into the callback arguments in the menu. This is a waste of memory esp. in php4. php5 isn't so bad because objects are past by pointer so you will only have 1 copy but php4 will have many. node_load() caches nodes so it will not hit the database again to get the node.

2. Don't have multiple form_alter hooks, it will make things harder to maintain.

Also is there any reason for the change in the name of the url?

This patch needs a fix on line 1348 of the patched product.module, the code, once its properly formatted should look like this:

  if (!$ptype && (count($settings['product_types']) == 1)) {
    $ptype = array_shift($settings['product_types']);
  }
   else if (arg(3) && in_array(arg(3), $settings['product_types'])) {
    $ptype = arg(3);
  }

The fix is that you are trying to assign $ptype to the value of $settings['product_types'][0] but its an assoc array so it becomes defined as nothing, then displays a blank page since there is no default behaviour if $ptype contains nothing.

Also, i am havin issue with the array_merge in _product_transform_get_settings. I think its not necessary and tosses an error on my install. Here is my replacement starting on line 1242:

function _product_transform_get_settings($ntype = NULL) {
  if (!$ntype) {
    return $settings;
  }
  $settings = variable_get('product_transform_settings', array());
  return $settings[$ntype];
}

i was getting an error on the array_merge(). It was merging an empty array with the settings array, which I dont see a point of, unless I am reading the code wrong....

Ok, after talking to yogadex we found another instance of the error mentioned in #26. So I've put together a patch from the discussion with both of those fixes. Also, I put together a little fix for the array_merge problem. check _product_transform_get_settings for changes.

Everything looks very good from my end. I'm quiet happy with the patch.

the patch...

i want to let everybody can turn node(non-products and added by other body) into products,how can i do?

That's the functionality this patch is trying to update. After it is applied you are able to add product types to content types and then convert nodes to products. This is the new process for converting a node to a product node.

1. install product modules to provide the required product types
2. make sure your user has the ability to administer products
3. go to admin/settings/content-types and add the product types you want associated with each node type
4. add new nodes and the product information or add product type to an existing node by clicking on the product tab show when viewing the node.

Hi,
I am trying to install the patch, but get the below error. Can you help me out!
Thanks a lot
Rudy
-----------
D:\www\drupal\modules\usr\local\wbin>patch product.module 62682.patch.txt
patching file `product.module'
Assertion failed: hunk, file patch.c, line 321

This application has requested the Runtime to terminate it in an unusual
Please contact the application's support team for more information.

I have taken a look at this, and I think that there is still some work required.

I do not like the idea of having both the tab and the form inserted into node_form. This may cause some confusion and it is a bit redundent.

What I would like to see is to remove the product tab. Turn this into a callback so that the user can select from the fieldset the product they want to create. This would actually remove 1 step.

As for deleting use the same method as the menu settings, and add a checkbox which removes the product on submiting the node.

Also I was wondering if the settings should default to on as default, because this is how it currently works.

I like the idea of removing the product tab, too. You may recall, an early version of the patch did just that.

Yes, but you could not add different product types to a node.

'm not sure I understand what you're suggesting. You want to make every node create form a multi-page wizard where on the first page a product type is selected and on the second page the product details are filled in? Or are you saying each product type is a fieldset on a single-page form?

For a node which is not a product, in the fieldset display the list of available products types that can be added. If the user wants to create a product they select the product type and then get presented with form to add the product to the node.

If the node is not a product, also make sure that the product fieldset is collapsed.

Remember also that some users may have 'administer products' permission, but not permission to edit a particular node type. For those users, its good to have the product tab around as it allows them to edit product characteristics without access to the edit tab. Are you suggesting we no longer show the product tab to these users?

If the user doesn't have administer product access, then remove the fieldset from the product. But make sure the ptype is still on the form, so that if a revision is made it will move the product information from the previous revision to the current revision.

we can change a node(blog,page and so on ) to a product's node,and after that the node have changed but not a new node.
1,Now i want to the system will generat a new node(a product's node) when we change a node(blog,page and so on ) to a product's node,and the old node(blog,page and so on ) will not change.
how will we change the code?
2,somebody A can change the node(created by somebody B) to a product's node(by created a new node),and the node(created by somebody B) do not change .
how will we change the code?

when i put into ie use "http://www.******.org/admin/settings/content-types/product" , i get the bug "warning: array_merge() [function.array-merge]: Argument #2 is not an array in /www/winetcn/hotkeeorg/modules/product_transform.module on line 168.
".
why?

I've just tested this and it works.

I find it less intuitive than the old way with the tab - it makes more sense as a two step process. I suppose you get used to one way of doing things. If this is what people would like then I'm fine with it - I guess it must be faster to create products in with one page, and I'm all for that.

I really don't like the "Add To Store" button in addition to the "Submit button". That just seems weird (I assume they both do the same thing??) Setting, RTBC, but personally see possible UI improvements down the track.

.s

I've just tested this and it works.

I find it less intuitive than the old way with the tab - it makes more sense as a two step process. I suppose you get used to one way of doing things. If this is what people would like then I'm fine with it - I guess it must be faster to create products in with one page, and I'm all for that.

I really don't like the "Add To Store" button in addition to the "Submit button". That just seems weird (I assume they both do the same thing??) Setting, RTBC, but personally see possible UI improvements down the track.

.s

I have taken a quick look at this, and it seems that the form is not being contructed the same as it is on a product type node.

This has been one of my requirements that the form for a product type node, and a transformed node need to be exactly the same so that the user does not have any issues with inconsistancies and secondly so that programs that change the product form have not problem.

ATM your patch changes it to product_transform (or something) and not product, as it is in the normal product node.

This difference makes it harder to develop E-Commerce extensions because they need to include both methods instead of only 1 method as it should be.

If I am wrong, I am checking this on a public internet terminal in an airport, so it has been hard to check everything.

Ok, This is great so far, but there is 1 issue that needs to be fixed.

When turning a node into a product, When you use the "Add to Store" submit to refresh the page with the product fields, it should not display an error that the price is missing.

Effectively you are saying that the user has done something wrong, when they have not done anything wrong, except follow SOP.

Fix this issue, and I will commit it to CVS, ready to backport to 4.7

Gordon

I've done a patch implementing this approach in a more cleaner way. Also I've added some tricks to solve the price validation issue.

I should not be able to see the product fieldset once the node has been converted into a product, and I should not be able to change on the fly between product types. ie change the ptype from generic to donate.

Fixed the issue described above.

This is great, but I have 1 question before I commit this.

Why is the ptype file being changed from a value to a hidden in the product transformation.

Unless there is a good reason I would prefer a value like this not being sent to the browser where it could be altered.

The reason is that we need to pass the ptype so we can get this in nodeapi 'prepare'. The standard product form extracts the ptype from url with $type = arg(3); and the old patch also does this but with a custom field 'product_type'. This seems not to be a big problem, since the form is being validated and this feature can be used only by users with 'administer products' permission.

Commited to cvs and 4.7, Thanks this is great.