Normally, I would hook into the wp_enqueue_scripts action in order to gather a list of enqueue'd scripts and styles.
However, I have a very intensive process I need to run, thus instead of running it through the site itself, I am hooking into WP CLI.
How can I gather the scripts and styles without having the action wp_enqueue_scripts available to me in CLI? Or is there a CLI action that I am just not finding in the documentation for the WP CLI API?
Normally, I would hook into the wp_enqueue_scripts action in order to gather a list of enqueue'd scripts and styles.
However, I have a very intensive process I need to run, thus instead of running it through the site itself, I am hooking into WP CLI.
How can I gather the scripts and styles without having the action wp_enqueue_scripts available to me in CLI? Or is there a CLI action that I am just not finding in the documentation for the WP CLI API?
- 3 I'm unsure if this is a viable approach. Generally, WP CLI should not know about what page is being accessed, what template is rendered, etc. And as such, it should not be able to get info on which styles and scripts are enqueued. – kero Commented Feb 12, 2021 at 14:38
- 1 The reason why I am doing this in CLI is the plugin generates a content security policy, in order to effectively get everything needed for this, I need to see what's queue'd for the site, in addition to actually parsing other pages for potentially other external content (videos, frames, etc....) As I'm sure you know... with a large site, doing something like this on the web side of it, would not be a good idea.... – Kevin Commented Feb 12, 2021 at 14:43
- 1 p.s. I check the queue's first, so when the actual HTML parsing is going on, if the resource already exists, it isn't re-added – Kevin Commented Feb 12, 2021 at 14:43
- 2 Isn't the CSP for external files? Plugins should not require them at all and instead bundle in the plugin. Yeah, I'd go about HTML parsing as well here. Might be that some bad code isn't using proper methods to enqueue at all. – kero Commented Feb 12, 2021 at 14:45
- 2 Na, it's not an answer to your question and I don't need the internet points that desperately :D Feel free to leave the question open, maybe someone else has an idea, or to delete it. – kero Commented Feb 12, 2021 at 15:06
1 Answer
Reset to default 2You can't, and it doesn't make sense to do so.
Different pages/URLs enqueue different things, e.g. a WP Admin page won't enqueue the same styles and scripts, widgets might enqueue things conditionally, etc.
But in WP CLI those hooks don't run, and there is no page or frontend. So the question doesn't make sense at a fundamental level. It isn't enough to know the URL either, you need to render the page to know which scripts and styles are enqueued. There is no way to know in advance.
Could you render the page in WP CLI? Unlikely, a CLI environment will be missing a lot of the environment that a browser request has. For example, there is no URL, no GET/POST, no current user, cookies, etc.
The closest you can get to this, is a curl request. Just know that the security policy you generate will be specific to that page, and will be missing other scripts and styles, e.g. things only enqueued for admins/logged in users/other pages/etc.