▶️ New Video: Advanced Product Variations in FluentCart
WPTuts ( Paul C ) just dropped a great walkthrough on one of our favorite recent additions: Advanced Variations, now available in the completely free version of FluentCart. No paywall, no add-on maze.
If you sell products that come in multiple combinations (think colors and sizes and materials), this one's for you. Paul takes you through the whole process:
- Converting a simple product into advanced variations
- Combining multiple options (colors × sizes) to auto-generate every variant
- Adding per-variation pricing, compare-at prices, images, and SKU codes (with auto-generate)
- Managing stock and inventory per variant
- Direct checkout links for individual variations
- A look at the front-end experience, with real-time price updates as customers pick their options
Big thanks to Paul for the thorough review and the thoughtful feedback. A few of his suggestions around editable fields in the inventory view are already on our radar. 👍
Got products with lots of variations? Give it a try and let us know how it goes in the comments!
Shahjahan Jewel does the official MCP support these tools/calls already? if not are there API endpoints?
A suggestion for the next demos, please include use cases with digital products, such as software, communities, etc. thanks and congrats.
It's working very nice on my side, only one trigger was missed once but I have no way to track the reason why it happened, I will make an automation to avoid this possibility in the future with a double check.
Right now I have my agent working with all the MCPs I created, and they create my automation workflows, design all my carts, boards,
and all the settings. It's pretty amazing having the agents connected to the MCPs and being able to delegate 90-95% of the task.
Carlos Rodera the official MCP does not support the create / update products yet. We will add that capability in the next version.
Shahjahan Jewel thanks, looking forward to
Nice review from WPTuts, one of the best WP channels i know !
Nicolas D I am a big fan of the channel.
Shahjahan Jewel I’m also a big fan, and Paul is a true WordPress professional. It’s not like all those WordPress channels run by YouTubers who post fake reviews of every plugin and theme out there just to earn affiliate commissions.
These attributes only work for variation products, right?`Woocommerce also used attributes to display information about the products (even simple ones) like dimensions, materials etc. Are you planning to enable something like this as well? These can also be thought as custom fields I guess.
Madis Mark yes, these attributes are for variations. We have other plan for product spec that you want to show on the product page.
Shahjahan Jewel Awesome! Most of the features soon seem to be done then :) I guess only multilingual feature remains (or perhaps integration with already existing multilingual plugin takes care of it). Oh and customer reviews also.
Madis Mark Shahjahan Jewel About this, here is our request to fluentcart support 4 weeks ago while we were actively testing the "advanced variations" beta :
Hi,
Following up on the catalog filtering work for the new global attributes system — glad to hear it's coming. While testing it, we ran into a structural gap I think is worth flagging now, while the filter design is still open.
The current `advanced_variation` model only attaches attribute relations at the variation level. There's no equivalent to WooCommerce's distinction between an attribute "used for variations" and an attribute simply assigned to the product as a fixed characteristic.
The use case is very common in physical-product stores: an attribute that is constant across every variation. For example, a product has 10 variations (Size × Color), but it is made of Paper — and that's true for all 10 variations. The customer doesn't choose the material; it's a fixed property used only for filtering and description. Same for things like origin, gender, internal brand, etc.
Right now the only way to model this is to add Material as a single-term group in the variation set. It works (a one-term group multiplies the cartesian by 1, so it doesn't create extra variations, and the term still attaches to each variation via attr_map), but it has downsides: the data is stored redundantly on every variation, and it shows up in the variation editor as if it were a selectable option, which it isn't (and also in sidecart, checkout..).
The clean solution would be a product-level attribute relation — an attribute attached to the product (ProductDetail) rather than to its variations — distinct from the variation-level one. This is exactly WooCommerce's "assigned to product / not used for variations" behavior.
My ask: when you design how the frontend catalog filters read the attribute relations, could you make them read product-level relations in addition to variation-level ones? If the filter is built to query both levels now, adding the product-level attribute concept later won't require reworking the filter logic. It seems much cheaper to account for it at design time than to retrofit it.
Happy to share more detail or test builds whenever useful. Thanks as always for the responsiveness.
Best,
Nicolas
and their answer :
Hi Nicolas,
Thank you for sharing such a detailed and thoughtful breakdown. The distinction you described between variation-level attributes and product-level fixed attributes makes sense, especially for cases like material, origin, gender, or internal brand that should be available for filtering without becoming selectable variation options.
We’ve forwarded your full feedback and use case to our team for review while the catalog filtering and global attributes work is still being planned. This should help them evaluate how the filter logic should handle both variation-level and future product-level attribute relations.
If the team has any updates, feedback, or follow-up questions, we’ll get back to you in this ticket. We really appreciate you taking the time to explain the current workaround, its limitations, and why it would be better to account for this in the filter design now.
Thank you
Just watched Paul C's amazing walkthrough. My one grey area is the prospect of making SKU editable; I think this needs to be thought through from an audit SSoT perspective rather than just design convenience. As an audit data analytics sme/trainer, I would recommend that if you were to take the Paul C route of opening up the SKU field, it will make sense to capture changes somewhere in the UI dedicated to tracking changes in that field and/or others in the inventory management section for traceability purposes. If it were my call, I wouldn't open the SKU for alterations for any reason to streamline design and analytics workflows; rather, I'd offer to have the product entry deleted and re-entered. With the above said, it would be helpful for me and others to understand the use cases around Paul C's recommendation for SKU editability that section. Just a second thought. It will be interesting to read what other users in this space think.
Great addition! I do have a bit of feedback:
Lots of clients that I work with have a massive amount of product variations or combinations, and I've got asked multiple times about editing prices in the different way: Rather than assigning a price to every possible combination (Which means the price must be edited hundreds of times), they wished to edit the Attribute price itself. For example:
IF one of my client sells Fans, one attribute is diameter:
- 8 FT +500$
- 10 FT +600$
- 12 FT +$700
And another attribute that is down tube length:
- 2 ft +$200
- 5 ft $300
And so on and so on for like 8 attribute groups.
This would make the experience much easier for the client to manage. Not sure if this is something that could be added in the future. It would be game changer for some of my clients.
Sebastian c I think that feature is called product customized in Shopify or Woo world.
Shahjahan Jewel Yes something along those lines. It's possible to do on Woo, it's the route that we've been going for lately, but obviusly FluentCart is a much more attractive option, not sure if this would be possible at this point in time. If not, this is a big one for me :)
Thanks for the reply.
Sebastian c I am currently working on a product options plugin, fully integrated into the Fluentcart menus with the same styling, as if it were native to the core.
*Screenshot was taken in the early stages of development.
Sander W. Hey thanks, that's great! I only look for the logic and backend work though, I have no problem if it doesn't have widgets or styling since I do all the frontend from scratch using Etch. If the data is accesible via query loops I can definitely test it.
Can you assign product categories to variations? For example, suppose you want to filter on all the XL sized shoes and show only those?
One idea. Not sure if it has been mentioned already.
To pick color swatches, we are forced to use advanced variations right now, but we can use images for simple variations. Why not colors too? Sometimes maybe only a few color variations and no need to use advanced? What do you guys think?
Out of curiosity, how does one gain access to beta testing upcoming features?