The contents of a page may be drastically different depending on whether or not a user is logged-in. For example, consider a membership site or a site with a paywall. Optimization Detective will store two sets of URL Metrics for those who are logged-in and those who aren't. For administrators, URL Metrics are not gathered at all by default since yet additional frontend elements are conditionally displayed to them for site editing purposes (although see #1425 for a possible reconsideration on this).
The way that different sets of URL Metrics are stored by authenticated state is currently implemented by adding a user_logged_in to the normalized query vars:
|
function od_get_normalized_query_vars(): array { |
|
global $wp; |
|
|
|
// Note that the order of this array is naturally normalized since it is |
|
// assembled by iterating over public_query_vars. |
|
$normalized_query_vars = $wp->query_vars; |
|
|
|
// Normalize unbounded query vars. |
|
if ( is_404() ) { |
|
$normalized_query_vars = array( |
|
'error' => 404, |
|
); |
|
} |
|
|
|
// Vary URL Metrics by whether the user is logged in since additional elements may be present. |
|
if ( is_user_logged_in() ) { |
|
$normalized_query_vars['user_logged_in'] = true; |
|
} |
|
|
|
return $normalized_query_vars; |
|
} |
However, this feels like somewhat of a hack. When inspecting the od_url_metrics posts (such as via my hacked-together Optimization Detective Admin UI plugin), you can see that two posts are for the same URL and yet they have different slugs:
This is because the slugs are computed by hashing the query vars. When adding another Optimization Detective extension plugin to capture the query vars in the URL Metrics, you can see this difference in the query vars, here for the homepage:
| Logged-in |
Logged-out |
 |
 |
Considering a the logged-in state as a "query var" successfully results in two sets of URL Metrics being captured, but ultimately it feels like a hack because user_logged_in isn't a query var at all. It's more similar to the kind of internal state data being described in #1466, although it's not really appropriate there either since whether a user is logged-in shouldn't have any impact on whether a URL Metrics post is considered stale or not, as again there should be two sets of URL Metrics in which the user is always logged-out for one and always logged-in for the other.
Nevertheless, maybe it does make sense to consider user_logged_in as a query var when considering that even though it isn't reflected in the requested URL, it is reflected in the cookie. So maybe I just argued myself back to where I started from. in any case, I wanted to open an issue to perhaps discuss further and explain my thought process.
The contents of a page may be drastically different depending on whether or not a user is logged-in. For example, consider a membership site or a site with a paywall. Optimization Detective will store two sets of URL Metrics for those who are logged-in and those who aren't. For administrators, URL Metrics are not gathered at all by default since yet additional frontend elements are conditionally displayed to them for site editing purposes (although see #1425 for a possible reconsideration on this).
The way that different sets of URL Metrics are stored by authenticated state is currently implemented by adding a
user_logged_into the normalized query vars:performance/plugins/optimization-detective/storage/data.php
Lines 66 to 86 in 20a038f
However, this feels like somewhat of a hack. When inspecting the
od_url_metricsposts (such as via my hacked-together Optimization Detective Admin UI plugin), you can see that two posts are for the same URL and yet they have different slugs:This is because the slugs are computed by hashing the query vars. When adding another Optimization Detective extension plugin to capture the query vars in the URL Metrics, you can see this difference in the query vars, here for the homepage:
Considering a the logged-in state as a "query var" successfully results in two sets of URL Metrics being captured, but ultimately it feels like a hack because
user_logged_inisn't a query var at all. It's more similar to the kind of internal state data being described in #1466, although it's not really appropriate there either since whether a user is logged-in shouldn't have any impact on whether a URL Metrics post is considered stale or not, as again there should be two sets of URL Metrics in which the user is always logged-out for one and always logged-in for the other.Nevertheless, maybe it does make sense to consider
user_logged_inas a query var when considering that even though it isn't reflected in the requested URL, it is reflected in the cookie. So maybe I just argued myself back to where I started from. in any case, I wanted to open an issue to perhaps discuss further and explain my thought process.