With the move to more JavaScript and Styles in WordPress admin pages and editors, I spend some time debugging what styles and scripts are being loaded on a given page. (Specially important if you’re working on blocks, or JavaScript rendered admin pages)
To help with that I use a small vibe-coded tool. It helps understanding why a script or style was enqueued on a given page.
For each script (or style) it gives:
- The uncompressed size.
- If it was enqueued explicitly.
- Which ancestor script was enqueued explicitly causing the current one to be loaded in the page as well.
- What is the direct parent script.
And it presents all of that in a digestible list.
How to use it
- Just drop the file in your WordPress plugins folder (or load in another existing plugin)
- Append
?debug_scripts=trueto the url of the admin page that you want to debug.
That’s it, for a more complete debugging solution, consider checking the excellent Query Monitor plugin.
3 responses to “Debugging WordPress Scripts and Styles”
Coincidentally, I recently learned about a Trac ticket to expose more of the data about script modules so there we don’t have to resort to the Reflection API: https://core.trac.wordpress.org/ticket/60597
It’s funny that the AI is trying to use the WP_Script_Modules::get_registered() and WP_Script_Modules::get_enqueued() and methods when these has never existed as far as I know. But in 6.9 there WILL at least be a WP_Script_Modules::get_queue() method (now in trunk)!
It turns out that Query Monitor is accessing private members of WP_Script_Modules and this broke in 6.9-beta1 with some of the internal refactoring: https://core.trac.wordpress.org/ticket/61734#comment:53
Haha indeed 🙂
It’s fair to say that the pages I tested didn’t have scripts modules, so I was not able to spot this issue 🙂
[…] his personal blog, Riad Benguella, lead developer on the Gutenberg project, wrote about Debugging WordPress Scripts and Styles. He introduced a vibe-coded tool addressing increased JavaScript and CSS complexity in WordPress […]