Bug Report: Excessive Transient Creation and Ineffective Caching in B2BKing

Hello B2BKing Support Team,

I am reaching out to report a technical issue identified while running B2BKing in combination with WooCommerce 9.3.4. The problem results in excessive transient creation in the wp_options table and leads to significant database growth and performance degradation.

After analyzing both the plugin code and production logs, I have identified several underlying issues.

First, the price filter (woocommerce_get_price_html) is applied globally whenever the “show B2C price” setting is enabled. This can be seen in:

b2bking/public/class-b2bking-public.php
b2bking/includes/class-b2bking.php

Code:

if (intval(get_option('b2bking_show_b2c_price_setting', 0)) === 1){    add_filter('woocommerce_get_price_html', array($this, 'b2bking_show_both_prices'), 99995, 2);
}

This means the function b2bking_show_both_prices() runs on all price renders (archives, single products, related products, widgets), not only for B2B users.

Second, transient keys are generated using get_current_user_id():

get_current_user_id()

Resulting in keys such as:

b2bking_display_price_both{product_id}_0

For guest users (user ID = 0). This causes transients to be created for anonymous visitors, which represents the majority of traffic.

Third, transients are written even when the current user is not a B2B user. The logic includes:

$is_b2b_user = get_user_meta(get_current_user_id(),'b2bking_b2buser', true);
if ($is_b2b_user === 'yes'){    // B2B logic
}
// Later in the function:
set_transient('b2bking_display_price_both'.$product_id.'_'.get_current_user_id(), $price);

The set_transient() call executes regardless of whether the user is B2B, meaning guests and B2C users also trigger writes.

Fourth, and most critically, the caching logic is effectively disabled by default:

if (    !get_transient('b2bking_display_price_both'.$product_id.'_'.get_current_user_id())     || apply_filters('b2bking_display_both_cache_disable', true)
)

Because the filter default is true, this condition always evaluates to true. As a result:

• the cache is never reused
• the price is recalculated on every request
• set_transient() is executed on every price render

This defeats the purpose of caching entirely.

Fifth, due to this behavior, every call to:

woocommerce_get_price_html

results in a database write. On archive pages displaying multiple products, this leads to dozens of writes per request. Under crawler or bot traffic, this scales significantly.

Additionally, the plugin maintains a global transient that is updated on shutdown:

b2bking/includes/class-b2bking-global-helper.php
b2bking/includes/class-b2bking.php

Code:

add_action('shutdown', function(){    b2bking()->set_global_data_update();
});

And:

set_transient('b2bking_global_data', $b2bking_data, 30 * DAY_IN_SECONDS);

This can result in repeated writes of large serialized datasets, even when no meaningful changes have occurred.

In production, this behavior has resulted in:

• tens of thousands of _transient_* rows
• a wp_options table exceeding several hundred megabytes
• continuous INSERT and UPDATE operations
• performance degradation under load

From an expected behavior standpoint:

• the price filter should only execute for relevant B2B users
• transients should not be created for guest or B2C users
• caching should be enabled by default and reused properly
• global transients should only be updated when underlying data changes

Based on this analysis, I recommend the following improvements:

• Restrict execution of the price filter:

if (!is_user_logged_in() || get_user_meta(get_current_user_id(),'b2bking_b2buser', true) !== 'yes') {    return $price;
}

• Prevent transient creation for guests:

if (get_current_user_id() === 0) {    return $price;
}

• Fix cache logic default:

apply_filters('b2bking_display_both_cache_disable', false)

• Only call set_transient() when necessary (B2B users and when value changes)
• Avoid unnecessary global transient updates by checking if data actually changed before writing

The current implementation effectively causes unbounded transient creation due to global execution combined with ineffective caching logic. This leads to database bloat and performance issues, especially on larger WooCommerce installations.

Kind regards, Timothy

Hello B2BKing Support Team,

I am reaching out to report a technical issue identified while running B2BKing in combination with WooCommerce 9.3.4. The problem results in excessive transient creation in the wp_options table and leads to significant database growth and performance degradation.

After analyzing both the plugin code and production logs, I have identified several underlying issues.

First, the price filter (woocommerce_get_price_html) is applied globally whenever the “show B2C price” setting is enabled. This can be seen in:

b2bking/public/class-b2bking-public.php
b2bking/includes/class-b2bking.php

Code:

