JavaScript Developer for Hire

Broken JavaScript on WordPress sites has a small set of common causes that cover the vast majority of cases.nnjQuery noConflict conflict - WordPress loads jQuery in noConflict mode, which means the $ shorthand is not available. Code written as $('selector') needs to be jQuery('selector') or wrapped in (function($){ ... })(jQuery); to work.nnMissing script dependency - if a script uses jQuery but is registered without 'jquery' in its dependency array in wp_enqueue_script(), it may load before jQuery is available, causing 'jQuery is not defined' errors.nnDeferred by caching plugin - WP Rocket's JavaScript delay or LiteSpeed Cache's JS defer may be preventing a script from running on page load. The script needs to be added to the plugin's exclusion list.nnScript loading after DOM events - code that attaches events to elements needs to run after the DOM is ready. Wrapping in jQuery(document).ready() or using the DOMContentLoaded event listener solves this.

The correct method is wp_enqueue_script(). Never add script tags directly to a template file or functions.php output.nnwp_enqueue_script( 'my-script', get_stylesheet_directory_uri() . '/js/my-script.js', array('jquery'), '1.0.0', true );nnThe parameters are: handle (unique name), source URL, dependencies array (scripts that must load first), version, and whether to load in the footer (true) or header (false).nnLoading scripts in the footer (last parameter true) is best practice for performance - it prevents the script from blocking HTML parsing. The exception is scripts that need to run before the page renders, like critical CSS or analytics snippets that must fire immediately.

WordPress AJAX uses admin-ajax.php as a central endpoint. The JavaScript sends a POST request to admin-ajax.php with an action parameter, and WordPress routes that action to the PHP function registered to handle it.nnOn the PHP side: add_action('wp_ajax_my_action', 'my_ajax_handler'); for logged-in users, add_action('wp_ajax_nopriv_my_action', 'my_ajax_handler'); for non-logged-in users.nnOn the JavaScript side: jQuery.post(ajaxurl, { action: 'my_action', nonce: myData.nonce, data: value }, callback);nnAlways include a nonce in AJAX requests and verify it server-side with check_ajax_referer() to prevent unauthorized requests. The ajaxurl variable is available automatically in the admin. On the frontend, pass it via wp_localize_script().

For new WordPress projects in 2026, vanilla JavaScript is the better choice for most frontend work. Modern browsers support all the DOM methods and event handling that jQuery provides - document.querySelector(), addEventListener(), fetch() for AJAX - without the extra 30KB library weight.nnjQuery is still appropriate when: you are extending existing jQuery-dependent plugin code, you need to use jQuery's AJAX methods for WordPress admin-ajax.php compatibility, or you are working with a legacy codebase where consistency matters more than optimization.nnFor Gutenberg blocks, neither jQuery nor vanilla DOM manipulation is used - blocks are built with wp.element (a React abstraction) and the @wordpress/scripts toolchain.

wp_localize_script() is the WordPress function for passing PHP data to JavaScript. It creates a JavaScript object attached to an enqueued script that contains whatever data you pass from PHP.nnCommon uses: passing the admin-ajax.php URL to frontend scripts so they can make AJAX requests; passing a nonce value for AJAX security verification; passing user-specific data like cart totals or logged-in status; passing configuration values from WordPress options to JavaScript without hardcoding them.nnThe alternative in modern WordPress is wp_add_inline_script(), which appends a JavaScript string directly before or after an enqueued script. Both approaches are correct - wp_localize_script() is simpler for passing key-value data objects.

Yes. I build custom Gutenberg blocks using the @wordpress/scripts toolchain, which handles Webpack and Babel configuration automatically.nnA custom block consists of block.json (registration metadata), an edit component (what the editor sees with editable fields), and either a save component (static front-end output) or a PHP render_callback (dynamic output from the database).nnDynamic blocks with a PHP render_callback are the better choice for most WordPress use cases because the front-end output can change based on current data - a block that shows the latest three posts will always show the current latest three, not the three that were latest when the block was first saved.nnI also build blocks using ACF Blocks (ACF PRO) when the project is already using ACF, which avoids the React complexity entirely for simpler editorial blocks.

This error means your script is executing before jQuery has loaded, or jQuery has not been declared as a dependency.nnFix 1 - declare jQuery as a dependency in wp_enqueue_script(): in the dependencies array parameter, include 'jquery'. WordPress will then ensure jQuery loads before your script.nnFix 2 - if you are loading the script via a plugin that does not use wp_enqueue_script(), move the script to load in the footer (after jQuery) rather than in the header.nnFix 3 - if the script uses $ and fails, wrap all code in (function($){ your code here })(jQuery); This passes jQuery as the $ parameter locally, which is safe in WordPress's noConflict environment.

WooCommerce triggers custom jQuery events at key points in the shopping experience. Using these correctly is essential for custom WooCommerce JavaScript that needs to react to store actions.nnKey events: added_to_cart fires after a product is added via AJAX. updated_cart_totals fires after the cart is recalculated. updated_checkout fires when the checkout page is refreshed. payment_method_selected fires when the customer changes payment method. wc_fragments_refreshed fires after cart fragments are updated.nnThe correct way to attach to these: jQuery(document.body).on('added_to_cart', function(event, fragments, cart_hash){ ... });nnStandard DOM events like click attached to WooCommerce buttons often break after cart fragment refreshes because the buttons are re-rendered and the event listener is lost. Always use delegated events attached to document.body for WooCommerce UI.

This is almost always a caching issue. The live site is serving a cached version of the page or the JavaScript file that does not match what you are testing.nnSteps to diagnose: clear all caches - WP Rocket, LiteSpeed, server-level, and Cloudflare. Then test in an incognito browser window to rule out browser cache.nnIf the issue persists, check whether a caching plugin is combining or minifying JavaScript files and breaking the output. Disable JS combination temporarily and retest.nnA second common cause is that the script works on the dev domain because the admin-ajax.php URL or nonce is hardcoded to the dev URL, and those values are wrong on the live domain. Always pass these dynamically via wp_localize_script() rather than hardcoding them.

For Gutenberg block development I use wp.element, which is WordPress's React abstraction layer - it uses React under the hood but through WordPress's own package so the React version stays in sync with WordPress core.nnFor standalone React or Vue frontends decoupled from WordPress (headless WordPress), my approach is to build and expose the correct REST API or GraphQL endpoints in WordPress and work with a front-end developer on the React or Vue layer if the project requires one. My depth is in WordPress as a backend and content management system, not in building React single-page applications.nnFor most WordPress business sites, vanilla JavaScript and jQuery are the right tools - they add no build complexity, work in every browser, and do not require a Node.js build step every time a change is needed.