Don't write trace summary report when...

[bobbingwide]

I've come across more instances where the trace summary report is written to output which is being written to a file. In some cases the output affects further processing.

Action	Subsequent Problem?
WooCommerce Product Export	Yes. Dummy products imported.
Advanced Gutenberg Contact form export	?
Advanced Gutenberg Newsletter export	?
Exporting Gravity Forms	Cannot import
edd-api=products request	Downloads block doesn't complete.

See also #20, #48, #75, #77, #100

[bobbingwide]

For the WooCommerce Product Export the request was

/wp-admin/edit.php?post_type=product&page=product_exporter&nonce=0166f6ed59&action=download_product_csv&filename=wc-product-export-2-7-2019-1562056736301.csv

We can detect the action as being download_product_csv in bw_trace_ok_to_echo().

[bobbingwide]

For Advanced Gutenberg Contact form export the $_REQUEST contains

   [page] => advgb_main
    [advgb_export_data_nonce_field] => ae92b12056
    [_wp_http_referer] => /wp-admin/admin.php?page=advgb_main
    [block_data_export] => contact_form.csv

For the Newsletter it's

 [page] => advgb_main
    [advgb_export_data_nonce_field] => f6daaba145
    [_wp_http_referer] => /wp-admin/admin.php?page=advgb_main
    [block_data_export] => newsletter.json

[bobbingwide]

The current solution for oik-bwtrace is not easily extended by users who discover other cases where bw_trace_ok_to_echo() currently thinks it's OK to echo.

In the future, I may want to make this a user configurable field.
... But it's only really necessary when someone is tracking down an issue using tracing and where tracing is getting in the way of solving the problem.

[bobbingwide]

Re-opening: trace summary report should not be written for ACF fields export.

[bobbingwide]

Trace summary export should not be written for Export Divi Customizer settings.
This is a request to wp-admin with the following query parameters.

_REQUEST Array

[et_core_portability] => (string) "1"
[context] => (string) "et_divi_mods"
[name] => (string) "Divi%20Customizer%20Settings"
[nonce] => (string) "eb93443b1a"
[timestamp] => (string) "1273257722307800"

[bobbingwide]

I've come across more situations where producing the trace output report causes problems in the browser.
The most common is when the browser expects a particular content type such as JSON or XML and can't handle the HTML comments. It should be possible to generically detect a Content-Type header record being sent with the value being something which isn't text/html.