YITH Frequently Bought Together 1.60.0 – for WooCommerce

YITH Frequently Bought Together does one narrow job, and that’s why I like it: it builds an Amazon-style “buy these together” block on WooCommerce product pages without forcing a full bundle system onto the store.

I use it when the store needs controlled cross-sells, not vague related products. A merchant wants this phone + this charger + this case, with one add-to-cart action and optional bundle discount. That’s the sweet spot. If the catalog needs complex kits, inventory sync across components, or dynamic bundle rules, this is too light. For direct upsells, it’s efficient.

How it works in the store

The logic is mostly admin-side and stored in WordPress/WooCommerce data, not hardcoded per product page.

You configure the global behavior in the YITH plugin panel, then assign linked products on the product edit screen. The plugin stores:

• plugin-wide settings in wp_options;
• per-product “frequently bought together” selections in post meta;
• discount/display choices depending on the plugin version and setup.

On the frontend, it injects the box into the single product template using WooCommerce hooks. The rendering is plugin-driven, but the display point is usually adjustable from the plugin settings. That part is easy. The harder part is changing the actual markup logic or quantity behavior — that lives in the plugin templates/PHP.

What’s editable without code:

• block position;
• linked products;
• text labels;
• discount/presentation options;
• button behavior in normal use.

What’s not really “click-editable”:

• template structure beyond plugin options;
• custom pricing logic;
• unusual variation handling;
• deeper AJAX/cart behavior.

If I need markup changes, I check whether that plugin version supports template overrides in the theme. If yes, I override there. I do not edit the YITH Frequently Bought Together files directly.

Where it usually breaks

The first break is variable products. Not the plugin itself — the chain around it.

If one of the linked products is variable and the required variation isn’t resolved correctly, the bundle add-to-cart flow becomes inconsistent. Typical symptom: the main product adds fine, one linked item fails silently, or WooCommerce throws a variation error.

My first check is DevTools → Network and Console. I look for failed requests and Woo scripts not loading. The usual suspects are:

• wc-add-to-cart-variation
• wc-cart-fragments
• jquery
• jquery-core

Aggressive JS delay/minify breaks this faster than people expect. The fastest fix is to exclude those handles in your performance plugin, then retest on a variable product page.

The second break is fragment/cart refresh trouble. You click the combined add-to-cart button, products are added, but mini-cart counts or notices don’t refresh correctly. That is usually a cart fragments or theme-AJAX conflict, not a pricing bug.

Fast workaround:

• temporarily disable JS delay/defer in WP Rocket / LiteSpeed Cache / Autoptimize;
• retest the single product page;
• if fixed, exclude WooCommerce cart/variation scripts and the YITH frontend script bundle from optimization.

Caching can also produce stale prices or old linked-product output after editing the setup. When that happens, I purge page cache, plugin cache, and CDN cache, then hard refresh the product page. On Woo sites, stale fragment behavior often looks like a plugin bug when it’s really cached markup plus delayed JS.

Activation, updates, and what you actually lose without a key

In the build I tested, the plugin was activated and fully working, with no feature restrictions in daily use.

Plain version of the licensing reality: YITH premium plugins generally run without a license key once installed, but without activation you usually lose:

• automatic updates;
• official support;
• access to vendor update flow and account services.

Manual updates are simple:

• Plugins → Add New → Upload Plugin, then upload the new ZIP, or
• replace the plugin folder via FTP/SFTP.

If you overrode templates in the theme, recheck them after every update. If you edited plugin files directly, those edits will be overwritten. I never use that route.

FAQs (the stuff people actually trip over)