My first question is about the forum. Do the developers ever log on and read problems? It seems like the only way to get help with problems with this product is to buy the support.
We have not kept the forum up to date. We are changing that with new efforts around Stack Overflow and other avenues for community support.
Has anyone came up with a work around for the stupid implementation of Product Options on the product page and the search facets? Currently in Broadleaf, when you navigate to a product page it shows all the option values from the table on the product. Event the options do not correspond to that specific product. I am building a store for my self and one of my shirts only comes in one color but when I navigate to the product page it shows options for every color in the DB. The same thing happens with the search facets. On the left hand side, if I click Blue as a search criteria it shows all my shirts not just the ones that are actually sold in blue. This seems like a big feature to mess up on.
The best way to implement this on the product details page is to look for the active associations between ProductOptionValues and Skus. In the admin, if you create a product option a``nd then assign values to it, then associate that to a product, you can go to the 'Options' tab and 'Generate Skus'. This will generate Skus for all of the option value permutations.
For example, if you have shirts with a Product Option of Color (Blue, Yellow, Green) and Sizes (S M L) then this will generate 9 Skus (Blue S, Blue M, Blue L, Yellow S, Yellow M, etc). You can then delete the generated Skus that you don't actually want.
On the left hand side, if I click Blue as a search criteria it shows all my shirts not just the ones that are actually sold in blue. This seems like a big feature to mess up on.
The reason this does not work now is because we do not index the individual Skus along with the product, just the product itself. One way to resolve this would be to create a new field for the product and associate values for what Skus are actually contained within it, or create a service method that you add these facetable values to each document. The best extension point for this is to create a SolrIndexServiceExtensionHandler bean and override the addPropertyValues() method that will work in conjunction with the facet that you would create in the DB.
I have already submitted a issue about this on GitHub but it doesn't look like the developers are active on GitHub that often or on these forums either. My store does not make enough to justify not using the community edition.
Also something that we are fixing, I am going through and triaging issues there over the next week or so. You can expect a lot more involvement and engagement over the next few weeks, getting back to where we were.
The Broadleaf forums are being retired as a readonly archive of questions. For active discussions and questions, check out the broadleaf-commerce tag on Stack Overflow
which is actively monitored by the Broadleaf team.