if (intval(get_option('b2bking_show_b2c_price_setting', 0)) === 1){    add_filter('woocommerce_get_price_html', array($this, 'b2bking_show_both_prices'), 99995, 2);
}

This means the function b2bking_show_both_prices() runs on all price renders (archives, single products, related products, widgets), not only for B2B users.

Second, transient keys are generated using get_current_user_id():

get_current_user_id()

Resulting in keys such as:

b2bking_display_price_both{product_id}_0

For guest users (user ID = 0). This causes transients to be created for anonymous visitors, which represents the majority of traffic.

Third, transients are written even when the current user is not a B2B user. The logic includes:

$is_b2b_user = get_user_meta(get_current_user_id(),'b2bking_b2buser', true);
if ($is_b2b_user === 'yes'){    // B2B logic
}
// Later in the function:
set_transient('b2bking_display_price_both'.$product_id.'_'.get_current_user_id(), $price);

The set_transient() call executes regardless of whether the user is B2B, meaning guests and B2C users also trigger writes.

Fourth, and most critically, the caching logic is effectively disabled by default:

if (    !get_transient('b2bking_display_price_both'.$product_id.'_'.get_current_user_id())     || apply_filters('b2bking_display_both_cache_disable', true)
)

Because the filter default is true, this condition always evaluates to true. As a result:

    the cache is never reused
    the price is recalculated on every request
    set_transient() is executed on every price render

This defeats the purpose of caching entirely.

Fifth, due to this behavior, every call to:

woocommerce_get_price_html

results in a database write. On archive pages displaying multiple products, this leads to dozens of writes per request. Under crawler or bot traffic, this scales significantly.

Additionally, the plugin maintains a global transient that is updated on shutdown:

b2bking/includes/class-b2bking-global-helper.php
b2bking/includes/class-b2bking.php

Code:

add_action('shutdown', function(){    b2bking()->set_global_data_update();
});

And:

set_transient('b2bking_global_data', $b2bking_data, 30 * DAY_IN_SECONDS);

This can result in repeated writes of large serialized datasets, even when no meaningful changes have occurred.

In production, this behavior has resulted in:

    tens of thousands of _transient_* rows
    a wp_options table exceeding several hundred megabytes
    continuous INSERT and UPDATE operations
    performance degradation under load

From an expected behavior standpoint:

    the price filter should only execute for relevant B2B users
    transients should not be created for guest or B2C users
    caching should be enabled by default and reused properly
    global transients should only be updated when underlying data changes

Based on this analysis, I recommend the following improvements:

    Restrict execution of the price filter:

if (!is_user_logged_in() || get_user_meta(get_current_user_id(),'b2bking_b2buser', true) !== 'yes') {    return $price;
}

    Prevent transient creation for guests:

if (get_current_user_id() === 0) {    return $price;
}

    Fix cache logic default:

apply_filters('b2bking_display_both_cache_disable', false)

    Only call set_transient() when necessary (B2B users and when value changes)
    Avoid unnecessary global transient updates by checking if data actually changed before writing

The current implementation effectively causes unbounded transient creation due to global execution combined with ineffective caching logic. This leads to database bloat and performance issues, especially on larger WooCommerce installations.

Kind regards, Timothy

Hi Stefan,

Thank you for the update and the detailed explanation — much appreciated.

I’m going to test the updated B2BKing Pro build on our staging/production environment and monitor the impact on transient usage and overall database behavior.

From a first analysis, the changes around the display price logic and reduction of unnecessary transient writes look like a solid improvement, especially for guests and non-B2B users.

However, during our debugging we identified two additional areas that are still relevant in our setup, and I would like to get your feedback on these:

1. Global data transient (b2bking_global_data)

You mentioned that this only updates when $b2bking_data_is_dirty === true, which is intended to improve performance.

In our case, we observed that:

• set_global_data() is triggered quite frequently
• this sets the “dirty” flag to true relatively easily
• which results in repeated writes to the b2bking_global_data transient

On high-traffic WooCommerce setups (especially with many product/archive requests), this can still lead to:

• frequent writes to wp_options
• unnecessary database load
• increased I/O under load

Our concern is that this behaves more like a “write-on-access” pattern rather than a strict “write-only-on-change” (i.e. comparing with previous data before persisting).

Question: Is there any plan (or recommended approach) to make this mechanism more strict, e.g. only persisting when the actual data has changed compared to the previous stored value?

