Your script would end up in the wrong place that way. Even though it works, the page wouldn’t validate. (AFAICT, unconfirmed) In any case, all external javascript in WP should be enqueued through wp_enqueue_script(). The enqueue process doesn’t care where the script resides, only that the URL provided is valid and accessible by the browser.
In the case of inline scripts, you can output it from any convenient action that fires after HTML output has started. Depending on placement and dependency, inline script may need to be wrapped in an event listener, such as for ‘DOMContentLoaded’. All the enqueued scripts loaded in head are output with the “wp_print_scripts” action. You can output your inline script with the same action. Hook the action with a large priority number so it is output after the external references. Or small priority to appear before. Unless your inline script is relatively simple, it’s best to place it in an external file and enqueue it so WP can properly manage any dependencies.
If a file that needs to be in root does not actually exist there, you can have WP dynamically fill the request. When the server finds no such file exists, the request is passed on to WP (for root WP installs). As long as the response from WP is appropriate for the requested file, it doesn’t matter where it really comes from. SEO plugins often do this to dynamically serve sitemap and robots.txt files. I believe they hook into the “request” action where WP thinks it’s a page name request. If your callback sees this page request and responds appropriately with headers and data, then exits, all is well as though the file actually existed.
The only other alternatives would be to add a rewrite rule in .htaccess to serve the plugin file in response to a root request, or to physically copy the file to root on plugin activation.
With wp_enqueue_script the javascript would be included in the head of my WP page, right? That it’s something that I don’t desire.
The approach of using a add_filter over request seems nice too, but doesn’t differ much from the one I propose.
Instead of using
add_action( 'wp', 'sw_entry_point' );
I would be using
add_filter( 'request', 'sw_entry_point' );
It’s that it?
Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
With wp_enqueue_script the javascript would be included in the head of my WP page, right? That it’s something that I don’t desire.
No, you can choose where it loads using the $in_footer parameter: https://developer.wordpress.org/reference/functions/wp_enqueue_script/
In regards to “wp” vs. “request” actions when fulfilling a non-existent file request, you are correct, it may not matter much. It depends on what data you need from WP to generate the output. If WP data is not needed at all, the earliest action possible is preferable.
Which action to hook is an issue if you are injecting your script into a normal WP request, in which case neither “wp” or “request” is correct. In that case enqueuing an external file is the preferred approach. If you must inject inline script, use either “wp_print_scripts” or “wp_footer”, depending on where you want your script to appear. It’s relation to other scripts added through the same action is managed with the priority parameter supplied when adding your callback.
I don’t want the script to be in the footer or the head. Just to be accessible throw http://www.exampledomain.com/sw.js, so I think I’m good with the request or WP solution.
Thanks,
