Try: add script attribution data #1629
Conversation
Co-authored-by: Weston Ruter <[email protected]>
adamsilverstein
changed the title
| continue; | ||
| } | ||
| // Gather the plugin slug, name at relative path. | ||
| $plugin_data = $this->get_plugin_data_from_src( $src ); |
There was a problem hiding this comment.
The way that the AMP plugin and Origination project determine which plugin enqueued a script is to wrap each of the action callbacks so that we can capture a list of the enqueued handles before and after an action callback runs, and then any new script handles added can then be attributed to the theme/plugin which is identified as the source for the given function/method via the Reflection API.
In the AMP plugin this is the AMP_Validation_Callback_Wrapper invocable class https://github.com/ampproject/amp-wp/blob/develop/includes/validation/class-amp-validation-callback-wrapper.php
Here's how this is used: https://github.com/ampproject/amp-wp/blob/60a655cdad9e3431b47b2dcc3b2e5ddb86ac5c5e/includes/validation/class-amp-validation-manager.php#L1429-L1490
That wrap_hook_callbacks method runs at the all action.
There was a problem hiding this comment.
we can capture a list of the enqueued handles
does this also capture manually output 3p scripts (eg. analytics) which are arguably the hardest to attribute?
My approach was to wait and run late on wp_footer (since I'm doing my output there anyway), then parse thru the global script object's "done" property which should include any enqueued scripts.
There was a problem hiding this comment.
Yes, it adds buffering individually to the output of all actions: https://github.com/ampproject/amp-wp/blob/60a655cdad9e3431b47b2dcc3b2e5ddb86ac5c5e/includes/validation/class-amp-validation-callback-wrapper.php#L110
And then it wraps the output with HTML comments to indicate the origin of the markup:
https://github.com/ampproject/amp-wp/blob/60a655cdad9e3431b47b2dcc3b2e5ddb86ac5c5e/includes/validation/class-amp-validation-manager.php#L1708
The injection of the HTML comments to later discover the source of markup during validation is an additional redirection which probably is not relevant. For your use case, it's probably better to use the HTML Tag Processor in the output buffet callback to add data attributes to the SCRIPT tags to indicate the origin.
There was a problem hiding this comment.
Sorry, I was referring to scripts being printed manually and not enqueued. But yes, 3P enqueued scripts are also attributes to the relevant plugins/themes. By computing a diff of the the registered/enqueued scripts before and after each hook callback invocation we can determine which callback introduced a script, and then we can look up the origin of the callback via the Reflection API to find out the plugin or theme.
No description provided.