2. Runtime flush_rewrite_rules()

We also noticed that B2BKing still hooks into runtime requests and may trigger rewrite flushing (via the b2bking_flush_permalinks logic).

In production environments, this is quite problematic because:

• flush_rewrite_rules() is an expensive operation
• it writes to the database (rewrite_rules option)
• if triggered during normal frontend requests, it can significantly impact performance
• under load, this can become a bottleneck or even cause spikes in database usage

To prevent this, we currently disable it via:

add_filter( 'b2bking_flush_permalinks', '__return_false', 999 );

Question: Is there a reason this still runs during normal requests, and would it be possible to limit this behavior to:

• plugin activation
• settings updates
• or explicit admin-triggered events only?

Overall, the new build is definitely a step in the right direction, and we’re happy to continue testing and providing feedback.

Thanks again for your work on this.

Kind regards, 

Timothy

Hi Stefan,

Thank you for your detailed explanation and for providing the updated version — much appreciated.

Your reasoning regarding the b2bking_global_data approach and the permalink flushing makes sense from a broader plugin perspective, especially considering the need to support a wide range of store configurations at scale. I understand the trade-offs involved.

On our side, we are working with a relatively large WooCommerce setup where we’ve been experiencing intermittent database growth and write spikes, particularly in the wp_options table. Because of that, we’ve taken a more diagnostic and controlled approach:

• We are actively logging and tracing option writes (including backtraces and request context) to identify the exact source of sudden spikes.
• We aim to minimize unnecessary write operations during normal frontend requests, especially those triggered by non-authenticated traffic (bots, crawlers, etc.).
• Stability and predictability of database behavior is critical in our case, as we’ve observed situations where the database grows significantly within a short time window.

That is the main reason we are selectively disabling or adjusting certain default behaviors (such as permalink flushing and cache-related actions), while monitoring the effects closely in production.

We will proceed with testing the updated version you provided and evaluate how it impacts the write patterns and overall database stability.

Thanks again for your support and transparency — it’s very helpful in diagnosing these kinds of issues.

Kind regards, 

Timothy

Hi Stefan,

Thank you again for your earlier explanations and the updated builds you provided. The previous changes around the b2bking_display_price_both transients have helped: in our latest logs we no longer see the earlier guest/user ID 0 transient buildup, and the major wp_options explosions appear to have stopped.

We have continued monitoring the site with detailed option-write logging, including request context and backtraces. The remaining B2BKing-related issue we still see is around:

_transient_b2bking_global_data
_transient_timeout_b2bking_global_data

In the logs, these are still among the largest remaining wp_options write sources. The traces point to:

B2bking_Globalhelper::set_global_data_update()
→ set_transient( 'b2bking_global_data', ... )

From what we can see, the global data is marked as dirty during runtime and then saved again on shutdown. In practice, this still results in repeated writes of the full b2bking_global_data transient on normal public requests, including guest/bot/product/category traffic.

The transient is often several hundred KB, sometimes close to or above 1 MB. Even if this is not causing the same database explosion as before, it still creates significant wp_options write churn and I/O pressure on larger stores.

The specific question is whether the current dirty-check could be made stricter. For example:

Only mark the global data as dirty if the new value is actually different from the existing value.
Only call set_transient() if the serialized/hash value has changed.
Avoid refreshing the timeout when the stored data has not changed.

We understand your previous explanation that one global transient can be faster than many individual transient writes. That makes sense. The issue we are seeing now is not the use of a global transient itself, but that it still appears to be rewritten very frequently during public runtime requests.

Could you please review whether set_global_data() / set_global_data_update() can be optimized further to avoid rewriting b2bking_global_data when the actual data has not changed?

Kind regards, 

Timothy

Hi Stefan,

Thank you for the quick and clear explanation.

Yes, I understand your point that the global data can legitimately change often depending on the user, products, category pages and applicable rules. I also understand that doing a deep comparison of a large dataset may not necessarily be cheaper than writing it.

In that case, I think your proposed approach is worth testing.

Splitting the current b2bking_global_data transient into smaller individual transients would likely reduce the impact we are seeing in the logs, because the current issue is mainly that one large transient, often several hundred KB up to around 1 MB, is rewritten repeatedly.

If you can prepare a build with a filter to enable this behavior, we would be happy to test it.

A few points that would be important for our setup:

