The key purpose of this module is to simplify the process of creating a product, by bringing the creation of a product and it's display together. The challenge is that a given node display can reference several products, this allows you to easily have one display for several variants of a product(s).

Add product

It shows the product creation form by default, this is the primary use case for this widget. The other use case, a referenced product is demoted in terms of importance. Using <hr> we "organize" the form into a part that is solely about the product. Then we display the different actions "Add another product" and "Reference a product" on the bottom of this part, with a gray background color (similar to Rules).

Add another product

Clicking add another product, the current product saves and you are shown a new product form. The previously entered product is now saved, and shown in a table on top. This all happens in a collapse/fade animation :'). Additionally the form transforms into a drag and drop form, which is connected to the table.

Add another product (multiple ones exists)

This shows the interaction when there are multiple products. The way that the "edit" link works, is that it opens up the form in the table. This is similar to how formatter settings work in the field ui.

Table of products

When you edit the product, and there are products and you did not click "Add another product".

Pattern already exists

We are not totally hacking core! :) The pattern partly exists for formatter settings in the Field UI


Stalski’s picture

Well the UI is great.

Extra case with more fields.
This is a very simple example and most products contain more fields. It is a tedious task to create ONE product display currently for a green/blue/red/yellow version and eacy of them having other sizes. The reason is that we might want to set buy 3 medium sized red t-shirts and 2 small sized red t-shirts.

I would like to suggest to pre-populate fields from existing products within that display.
I suggest there is a system that separates the product fields into "variant fields" and "fixed fields" or something like that. This way a blue t-shirt could be easily created/cloned from a green one by only having to change it's color. A medium size t-shirt can be "cloned" from the small version by only changing the size (leaving color by itself).

Also needed in this approach then, is a pattern for the sku and / or title of the product to ease that task.

Jason Ruyle’s picture

Has any of this been worked on?

j0rd’s picture

How does this actually work with Attributes. That's the important thing. Right now it's just Title, Status, Price + SKU.

I don't think it would be horrible to simply have products added as a tab on the product display node.

Then if we wanted to get fancy, we could move it into the normal edit mode.

At least it would simply things and get the ball rolling.

What ever method is chosen, we need to make sure for product display nodes, which will only have a single product, that no duplication of time is made to create this linear relationship. This is the most common and most used use case for most stores.

BenK’s picture


restyler’s picture


lukus’s picture

I don't understand why the user (site manager) needs to have any understanding of the differentiation between product displays and products.

From a UX point of view, I believe a user wants to add a product, and sometimes add variations of a product. I'm imagining that this is the mental model that most users will follow when going about the task of updating their inventory. From the point of view of designing a UI, I don't think the terminology needs to mirror the implementation.

If the site manager is going to use the product display entry form to build their products, does there need to be any differentiation between fields that exist on the product display node and the product entity?

Stalski’s picture

Totally agree on that actually. But that's the actual problem

bojanz’s picture

So I just had a good talk with lukus.

The main concern is that it will still be confusing to the client why he / she is adding products to a product.
A possible solution might be to bring the "product variation" term into Commerce. It's not currently anywhere in the UI, but I hear it mentioned all the time when talking about Commerce. It is a generic, ecommerce term and it should be widely understood.

So if you have a subform like in the mockups above, having the title be "Add product variation" instead of "Add product" could make it less confusing.

Bojhan’s picture

Agreed, lets do it

lukus’s picture

I'm going off on a slight tangent, but I've started trying to think about how products can be defined.

This is how ">Magento does it.


  1. Simple: e.g. Product A
  2. Grouped: e.g. Product A + Product B
  3. Configurable: e.g. Product A or Product B
  4. Virtual: basically a simple product without an actually shippable product.
  5. Bundle: eg. Product A + (Product B or Product C)
  6. Downloadable: basically a virtual product with a downloadable asset.

(I think that the 'virtual'/'downloadable types are perhaps the odd ones out here - and shouldn't necessarily be considered)

Magento calls these 'product types' - but in essence they are product combinations.

By introducing the concept of 'variations', we are putting a label to the combination Magento calls 'configurable'.

Perhaps, if we are going to eventually use this type of UI for creation of products we should think about ways of specifying similar product combinations?

adrianmak’s picture


Summit’s picture

Subscribing, greetings, Martijn

recidive’s picture

