You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
bw_trace_reset_status() determines whether or not the trace file needs to be reset based on a number of values.
When debugging my WooCommerce shipping plugin I found I had to configure trace reset to not reset the trace file every transaction since the Cart display was immediately followed by wc-ajax=get_refreshed_fragments.
Altering bw_trace_reset_status() to not reset when the $_REQUEST contained 'wc-ajax' was a pragmatic solution to the trace reset problem.
I think the solution should should be generalised. e.g. The AJAX heartbeat request may be another example where you don't want (AJAX) tracing to be reset.
The text was updated successfully, but these errors were encountered:
With the changes for #71 this solution is no longer necessary. You can set the Trace file generation limit, so that each transaction's output is traced to a different file. It doesn't make sense to set the value to a small number like 1 or 2.
This wasn’t closed in v3.0.0. Moving to 3.1.0. Need to remove logic that responds to a reset parameter being passed in the URL. It’s no longer necessary.
bw_trace_reset_status() determines whether or not the trace file needs to be reset based on a number of values.
When debugging my WooCommerce shipping plugin I found I had to configure trace reset to not reset the trace file every transaction since the Cart display was immediately followed by
wc-ajax=get_refreshed_fragments
.Altering bw_trace_reset_status() to not reset when the $_REQUEST contained 'wc-ajax' was a pragmatic solution to the trace reset problem.
I think the solution should should be generalised. e.g. The AJAX heartbeat request may be another example where you don't want (AJAX) tracing to be reset.
The text was updated successfully, but these errors were encountered: