Currently I can't see any way to easily change the price if, for instance, you had 200 almost identical products. BPC makes it very easy to add products in bulk but gives no way of also editing them.

CommentFileSizeAuthor
#9 bulk_update_products.txt8.06 KBjessepinho
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

sven.lauer’s picture

It is true that this is not possible at present.

I agree completely that this is much-needed functionality, but for now, it is beyond the scope of commerce_bpc. I have been toying around with various ideas how this could be made to happen. One of the main obstacles right now is that bpc does not keep track in any way which products have been created together. A future version will likely do this, and then something like editing "static values" for all products in a group should be easy (though care has to be taken: What should happen if one of the products has been changed since creation? Should the new value override the changed value? This just to illustrate that this is not just implementation work, but also a good deal of design choices). I've been meaning to start an issue for discussing this functionality, and how it could be implemented, but for now, this is "music of the future", as they say in the language of my ancestors ;)

Granted, one could also conceive of a general "Bulk update" functionality that just allows to select a number of products (as in VBO) and then presents a list of fields to change. While useful, I think this would go in the wrong direction for bpc. What one wants, really, is "Bulk product management", or, as I have been starting to think of it "Product Group UI".

Which is to say: I feel your pain, but my resources are too limited to make this happen quickly.

msmithcti’s picture

Thanks for your speedy reply, there's some great ideas there and I look forward to having this functionality but I do understand the lack of resources.

Some thoughts I had on the question of what do to with single products that have been altered - could there be a 'confirmation' type screen that says: These are the products that have been altered on their own... and then two options - apply the changes to these products or don't.

I think for now however, the solution may have to be quick and dirty - some combination of VBO and rules.

sven.lauer’s picture

Some thoughts I had on the question of what do to with single products that have been altered - could there be a 'confirmation' type screen that says: These are the products that have been altered on their own... and then two options - apply the changes to these products or don't.

I guess functionality-wise, something like this is probably the best. But note that for this to work, we not only need to keep track of which products were created together, but also which are the "default" values (and/or mark every value for being the default or overriden). So this is far from trivial to implement.

commercebythegraceofgod’s picture

Thanks for your response on this. I understand that this is not a trivial task. At this point, you may consider contributing to VBO where bulk update is concerned...some of the legwork has been done, but it is not perfect.

BPC seems to do what it was intended to do: Create new products during the development of a new site.

VBO should be able to handle the management once these are created.

I love the Drupal community so much. It just seems that functionality is being duplicated between products. For the future usability of Commerce as a whole, it seems that BPC and related modules with regard to product management should be moved into the core of the Commerce project, for the sanity of all involved.

sven.lauer’s picture

VBO should be able to handle the management once these are created.

I love the Drupal community so much. It just seems that functionality is being duplicated between products.

I don't think this really applies in this case---there is little duplication, either in terms of code/logic or in terms of intended functionality between the projects (there is some possible duplication between bpc and Product Display Manager, but this project has been dormant for a long time and only just has begun to be developed again).

What VBO does is quite different from what a proper product group management module would do. If and when this gets implemented in / as an offshot of BPC, group management would mean that you can create products in bulk and then edit / manage / delete products that were created together, as if they were "one product" with different variations. VBO, on the other hand, is for generic bulk operations. Of course, in particular with respect to deletion, VBO can be used as a workaround, but it really has a different focus. So these things are rather different.

Believe me, I am keeping an eye out to make sure that if there are ways to coordinate to save work, these are not ignored, esp. since my time to work on BPC is limited.

For the future usability of Commerce as a whole, it seems that BPC and related modules with regard to product management should be moved into the core of the Commerce project, for the sanity of all involved.

This is unlikely to happen. I think I recall Ryan saying at some point that they have built a considerable number of commerce sites that did not require bpc-like functionality. And I can see that: BPC-like functionality is really needed with traditional, physical products, but may be unnecessary for other sites. And there is something to be said for keeping commerce core "lean and mean". Right now, there are no obvious problems with the development of BPC as a contrib module---i.e., there are no technical reasons to move it into commerce core (the APIs provided by commerce core are well-designed enough).

Now, of course, you may say, "if it were in core, there would be more developers working on it", but I think that is probably mistaken. If BPC-like functionality were in commerce core, but the core guys don't need the functionality, it is unlikely that they would work on it (which actually might mean a slow-down of development). Conversely, if commerce guys or anyone with the time and/or $$ to contribute would want to see bpc developed more quickly, that could just as well happen in a contrib module.

Which is to say: Duplicated effort / lack of coordination always is a potential problem, but I don't think it is the problem here.

(There is something to be said, though, that there likely is a considerable number of people who would/might use commerce (and thus in time, possibly contribute back) if there was better support for "product variations" (which really is what bpc is about). But in the end, this is speculation.)

bojanz’s picture

VBO 7.x-3.0-rc1 can bulk edit entity values, including commerce products (as well as orders or anything else that crosses your mind).
Feel free to open feature requests in the VBO queue for extending that functionality.

You can bulk change the price, but it must be a new amount that is applied to all products, you can't just say "increase all prices by 10% or 20$, etc", for that you need a rules component run by VBO.

And yes, I've yet to work on a project that required BPC (though I do find it nice).

sven.lauer’s picture

Thanks for the info, @bojanz. Now that VBO has support for bulk-updating entity values / fields, using BPC with VBO is a good interim solution for "product group" management. If I find the time, I will add a note about that to the documentation pages.

that0n3guy’s picture

I'm not sure I see how VBO can help me bulk reference some products from a product display... That seems to be a big thing that we need.

jessepinho’s picture

FileSize
8.06 KB

If this helps, here's a VBO view I created that allows you to bulk update any fields on any product types. (VBO even lets you use tokens—so cool!)

marktheshark’s picture

bojanz, what is your approach for mass product creation if you don't use BPC?

Thanks

mrackham’s picture

That VBO view in #9 jessepinho has just come very much in handy

Thanks

bohemier’s picture

Thanks to #9 jessepinho for that really nice view. Extremely useful...

pun_pun’s picture

Issue summary: View changes

Jessepinho, thank you for your solution #9!
Just want to note, that you should set access for this view. By default it's set to "none" (for everyone).