Additionally to the add product widget, it would be really useful having a setting to keep fields in sync, e.g. fields that don't change across multiple products, but need to be in the product, like weight and dimensions for shipping calculation. I thought yesterday about having a setting in the product widget to allow to choose fields in the product entity to be "shared" across products, and have those fields jump out of the add product form, i.e. having them look like a product node field, and it's value synced to all products within that product node

Other thing that's not explicitly being talked here is how the form should behave for single value product fields. I guess in this case, the better is to have the form look like a single form with all form fields integrated.

bmx269’s picture

Sub. UI is looking good, and will make a world of difference in adoption. THX

NaX’s picture

I really like what I see here, I played around a bit with the code and I think things are really close to being usable. Its really only the tricky entity form stuff holding things up.

I think its worth looking at how the Field Collection module is handling the form stuff. It does a lot of other stuff that is not relevant here but the one thing it seems to do is the embedding of the entity form. I had a look and it is bit above me but I do think looking at how Field Collection does its form handling could save a lot of frustration in the development of this module.

The part where my head started to hurt was how Field Collection handles the entity and the form_state before attaching the form fields. I really have not learnt enough about D7 to understand how this all interacts with the Ajax and widget form currently in commerce_ipf.

Another module that I think could also help is "Relation edit widget". It sounds like it is also doing some entity/node form embedding as a widget, but I don't know much about it so I can't say for sure.

Good luck, cant wait to see this module working.

muschpusch’s picture

Really, really interesting!!

mariomc’s picture


jeffschuler’s picture


I was struggling to figure out how to pitch to my client the duplicate work necessary in managing both products and product displays.

It took me a minute to wrap my head around [what here appears to be] changing the nomenclature from
Product & Product Display
Product Variation & Product
but the more I consider it, the better sense it makes as a model, to me.

minneapolisdan’s picture


bmx269’s picture

Are there any updates on this functionality?

wftl’s picture

Hello everyone,

Until the interface is ready, you might consider using the Product Display Manager, which does make the job a lot easier and a lot more bearable.


Marcel Gagné
Writer and Free Thinker at Large
Note: This massagee wos nat speel or gramer-checkered.

dhayles’s picture


chrisjlee’s picture

amaria’s picture

Wow, I was just about to look at what it would take to build this for a customer to be able to create product display and product in one step, when I saw this. I wanted to do an inline product form instead of automatically creating a product display node when creating a product entity. With this I'll have more than a starting point. Thanks!

recidive’s picture

@amaria: cool! Does this mean you're going to finish this work? ;)

amaria’s picture

@recidive Ha! Well first let me see if I can get this working for my customer. Right out of the gate, it doesn't work at all. I imagine it may have something to do with the changes from Drupal 7.9 to 7.10... or not. :) In any case, I'll see what I can do.

aleighs’s picture

Updated wireframes based on our work for "Commerce Kickstart v2". This UI is currently being implemented bojanz. They'll be plenty of opportunity for tweaks once we see the code in action.

View of product variations in a table:
Inline form - list view

User clicks to edit an existing variation and form appears inline:
Inline form - edit view

Empty state:
Inline form - empty state

Bojhan’s picture

Awesome! Do you want to have the .PSD I always use for Seven detailed designs? I would love to give this a review, since I have seen people use the Field UI in-row settings in our last round of usability testing.

1) The wireframe as proposed only accounted for a few fields. The more complex design in #28 shows that the pattern doesn't really scale well, it starts to suffer from "fieldsetritus" where there is so much nesting that people lose orientation. Should we consider using a modal dialog for this? From testing we saw overlay + modal dialog creates few to no usability issues.

2) Why is the empty state emphasis on "no variation yet"? Shouldn't it be a normal screen, or do we expect the workflow to be "add many variations" from the first go?

3) We found in usability testing of contribs like Views, Media that having more than one save button on the page is confusing. By putting it in a modal, you remove this problem. If you can't, try different wording, such as "Update".

4) We found that in general the pattern "Save and add another" doesn't work that well. It confuses beginners, which save to click and for more advanced users they like to see the object they created (not just a confirmation message). It's not a big issue but definitely one that can have an impact on beginners..

5) When there are more attributes, how does that scale in the table?

Feel free to bump me on IRC or per email if you need me to check more feedback/ideas around Commerce Kickstart v2.

aleighs’s picture

Thanks for PSD offer, I've created an omnigraffle stencil kit, which is what I usually use, but I'd love to have the psd and can share the graffle stencil with you as well if you'd like.

This feedback is great and some of this has already been adjusted in development. Should have mentioned these are already a bit outdated.