- the new behavior should be controlled by a filter, so we can enable/disable it easily
- the new transients should not autoload
- the transient keys should use a clear B2BKing prefix so we can monitor them
- the split should preferably be per logical data point/group, not too granular per request
- if possible, avoid refreshing an individual transient when that specific value has not changed

The goal for us is not necessarily to reduce the number of writes to zero, but to avoid repeatedly writing one large serialized transient during normal public requests + just to optimise the database writes.

Is this something you are able to do without to much work?

Would this be beneficial for all users? 

When this would be ready we will monitor the impact on:

_transient_b2bking_global_data
_transient_timeout_b2bking_global_data
wp_options write volume
overall database stability

Thanks again for looking into this.

Kind regards, 

Timothy

Hi Stefan,

Thank you for preparing the updated build and adding the filter.

I have reviewed the approach and this looks like the right next test for our setup. We will install the provided B2BKing Pro build and enable:

add_filter( 'b2bking_split_data_transients', '__return_true' );

We understand that this may not reduce the total number of writes to zero, but the goal for us is mainly to avoid repeatedly writing one large serialized b2bking_global_data transient during normal public requests.

After enabling it, we will monitor:

_transient_b2bking_global_data
_transient_timeout_b2bking_global_data
_transient_b2bking_global_data_*
_transient_timeout_b2bking_global_data_*
wp_options write volume
average and maximum option value size
overall database stability

We will test this together with the other performance filters we already use, and I will report back with the results.

Thanks again for preparing this so quickly.

Kind regards, 

Timothy

Hi Stefan,

Thank you again for the test build with:

add_filter( 'b2bking_split_data_transients', '__return_true' ); 

We installed the build and monitored the site with detailed wp_options logging, including option names, request context and traces.

The good news is that the split-transient approach is working technically. The old monolithic keys are no longer the main write source:

_transient_b2bking_global_data 
_transient_timeout_b2bking_global_data 

Instead, the data is now split into component-specific transients, for example:

_transient_b2bking_global_data_b2bking_required_multiple 
_transient_b2bking_global_data_b2bking_required_multiple_rules_apply 
_transient_b2bking_global_data_b2bking_minmax 
_transient_b2bking_global_data_b2bking_quotes_products_user_applicable_rules 
_transient_b2bking_global_data_b2bking_tiered_price_user_applicable_rules 

This is an improvement because we no longer repeatedly write one large serialized b2bking_global_data transient. However, the logs now show that some individual split components are still written very frequently.

In the latest monitored period, B2BKing split-transients accounted for the majority of wp_options writes. The most active keys were:

_transient_timeout_b2bking_global_data_b2bking_quotes_products_user_applicable_rules 
_transient_timeout_b2bking_global_data_b2bking_tiered_price_user_applicable_rules 
_transient_timeout_b2bking_global_data_b2bking_required_multiple 
_transient_timeout_b2bking_global_data_b2bking_minmax 
_transient_timeout_b2bking_global_data_b2bking_required_multiple_rules_apply 
_transient_b2bking_global_data_b2bking_required_multiple 
_transient_b2bking_global_data_b2bking_required_multiple_rules_apply 

The largest value payloads are now mainly:

_transient_b2bking_global_data_b2bking_required_multiple 
_transient_b2bking_global_data_b2bking_required_multiple_rules_apply 

These are much smaller than the old full global transient, but they are still updated very often.

What is important in our setup: we currently only have one active Dynamic Rule, and that is a Tax Exemption rule for B2B users. We do not use Required Multiple rules, Minimum/Maximum Order rules, Free Shipping rules or Quote Product rules.

Despite that, the logs show that required_multiple, minmax, quotes_products_user_applicable_rules and tiered_price_user_applicable_rules are still being triggered by normal public traffic and bots on product/category/filter pages.

Looking at the code, this seems related to logic such as:

get_option( 'b2bking_have_minmax_rules', 'yes' ) === 'yes' 
|| apply_filters( 'b2bking_auto_activate_minmaxstep_rules_meta', true ) 

and similarly for required multiple:

get_option( 'b2bking_have_required_multiple_rules', 'yes' ) === 'yes' 
|| apply_filters( 'b2bking_auto_activate_minmaxstep_rules_meta', true ) 

Because b2bking_auto_activate_minmaxstep_rules_meta defaults to true, it appears that the min/max and required-multiple logic can still be activated even when no dynamic rules of those types are configured.

