bobbingwide
commented
2 years ago Looking at the output from Query Monitor, it seems that you don't have to produce the output before the </html>
Closed bobbingwide closed 11 months ago
bobbingwide
commented
2 years ago Looking at the output from Query Monitor, it seems that you don't have to produce the output before the </html>
bobbingwide
commented
2 years ago In a WordPress Multi Site install with subdirectory installs the current logic doesn't convert the trace file name to the correct URL.
In s.b/wp55/thisis the trace files directory is set to C:/apache/htdocs/wp55/bwtrace
ABSPATH is C:\apache\htdocs\wp55/. This gets standardized to C:/apache/htdocs/wp55/
When ABSPATH is removed and replaced with the output from get_site_url()
a trace file name of C:/apache/htdocs/wp55/bwtrace/thisis.loh.11 is transformed to to
https://s.b/wp55/thisis/bwtrace/thisis.loh.11.
There's an unwanted thisis.
The unwanted thisis is also added to the link for the daily trace summary.
It's OK for site ID 1.
This problem can be fixed by replacing
$trace_file_url = get_site_url(null, $file_name);with
$trace_file_url = network_site_url( $file_name );Note: When it's not a Multi Site installation network_site_url() calls site_url(), which calls get_site_url().
When it is Multi Site it calls get_network() etc...
bobbingwide
commented
2 years ago Having used this new capability for a while I've decided I don't want to see the links when running batch routines from the command line.
bobbingwide
commented
2 years ago I observed in s.b/wordpress than when performance tracing is deselected the Trace fles directory was being incorrectly determined. I expected the daily trace summary to be https://s.b/wordpress/bwtrace3/bwtrace.vt.20220824 but it was in the PHPUnit tests folder https://s.b/wordpress/wp-content/plugins/oik-bwtrace/tests/bwtrace/bwtrace.vt.20220824
bobbingwide
commented
1 year ago I observed in
s.b/wordpressthan when performance tracing is deselected the Trace fles directory was being incorrectly determined. I expected the daily trace summary to behttps://s.b/wordpress/bwtrace3/bwtrace.vt.20220824but it was in the PHPUnit tests folderhttps://s.b/wordpress/wp-content/plugins/oik-bwtrace/tests/bwtrace/bwtrace.vt.20220824
This problem was due to the PHPUnit tests changing the values and not resetting them. See https://github.com/bobbingwide/oik-bwtrace/issues/109#issuecomment-1751744171 Fixed in 093e45d
bobbingwide
commented
11 months ago Delivered in v3.4.1
When developing and/or debugging code locally it's a bit of a pain to have find the name of the trace file in order to be able to view it.
Current method
When the request is not a front-end browser request then the Daily Trace Summary file is needed. When this file is not available then the trace file has to be located in the trace files directory.
This is a bit time consuming and not conducive to debugging.
More often than not, in the development environment the trace file will be browsable. So why not produce a link to the file for the current display? And also a link to the daily trace summary? That way, it'll be much easier to view the most recent trace output.
Requirements
Proposed solution
There will be a new checkbox, labelled Trace 'shutdown' display trace file links, on the oik actions admin page.
The output will be produced regardless of the value of the Trace 'shutdown' status report checkbox.
Unlike other plugins, such as Query Monitor, the links will be produced with very little attempt to style and position them correctly. The user may have to scroll to the bottom of the page to see them.
As this option is intended for use in a development environment, not production, the links will be produced regardless of the current user's capabilities.