1) You're right, the only fieldset that should be able to be displayed inline is the attributes. In reality the details fieldset will need to be displayed as one field per row. As far as modal instead, this was discussed at length before we began. It's being implemented this way for now with the collective knowledge that this will need to be user tested and may need to be changed to a modal. So duly noted.

2) This empty text approach may be a bit over-engineered, but we're hoping that this gives a grouping and context to the add form within a form. Again, let's test it and see how it performs.

3) Definitely can change the "save" label to "update" if we already know that performs better in testing.

4) Happy to get rid of "save and add another", agreed that it has little value add and confuses users.

5) We plan on having the table be configurable so the admin user can choose which fields to display here, either by (a) using a view mode to display this or (b) creating a simple custom config page in the module that allows you to choose which fields to display.

Will definitely check-in with you on our plans for Kickstart v2, probably week of April 2.

Bojhan’s picture

@aleighs Sure, can you send me over your e-mail address?

1, 2) Sounds like a good strategy, although its probably difficult to find good data points for in research that would signal for modal dialogs. A research method, that I tend to use for discovering orientation is a 5 second test; if people can quickly spot what a part of the form is about.

botris’s picture

Off topic @Bojhan & @aleighs, would it be possible to create some sort of online repository where multiple Drupal UI kits can be stored? I use Fireworks for mock ups, and be happy to create one based on your files.

bojanz’s picture

Version: » 7.x-1.x-dev
Category: feature » task
107.83 KB
120.52 KB
89.31 KB

Here's how the current committed version looks like.

1) Doesn't have the Price & Status settings / columns in the table. We went back & forth on including those and I'm not sure what the final decision was.
Once the team reminds me, I'll implement the missing pieces. What do you guys think?
2) Doesn't have and won't have the "Save and add another" button, we agreed to kill that one.
2) The row being edited is always white, even if it was stripped (had a different background color). I've added a border between the row being edited and the neighboring rows, not sure if that's enough.
3) The logic for determining which table columns to show is this: if the product has up to three attribute fields, show them. If there are more than three attribute fields, show the title instead. This is not configurable from the UI currently. Please direct your thoughts on that to #1521274: Investigate a UI for configuring table columns (which fields and in what order).

Keep in mind that I'm no CSS wizard, and that the styling will be polished further.

rei’s picture

- please include image thumbnail column in the table, and I think price should also include in the table
- change word 'variation image' to just 'image' on the fieldgroup title (consistent with 'attributes' and 'details')

Summit’s picture

Hi, I am a little bit confused, but ask anyway :)
Are the variations attributes shown here a drupal commerce functionality or can these be term-fields?
I use term-fields for color and size, and would love to have them shown as displayed in these screens.
If this is not the issue to ask clearifying for this, sorry, then please advise where to put this.
Looking great those screens by the way!
Greetings, Martijn

bojanz’s picture

93.74 KB
93.51 KB
43.24 KB


- please include image thumbnail column in the table, and I think price should also include in the table

I agree. Forgot about the thumbnail, that needs to be added.

- change word 'variation image' to just 'image' on the fieldgroup title (consistent with 'attributes' and 'details')

No, the word variation needs to stay to distinguish the image from node-level images.

An attribute is a term reference or a list field that has cardinality 1 and is enabled as an attribute in field settings.

Made a new commit after today's feedback from my team. Here are the new screenshots.
1) Disabled the sticky headers that were just buggy.
2) No longer showing tabledrag while editing is in progress (which enables #3)
3) Shows the edit / delete from below the row, instead of replacing it.
In general, the look and feel is greatly improved in my opinion.

My next step is adding the missing columns.

bojanz’s picture

I've added the image and price fields to the colums.
As far as I'm concerned, this issue can now be closed, and focus switched to followup issues.
Giving you 48h to test and provide feedback, then closing it.

botris’s picture

Have no new remarks, design looks great. Workflow is very intuitive.

liupascal’s picture

In #36, 1.png, we can see "drag n drop" arrows on each line, which implicitly means that there is a weight system somewhere ? I'm not sure I've seen any "weight system" in the product reference field which could allow a user to select which product will be displayed first..

Maybe i'm completely wrong though.

bojanz’s picture

Yes, you can reorder them, and that affects display. The weight just changes the order of the ids in the field.

bojanz’s picture

Status: Active » Fixed

Added line item support, fixed a few more bugs. Closing this issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.