Scripts & Styles Generator
The right hook for every context, filemtime() cache busting and conditional loading — so assets only ship where they are used.
// Generated with WP CodeKit — powered by GrowQuest (https://growquest.io). /** * Enqueue front end assets. */ function mytheme_enqueue_front_assets() { wp_enqueue_style( 'mytheme-main', get_theme_file_uri( 'assets/css/main.css' ), array(), filemtime( get_theme_file_path( 'assets/css/main.css' ) ), 'all' ); wp_enqueue_script( 'mytheme-main', get_theme_file_uri( 'assets/js/main.js' ), array(), filemtime( get_theme_file_path( 'assets/js/main.js' ) ), array( 'in_footer' => true, 'strategy' => 'defer', ) ); wp_localize_script( 'mytheme-main', 'mythemeData', array( 'ajaxUrl' => admin_url( 'admin-ajax.php' ), 'nonce' => wp_create_nonce( 'mytheme_nonce' ), ) ); } add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_front_assets' );
About this generator
Scripts & Styles Generator Online
A wp_enqueue_script generator that writes the whole registration, not just the one line. Each asset gets a prefixed handle, a real URL helper (get_theme_file_uri() or plugins_url()), its dependency array, a filemtime() version for cache busting and, for scripts, the WordPress 6.3 loading-strategy array — all inside a callback attached to the correct hook for its context.
The Load map tab lists every asset beside the hook it rides on and where it ends up in the page, so you can see at a glance that the admin script really is gated on $hook_suffix and the deferred script really is in the footer. Free, no sign-up, and nothing leaves your browser.
Reviewed Output tested on WordPress 6.8 · PHP 8.3
Why the wp_enqueue_script generator beats a hand-written enqueue block
The function call is easy. What goes wrong is everything around it: an unprefixed handle that replaces core jQuery, a version argument left at null so browsers keep serving yesterday's CSS, admin assets loaded on every screen in the dashboard, and wp_head used for scripts that should have been queued. Each of those has a check here.
The right hook for each context
Front end, admin screens, block editor and login screen map to wp_enqueue_scripts, admin_enqueue_scripts, enqueue_block_editor_assets and login_enqueue_scripts. Assets are grouped into one callback per context, and the admin callback is generated with a $hook_suffix check so it does not fire on every dashboard page.
Cache busting that is actually correct
filemtime() versioning resolves through get_theme_file_path() or plugin_dir_path( __FILE__ ) depending on where the files live. You can also use a version constant or a fixed string; choosing null raises a warning, because the version then falls back to the WordPress version and your edits never reach a returning visitor.
Handle collisions caught before deployment
Naming an asset jquery, wp-element, lodash or any of the other core handles is an error with a one-click prefix fix. Two assets of the same type sharing a handle is an error too — WordPress silently ignores the second enqueue.
Loading strategies, not just footer flags
Defer and async emit the WordPress 6.3 argument array (in_footer plus strategy) rather than the old boolean. Loading in the head is flagged as render-blocking, and an async script that declares dependencies raises a warning, since async ignores order.
Typed wp_localize_script rows
Pass data to JavaScript without hand-writing the array: pick admin_url( 'admin-ajax.php' ), wp_create_nonce(), esc_url_raw( rest_url() ), a translated string or raw PHP, and the keys are aligned in the output. A localised script with no object name is an error.
Conditional loading and the usual extras
Restrict front-end assets to is_front_page(), is_singular(), is_post_type_archive(), is_page_template(), has_shortcode() or has_block(). Optional blocks move jQuery to the footer, add wp_set_script_translations() or dequeue the core block stylesheet — with a warning that the last one breaks default block styling.
How does the Scripts & Styles Generator work?
Four steps from an empty assets folder to a registration block you can paste.
- 01
Say where the files live
Theme or plugin — that decides whether URLs come from
get_theme_file_uri()orplugins_url( …, __FILE__ ). Set the handle prefix, the asset folder and the version strategy. - 02
Add each script and stylesheet
For every asset: script or style, handle, file path, context, comma-separated dependencies, and either a media attribute or a loading strategy.
- 03
Localise and narrow
Attach data rows to any script, then choose whether front-end assets load everywhere or only on a matching page, template, shortcode or block.
- 04
Check the load map, then export
The Load map tab shows each handle, its hook and its final position in the page. Clear the Checks tab, then copy or download as a snippet, a
functions.phpblock or a plugin file.
Worked example — one deferred theme script with localised data
A theme asset in assets/js/main.js, deferred to the footer, versioned by file modification time, with the AJAX URL and a nonce handed to JavaScript.
/**
* Enqueue front end assets.
*/
function mytheme_enqueue_front_assets() {
wp_enqueue_script(
'mytheme-main',
get_theme_file_uri( 'assets/js/main.js' ),
array(),
filemtime( get_theme_file_path( 'assets/js/main.js' ) ),
array(
'in_footer' => true,
'strategy' => 'defer',
)
);
wp_localize_script(
'mytheme-main',
'mythemeData',
array(
'ajaxUrl' => admin_url( 'admin-ajax.php' ),
'nonce' => wp_create_nonce( 'mytheme_nonce' ),
)
);
}
add_action( 'wp_enqueue_scripts', 'mytheme_enqueue_front_assets' );filemtime() reads the filesystem on every request. That is ideal in development, where every save busts the cache; for a high-traffic production site, switch the version strategy to a theme or plugin version constant.
Enqueueing scripts and styles — frequently asked questions
The questions developers ask most often about loading assets in WordPress.
Which hook should I use to enqueue scripts in WordPress?
Front-end assets go on wp_enqueue_scripts. Admin assets go on admin_enqueue_scripts, which passes $hook_suffix so you can load them on one screen instead of the whole dashboard. Block editor assets go on enqueue_block_editor_assets, and the login page has its own hook, login_enqueue_scripts. They are four different hooks; using the front-end one in the admin loads nothing.
How do I stop browsers caching my CSS after I change it?
Pass a version as the fourth argument that changes when the file does. filemtime( get_theme_file_path( 'assets/css/main.css' ) ) uses the file's modification time, so every save produces a new URL. Passing null is the common mistake: WordPress then appends the WordPress version, which does not change when your file does.
What is the difference between wp_register_script() and wp_enqueue_script()?
Registering records the handle, URL, dependencies and version without adding the file to the page. Enqueueing is what actually outputs it. Register once early when several conditions might request the same file, then call wp_enqueue_script( 'handle' ) with no other arguments where you need it. If you only ever load it in one place, enqueueing directly is enough.
How do I add defer or async to an enqueued script?
Since WordPress 6.3 the fifth argument accepts an array: array( 'in_footer' => true, 'strategy' => 'defer' ). Defer keeps execution order, so it is safe with dependencies; async does not, so an async script that depends on another can run before it. Before 6.3 the fifth argument was only the in_footer boolean and you had to filter script_loader_tag.
Why is my script loading but my jQuery code not running?
Core loads jQuery in no-conflict mode, so the $ shortcut is not defined globally. Wrap your code in jQuery( function ( $ ) { … } ); or use jQuery directly. The other common cause is a missing dependency: if jquery is not in the dependency array, your file can be printed before jQuery is.
How do I pass a PHP value, like an AJAX URL or nonce, to my JavaScript?
wp_localize_script( 'handle', 'objectName', array( … ) ) prints the array as a JavaScript object before your file loads. It must be called after the script is registered or enqueued, using the same handle. For anything that is not translation-related, wp_add_inline_script() is the more modern alternative and can inject arbitrary JavaScript rather than only an object.
Where do I paste the code from the Scripts & Styles generator?
You have three good options and one bad one. Best is a small site-specific plugin — the generator can output one for you, and it keeps working when you change theme. A code-snippets plugin is fine too. A child theme's functions.php works but ties the code to that theme. Never edit the parent theme: the next update overwrites it and your code is gone.
Can I use the generated code in client work or a commercial plugin?
Yes. The output is ordinary WordPress API calls that you configured — there is no licence attached to it and no attribution required. Use it in client sites, commercial plugins and themes, or products you sell. The generated file carries a short credit comment you are free to delete.
The other Core generators in the library, plus the WordPress tools most often used alongside this one.