That means bots and public product/filter traffic can still trigger these components and cause split-transient writes, even though the store does not actively use those rule types.

Our current conclusion:

- The split-transient build works and is an improvement. 
- It reduces the impact of one large global transient. 
- However, B2BKing still builds/persists data for some unused components. 
- The biggest remaining examples are required_multiple and minmax. 

Would it be possible to further guard these components so they only run when that specific rule type is actually active?

For example:

- do not hook required_multiple logic unless required_multiple rules exist 
- do not hook minmax logic unless minimum/maximum order rules exist 
- do not persist split-transient components for unused rule types 
- avoid refreshing split-transient timeouts when the component value has not changed 

In our case, the only dynamic rule that should remain active is Tax Exemption. So ideally B2BKing should not build or persist required_multiple, minmax or quote-product rule caches during normal public requests.

As a next test on our side, we are planning to enable:

Disable dynamic rule required multiple 
Disable dynamic rule minimum and maximum order 

because we do not use those features. We will then monitor whether the corresponding split-transient writes disappear.

Thanks again for preparing the split-transient build. It definitely helped us isolate the next layer of the issue.

Kind regards,  
Timothy

Hi Stefan,

Thank you again for the previous explanation and the test build with:

add_filter( 'b2bking_split_data_transients', '__return_true' );

We have now continued monitoring the site after applying your recommendations.

First of all, your suggestion regarding required_multiple and minmax was correct. After enabling the following settings:

Disable dynamic rule required multiple
Disable dynamic rule minimum and maximum order

and with the split-transient build active, the related writes have effectively disappeared from our logs.

Previously, we saw frequent writes to:

_transient_b2bking_global_data_b2bking_required_multiple
_transient_timeout_b2bking_global_data_b2bking_required_multiple
_transient_b2bking_global_data_b2bking_required_multiple_rules_apply
_transient_timeout_b2bking_global_data_b2bking_required_multiple_rules_apply
_transient_b2bking_global_data_b2bking_minmax
_transient_timeout_b2bking_global_data_b2bking_minmax

After disabling those components, these are now gone or negligible. That is a clear improvement.

The remaining B2BKing-related writes are now mostly split-transient timeout rows, especially:

_transient_timeout_b2bking_global_data_b2bking_tiered_price_user_applicable_rules
_transient_timeout_b2bking_global_data_b2bking_quotes_products_user_applicable_rules
_transient_timeout_b2bking_global_data_b2bking_info_table_user_applicable_rules

The important detail is that the related split values themselves barely change anymore. In our latest detail logs, the value hashes for the corresponding split values were usually identical, but the timeout rows were still refreshed thousands of times.

So the current situation is:

- the split-transient build works
- required_multiple/minmax are now resolved
- the large value writes are mostly gone
- but split-transient timeout rows are still refreshed very frequently

Would it be possible to avoid refreshing the split-transient timeout row when the component value has not changed?

In other words: if the split component value is identical to the stored value, could B2BKing skip refreshing the matching _transient_timeout_b2bking_global_data_* option as well?

We also noticed a separate warning in the PHP error logs:

Get cart should not be called before the wp_loaded action.

The trace points to this path:

init
→ B2bking_Dynamic_Rules::b2bking_dynamic_rule_tax_exemption
→ WC_Cart->get_cart_hash
→ WC_Cart_Session->get_cart_for_session
→ WC_Product_Variation->is_purchasable
→ B2bking->b2bking_make_quote_product_purchasable
→ B2bking_Globalhelper::user_has_p_in_cart
→ WC_Cart->get_cart

Our only active Dynamic Rule is still Tax Exemption. However, during normal frontend requests, B2BKing appears to reach quote/cart-related logic and calls WC()->cart / WC_Cart->get_cart() during init, before wp_loaded.

WooCommerce reports this as a doing_it_wrong warning.

Could this logic be moved to wp_loaded, or guarded so it does not run during normal public requests unless cart context is actually needed?

To summarize the current findings:

- Required multiple/minmax issue: resolved after your recommendation
- Split transient value writes: strongly improved
- Remaining B2BKing database churn: mainly timeout refreshes
- Remaining runtime warning: WC cart is accessed too early via tax exemption / quote-product logic

Thanks again for the help. The changes have definitely improved the situation, and we are now down to these remaining optimization points.

Kind regards,
Timothy