Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TRY] Optimization Detective debug helper #1759
base: trunk
Are you sure you want to change the base?
[TRY] Optimization Detective debug helper #1759
Changes from 6 commits
fc95f4a
651577e
ff3f120
9dd8159
12a3494
be0be49
e9bbe99
ac4d153
098191c
9288025
2f507a0
8ead9ae
ad09dea
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So cool!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll want to include the LoAF data here at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
O invoker commands, where art thou?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since pages aren't optimized by default for users who can
customize
, this presents a dilemma. We'd really want to show data collected for end users who aren't logged-in, but as it stands right now only the URL Metrics collected from an admin user would be collected here, which again would normally be none.Otherwise, URL Metrics are collected for logged-in users but they are stored discretely from those stored for logged-out users. See the
user_logged_in
"query var" added in theod_get_normalized_query_vars()
function:performance/plugins/optimization-detective/storage/data.php
Lines 66 to 86 in c446d8c
I'm not entirely happy with how I "abused" the query vars in this way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, well, if we want to access the URL Metrics for unauthenticated requests then we just need to unset the
user_logged_in
key from the array returned byod_get_normalized_query_vars()
below. In fact, we could obtain the URL Metrics from both and combine them into oneOD_URL_Metric_Group_Collection
, perhaps with a sample size of2 * od_get_url_metrics_breakpoint_sample_size()
.The remaining issue is what to do about the XPaths from the unauthenticated URL Metrics not applying to the current authenticated response (e.g. due to the admin bar). I think we may need an alternative to how we currently check if the current XPath via
$processor->get_xpath()
matches an XPath stored in a URL Metric. In particular, consider/*[1][self::HTML]/*[2][self::BODY]/*[1][self::DIV]/*[2][self::MAIN]/*[1][self::DIV]/*[3][self::DIV]/*[1][self::FIGURE]/*[1][self::IMG]
/*[1][self::HTML]/*[2][self::BODY]/*[2][self::DIV]/*[2][self::MAIN]/*[1][self::DIV]/*[3][self::DIV]/*[1][self::FIGURE]/*[1][self::IMG]
Note the slight difference in the index of the
DIV
caused by the admin bar:Maybe we should have a helper that strips out the index from elements which appear as direct children of
BODY
given that arbitrary elements are added/removed atwp_body_open
andwp_footer
? If this instead became normalized to:Or more simply:
Then this would match the
DIV.wp-site-blocks
both for when the user is logged-in and logged-out. This would be particularly effective for block themes which always have this rootDIV.wp-site-blocks
element fromget_the_block_template_html()
. It would be more prone to confusion in classic themes, for example, if there are two rootDIV
elements for both the header and footer. However, in looking at the core themes, every single theme except for Twenty Twenty has a rootDIV#page
wrapper for the page contents afterwp_body_open()
. The one exception is Twenty Twenty but it usesHEADER
,MAIN
, andFOOTER
at the root. So my concerns are likely unfounded and we can just leave the index off of elements which are children ofBODY
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this code is duplicated with what is located in
od_optimize_template_output_buffer()
, maybe we should factor that out into a helper function to return the$group_collection
.