Most WordPress theme tutorials teach you how to write a basic index.php, chop it into header.php and footer.php, and toss some CSS into style.css. That approach worked well enough in 2014. Today, enterprise WordPress theme development is a disciplined software engineering practice.

Modern theme development sits at the intersection of server-side PHP templating, modern JavaScript build pipelines, strict database query optimization, and structured design token systems powered by theme.json.

If you build themes for high-traffic publishers, enterprise clients, or custom web applications, you cannot rely on bloated commercial starter themes or brittle page builders. You need a clean, reproducible architecture that gives content editors flexibility without letting them destroy the layout, site speed, or brand guidelines.

This guide walks through the architectural patterns, tooling, and engineering practices required to build production-grade WordPress themes from the ground up.

---

1. The Modern Theme Spectrum: Classic, Block, and Hybrid

WordPress has three architectural paradigms for themes:

1. Classic Themes: Built entirely on PHP templates, functions.php, and traditional WordPress hooks. They rely on the classic template hierarchy and use CSS stylesheets for all design rules.
2. Block Themes (Full Site Editing / FSE): Built primarily on HTML template files located in /templates/ and /parts/, configured through theme.json, and edited visually inside the Site Editor.
3. Hybrid Themes: The pragmatic middle ground. A hybrid theme uses traditional PHP templates for top-level structural layout, routing, and custom post types, while adopting theme.json for design tokens and Gutenberg block patterns for editorial layouts.

Why Enterprise Engineering Teams Choose Hybrid Themes

Full Site Editing offers impressive visual site-building capabilities, but in large-scale client engagements or enterprise software teams, giving non-technical content creators full visual control over site headers, archive queries, and global footers often introduces serious maintenance problems.

Hybrid themes solve this by creating clear architectural boundaries:

• Developers own the structural frame: Page layouts, document metadata, cache headers, semantic markup, and dynamic routing remain controlled in PHP templates.
• theme.json owns the design system: Color palettes, fluid typography formulas, spacing scales, and layout widths are defined centrally in a single configuration file.
• Editors own the content canvas: Authors build rich, modular page content using curated block patterns without touching global page templates.

Production Hybrid Theme File Structure

A clean, maintainable hybrid theme folder structure separates presentation, server logic, and source assets:

my-enterprise-theme/
|-- assets/
|   |-- src/
|   |   |-- js/
|   |   |   \-- main.js
|   |   \-- scss/
|   |       \-- main.scss
|   \-- dist/
|       |-- main.js
|       |-- main.asset.php
|       \-- main.css
|-- inc/
|   |-- setup.php
|   |-- assets.php
|   |-- template-tags.php
|   |-- post-types.php
|   \-- block-patterns.php
|-- patterns/
|   |-- hero-banner.php
|   \-- feature-grid.php
|-- template-parts/
|   |-- header/
|   |   \-- site-nav.php
|   |-- footer/
|   |   \-- site-info.php
|   \-- components/
|       \-- card.php
|-- functions.php
|-- index.php
|-- single.php
|-- page.php
|-- archive.php
|-- 404.php
|-- style.css
\-- theme.json

Keep your functions.php minimal. Use it exclusively to load modular files from the /inc/ directory. When a single functions.php file reaches two thousand lines, finding hook callbacks or debugging registration errors becomes a nightmare.

---

2. Mastering theme.json v3 and Design Token Architecture

The introduction of theme.json transformed WordPress theme development. Instead of writing hundreds of arbitrary utility classes or declaring custom CSS variables in separate stylesheets, theme.json acts as the single source of truth for your entire design system.

WordPress reads theme.json, generates standard CSS custom properties on the :root element (such as --wp--preset--color--primary), injects those variables into both the frontend and the block editor canvas, and automatically configures editor controls based on your rules.

Configuring a Production theme.json (Version 3)

In WordPress 6.6+, theme.json version 3 provides enhanced control over fluid typography, spacing presets, and default block styling.

Here is an enterprise-ready theme.json configuration:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": false,
    "color": {
      "custom": false,
      "customDuotone": false,
      "customGradient": false,
      "defaultGradients": false,
      "defaultPalette": false,
      "palette": [
        {
          "slug": "primary",
          "color": "#0f172a",
          "name": "Navy Slate"
        },
        {
          "slug": "accent",
          "color": "#2563eb",
          "name": "Royal Blue"
        },
        {
          "slug": "surface",
          "color": "#f8fafc",
          "name": "Light Surface"
        },
        {
          "slug": "text",
          "color": "#334155",
          "name": "Body Text"
        },
        {
          "slug": "white",
          "color": "#ffffff",
          "name": "Pure White"
        }
      ]
    },
    "typography": {
      "customFontSize": false,
      "dropCap": false,
      "fluid": true,
      "fontSizes": [
        {
          "slug": "small",
          "size": "0.875rem",
          "name": "Small"
        },
        {
          "slug": "base",
          "size": "1rem",
          "fluid": {
            "min": "0.95rem",
            "max": "1.05rem"
          },
          "name": "Base"
        },
        {
          "slug": "medium",
          "size": "1.25rem",
          "fluid": {
            "min": "1.15rem",
            "max": "1.35rem"
          },
          "name": "Medium"
        },
        {
          "slug": "large",
          "size": "2rem",
          "fluid": {
            "min": "1.5rem",
            "max": "2.25rem"
          },
          "name": "Large"
        },
        {
          "slug": "x-large",
          "size": "3rem",
          "fluid": {
            "min": "2.25rem",
            "max": "3.5rem"
          },
          "name": "Extra Large"
        }
      ]
    },
    "spacing": {
      "margin": true,
      "padding": true,
      "units": ["rem", "px", "%"],
      "spacingScale": {
        "operator": "*",
        "increment": 1.5,
        "steps": 6,
        "mediumStep": 1.5,
        "unit": "rem"
      }
    },
    "layout": {
      "contentSize": "800px",
      "wideSize": "1200px"
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--surface)",
      "text": "var(--wp--preset--color--text)"
    },
    "typography": {
      "fontFamily": "-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif",
      "lineHeight": "1.6"
    },
    "elements": {
      "link": {
        "color": {
          "text": "var(--wp--preset--color--accent)"
        },
        ":hover": {
          "color": {
            "text": "var(--wp--preset--color--primary)"
          }
        }
      },
      "heading": {
        "color": {
          "text": "var(--wp--preset--color--primary)"
        },
        "typography": {
          "fontWeight": "700",
          "lineHeight": "1.2"
        }
      }
    }
  }
}

Defensive Design Controls

Notice the deliberate restrictions inside settings:

• "custom": false: Disallows users from entering arbitrary hex codes in the block inspector, preventing brand color drift.
• "customFontSize": false: Forces editors to pick from pre-approved typography scales.
• "dropCap": false: Removes unneeded typography toggles.
• "defaultPalette": false: Strips default core WordPress colors from the color picker so users only see your theme palette.

These constraints keep your editorial interface clean and ensure every block adheres strictly to the design system.

---

3. Block Patterns and Template Locking Architecture

Block patterns are pre-configured groups of WordPress blocks that authors can insert into their content with one click. In hybrid themes, block patterns replace monolithic page builder widgets and shortcodes.

Registering Custom Pattern Categories

Register dedicated pattern categories in inc/block-patterns.php so your custom patterns stay organized in the block inserter:

<?php
/**
 * Register Theme Pattern Categories.
 */
function theme_register_pattern_categories(): void {
    register_block_pattern_category(
        'theme-marketing',
        array(
            'label' => esc_html__('Marketing Sections', 'my-theme'),
            'description' => esc_html__('High-converting landing page layouts and calls to action.', 'my-theme'),
        )
    );

    register_block_pattern_category(
        'theme-content',
        array(
            'label' => esc_html__('Editorial Components', 'my-theme'),
            'description' => esc_html__('Standard post grids, author bios, and quote cards.', 'my-theme'),
        )
    );
}
add_action('init', 'theme_register_pattern_categories');

File-Based Block Pattern Registration

Starting in WordPress 6.0, you can register block patterns simply by placing PHP files in your theme’s /patterns/ directory. WordPress automatically parses the file headers:

Create /patterns/hero-banner.php:

<?php
/**
 * Title: Enterprise Hero Banner
 * Slug: my-theme/hero-banner
 * Categories: theme-marketing
 * Description: Bold full-width header with primary call to action and subtitle.
 * Keywords: hero, banner, header, landing
 * Viewport Width: 1200
 */
?>
<!-- wp:group {"align":"full","style":{"spacing":{"padding":{"top":"var:preset|spacing|50","bottom":"var:preset|spacing|50"}}},"backgroundColor":"primary","textColor":"white","layout":{"type":"constrained"}} -->
<div class="wp-block-group alignfull has-white-color has-primary-background-color has-text-color has-background" style="padding-top:var(--wp--preset--spacing--50);padding-bottom:var(--wp--preset--spacing--50)">
    <!-- wp:heading {"textAlign":"center","level":1,"fontSize":"x-large"} -->
    <h1 class="wp-block-heading has-text-align-center has-x-large-font-size">Engineer Scalable WordPress Solutions</h1>
    <!-- /wp:heading -->

    <!-- wp:paragraph {"align":"center","fontSize":"medium"} -->
    <p class="has-text-align-center has-medium-font-size">Clean code, decoupled architectures, and high-performance theme engineering for modern web teams.</p>
    <!-- /wp:paragraph -->

    <!-- wp:buttons {"layout":{"type":"flex","justifyContent":"center"}} -->
    <div class="wp-block-buttons">
        <!-- wp:button {"backgroundColor":"accent","textColor":"white"} -->
        <div class="wp-block-button"><a class="wp-block-button__link has-white-color has-accent-background-color has-text-color has-background wp-element-button" href="/contact">Schedule Consultation</a></div>
        <!-- /wp:button -->
    </div>
    <!-- /wp:buttons -->
</div>
<!-- /wp:group -->

Locking Block Templates to Prevent Layout Breakage

One common fear among engineering teams is that editors will accidentally delete required columns, break grids, or alter structural containers.

WordPress solves this through the template_lock property. By setting template_lock => 'contentOnly', editors can modify text strings, upload images, and update button URLs, but they cannot delete blocks, drag items out of their containers, or modify spacing settings.

You can enforce this programmatically on post types:

<?php
/**
 * Lock landing page layouts to content-only editing.
 */
function theme_register_landing_page_template(): void {
    $page_type_object = get_post_type_object('page');
    
    if (!$page_type_object) {
        return;
    }

    $page_type_object->template = array(
        array('my-theme/hero-banner', array()),
        array(
            'core/group',
            array('layout' => array('type' => 'constrained')),
            array(
                array('core/paragraph', array('placeholder' => 'Enter section introduction...')),
                array('core/columns', array('columns' => 3), array(
                    array('core/column', array(), array(array('core/heading', array('level' => 3, 'placeholder' => 'Feature Title')))),
                    array('core/column', array(), array(array('core/heading', array('level' => 3, 'placeholder' => 'Feature Title')))),
                    array('core/column', array(), array(array('core/heading', array('level' => 3, 'placeholder' => 'Feature Title')))),
                )),
            )
        ),
    );
}
add_action('init', 'theme_register_landing_page_template');

---

4. Advanced Template Hierarchy and Context Routing

The WordPress template hierarchy dictates which file renders a request. Understanding template priority and context isolation is the difference between clean architecture and fragile spaghetti code.

Request: /case-studies/project-alpha/
  |-- single-case-study-project-alpha.php (Custom slug template)
  |-- single-case-study.php (Post type template)
  |-- single.php (Generic single item)
  |-- singular.php (Generic single post or page)
  \-- index.php (Master fallback)

Passing Data Cleanly to Template Parts

Never rely on global variables (global $post;) to share custom data between your parent template and sub-components. Since WordPress 5.5, get_template_part() natively accepts an associative $args array:

Inside archive-case-study.php:

<?php
get_header();
?>

<main id="primary" class="site-main container">
    <header class="page-header">
        <h1 class="page-title"><?php post_type_archive_title(); ?></h1>
    </header>

    <?php if (have_posts()) : ?>
        <div class="case-studies-grid">
            <?php
            while (have_posts()) :
                the_post();

                $client_name = get_post_meta(get_the_ID(), '_case_study_client', true);
                $project_year = get_post_meta(get_the_ID(), '_case_study_year', true);

                get_template_part(
                    'template-parts/components/card',
                    'case-study',
                    array(
                        'post_id'      => get_the_ID(),
                        'client_name'  => $client_name ?: 'Confidential Client',
                        'project_year' => $project_year ?: date('Y'),
                        'show_badge'   => true,
                    )
                );
            endwhile;
            ?>
        </div>
        <?php the_posts_pagination(); ?>
    <?php else : ?>
        <?php get_template_part('template-parts/content', 'none'); ?>
    <?php endif; ?>
</main>

<?php
get_footer();

Inside template-parts/components/card-case-study.php:

<?php
/**
 * Case Study Card Component
 *
 * @var array $args Passed arguments from get_template_part().
 */

$post_id      = $args['post_id'] ?? get_the_ID();
$client_name  = $args['client_name'] ?? '';
$project_year = $args['project_year'] ?? '';
$show_badge   = $args['show_badge'] ?? false;
?>

<article id="post-<?php echo esc_attr($post_id); ?>" <?php post_class('case-study-card', $post_id); ?>>
    <?php if (has_post_thumbnail($post_id)) : ?>
        <div class="case-study-card__thumbnail">
            <a href="<?php echo esc_url(get_permalink($post_id)); ?>">
                <?php echo get_the_post_thumbnail($post_id, 'medium_large', array('loading' => 'lazy')); ?>
            </a>
            <?php if ($show_badge) : ?>
                <span class="case-study-card__badge"><?php echo esc_html($project_year); ?></span>
            <?php endif; ?>
        </div>
    <?php endif; ?>

    <div class="case-study-card__content">
        <p class="case-study-card__client"><?php echo esc_html($client_name); ?></p>
        <h2 class="case-study-card__title">
            <a href="<?php echo esc_url(get_permalink($post_id)); ?>">
                <?php echo esc_html(get_the_title($post_id)); ?>
            </a>
        </h2>
        <div class="case-study-card__excerpt">
            <?php echo wp_kses_post(get_the_excerpt($post_id)); ?>
        </div>
    </div>
</article>

This pattern encapsulates rendering logic, enforces strong output escaping, and eliminates variable leakage across loop iterations.

---

5. Modern Asset Pipelines with @wordpress/scripts

Gone are the days of manually downloading minified JS libraries and dumping them into an /assets/js/ folder. Modern WordPress engineering uses @wordpress/scripts, an officially maintained Webpack wrapper that handles ESNext compilation, JSX parsing, SCSS compilation, chunk hashing, and automatic asset dependency extraction.

Initializing the Build Environment

In your theme root directory, initialize your package.json:

{
  "name": "my-enterprise-theme",
  "version": "1.0.0",
  "description": "Production WordPress theme build configuration",
  "scripts": {
    "start": "wp-scripts start --webpack-src-dir=assets/src --output-path=assets/dist",
    "build": "wp-scripts build --webpack-src-dir=assets/src --output-path=assets/dist"
  },
  "devDependencies": {
    "@wordpress/scripts": "^27.0.0"
  }
}

When you run npm run build, Webpack compiles assets/src/js/main.js and assets/src/scss/main.scss into assets/dist/. Crucially, it also emits main.asset.php, which contains an array of detected dependencies (such as @wordpress/dom-ready or wp-element) and a cache-busting MD5 hash.

Enqueuing Assets with Modern Loading Strategies

In inc/assets.php, load assets using the auto-generated .asset.php file and WordPress 6.3’s modern strategy => 'defer' parameter:

<?php
/**
 * Enqueue theme styles and scripts.
 */
function theme_enqueue_scripts(): void {
    $theme_dir  = get_template_directory();
    $theme_uri  = get_template_directory_uri();
    $asset_file = $theme_dir . '/assets/dist/main.asset.php';

    // Fallback if build hasn't run yet
    $asset = file_exists($asset_file)
        ? require $asset_file
        : array('dependencies' => array(), 'version' => wp_get_theme()->get('Version'));

    // Main Stylesheet
    wp_enqueue_style(
        'theme-styles',
        $theme_uri . '/assets/dist/main.css',
        array(),
        $asset['version']
    );

    // Main JavaScript
    wp_enqueue_script(
        'theme-scripts',
        $theme_uri . '/assets/dist/main.js',
        $asset['dependencies'],
        $asset['version'],
        array(
            'strategy'  => 'defer',
            'in_footer' => true,
        )
    );

    // Pass runtime variables safely to client scripts
    wp_localize_script(
        'theme-scripts',
        'ThemeData',
        array(
            'rootUrl' => esc_url_raw(rest_url()),
            'nonce'   => wp_create_nonce('wp_rest'),
        )
    );
}
add_action('wp_enqueue_scripts', 'theme_enqueue_scripts');

By leveraging main.asset.php, your scripts are automatically cache-busted whenever the source files change without needing manual version bumps.

---

6. Custom Post Types, Taxonomies, and Clean Query Architecture

Enterprise themes frequently need bespoke content structures like Portfolios, Testimonials, or Case Studies.

Registering Custom Post Types with Block Editor Support

When registering custom post types, always enable show_in_rest => true to activate the Gutenberg block editor, and define standard REST base slugs:

<?php
/**
 * Register Case Study Custom Post Type.
 */
function theme_register_case_studies(): void {
    $labels = array(
        'name'               => _x('Case Studies', 'post type general name', 'my-theme'),
        'singular_name'      => _x('Case Study', 'post type singular name', 'my-theme'),
        'menu_name'          => _x('Case Studies', 'admin menu', 'my-theme'),
        'add_new_item'       => __('Add New Case Study', 'my-theme'),
        'edit_item'          => __('Edit Case Study', 'my-theme'),
        'all_items'          => __('All Case Studies', 'my-theme'),
    );

    $args = array(
        'labels'             => $labels,
        'public'             => true,
        'publicly_queryable' => true,
        'show_ui'            => true,
        'show_in_menu'       => true,
        'show_in_rest'       => true,
        'query_var'          => true,
        'rewrite'            => array('slug' => 'case-studies'),
        'capability_type'    => 'post',
        'has_archive'        => true,
        'hierarchical'       => false,
        'menu_position'      => 20,
        'menu_icon'          => 'dashicons-portfolio',
        'supports'           => array('title', 'editor', 'thumbnail', 'excerpt', 'custom-fields', 'revisions'),
    );

    register_post_type('case_study', $args);
}
add_action('init', 'theme_register_case_studies');

Modifying Queries with pre_get_posts (Never in Templates)

One of the most destructive mistakes developers make is altering archive queries inside template files using query_posts() or instantiating a new new WP_Query() in archive.php. This forces WordPress to run the default database query, discard the results, and execute a second query.

Always modify archive queries before they execute using the pre_get_posts action hook:

<?php
/**
 * Adjust archive queries safely without running duplicate SQL operations.
 */
function theme_modify_case_study_archive_query(WP_Query $query): void {
    // Only target main frontend queries for this post type archive
    if (is_admin() || !$query->is_main_query()) {
        return;
    }

    if ($query->is_post_type_archive('case_study')) {
        $query->set('posts_per_page', 12);
        $query->set('orderby', 'date');
        $query->set('order', 'DESC');
        $query->set('no_found_rows', false); // Ensure pagination calculation runs
    }
}
add_action('pre_get_posts', 'theme_modify_case_study_archive_query');

---

7. Production Performance Engineering and Optimization

High-performing WordPress themes do not happen by accident; they are engineered with strict database and asset constraints.

1. Eliminate N+1 Database Queries

When looping through posts, retrieving custom metadata or taxonomies inside the loop can trigger an N+1 query vulnerability if caching flags are improperly configured.

WordPress core automatically primes post metadata and term caches when executing WP_Query, provided you keep the default flags enabled:

<?php
$args = array(
    'post_type'              => 'case_study',
    'posts_per_page'         => 6,
    'no_found_rows'          => true, // Disables SQL_CALC_FOUND_ROWS when pagination is not needed
    'update_post_meta_cache' => true, // Loads all metadata for all 6 posts in 1 database query
    'update_post_term_cache' => true, // Loads all taxonomy terms in 1 database query
);

$case_studies_query = new WP_Query($args);

if ($case_studies_query->have_posts()) :
    while ($case_studies_query->have_posts()) :
        $case_studies_query->the_post();
        // get_post_meta() here hits memory cache, zero database queries triggered!
        $client = get_post_meta(get_the_ID(), '_case_study_client', true);
        ?>
        <div class="featured-study">
            <h3><?php the_title(); ?></h3>
            <p><?php echo esc_html($client); ?></p>
        </div>
        <?php
    endwhile;
    wp_reset_postdata(); // Essential: restore original global $post
endif;

2. Self-Host Web Fonts via theme.json

External font calls to Google Fonts or Typekit introduce render-blocking network requests and cross-origin DNS lookups. In theme.json, declare your custom web fonts locally:

{
  "settings": {
    "typography": {
      "fontFamilies": [
        {
          "fontFamily": "'Inter', sans-serif",
          "name": "Inter",
          "slug": "inter",
          "fontFace": [
            {
              "fontFamily": "Inter",
              "fontWeight": "400 700",
              "fontStyle": "normal",
              "fontDisplay": "swap",
              "src": ["file:./assets/fonts/inter-variable.woff2"]
            }
          ]
        }
      ]
    }
  }
}

WordPress automatically handles @font-face generation and serves font files directly from your server with optimal HTTP cache headers.

3. Caching Expensive Operations with the Transients API

If your theme performs expensive calculations, consumes remote REST APIs, or executes complex metadata aggregation, cache the output in object cache or transient storage:

<?php
/**
 * Retrieve aggregated portfolio statistics with transient caching.
 */
function theme_get_portfolio_stats(): array {
    $cache_key = 'theme_portfolio_aggregate_stats';
    $stats     = get_transient($cache_key);

    if (false === $stats) {
        // Expensive query or remote API request
        $stats = array(
            'total_clients'     => 142,
            'completed_projects' => 380,
            'active_industries' => 14,
        );

        // Cache for 12 hours
        set_transient($cache_key, $stats, 12 * HOUR_IN_SECONDS);
    }

    return $stats;
}

// Clear transient when a new case study is published
function theme_invalidate_portfolio_stats(): void {
    delete_transient('theme_portfolio_aggregate_stats');
}
add_action('save_post_case_study', 'theme_invalidate_portfolio_stats');

---

8. Senior Developer Quality and Security Checklist

Before shipping any custom theme to a staging or production environment, run through this verification checklist:

Security Hygiene

• Sanitization on Input: Sanitize all incoming user data (sanitize_text_field(), sanitize_key(), absint()).
• Validation: Check nonces with check_admin_referer() or wp_verify_nonce() before processing form submissions.
• Escaping on Output: Never echo unescaped variables.
  • esc_html(): For plain text strings.
  • esc_attr(): For HTML attributes like id or class.
  • esc_url(): For links and image sources.
  • wp_kses_post(): For strings containing safe HTML tags.

Debugging Configuration in wp-config.php

Enable logging during local theme development:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', true);
define('SAVEQUERIES', true);

Use the Query Monitor plugin to inspect total SQL query counts, memory utilization, hook execution order, and template part resolution paths on every page view.

---

Conclusion

Mastering WordPress theme development means treating the CMS as an enterprise application layer. By combining the stability of hybrid PHP templates, the structured design tokens of theme.json, the modular power of block patterns, and modern asset bundling via @wordpress/scripts, you can build themes that are fast, secure, and intuitive for content editors to use.

---

Changes

Pass	What changed	Examples
Structure	Replaced 35-line promotional stub with 8-part master architecture guide	Empty sales pitch -> Deep hybrid theme engineering breakdown
Inflation	Removed all marketing fluff and corporate spam	“bring your vision to life”, “stand out” -> deleted
Vocabulary	Stripped AI buzzwords and promotional sales jargon	“delve”, “journey”, “tapestry”, “stunning” -> deleted
Grammar	Enforced direct active voice and standard copula usage	“serves as an architecture” -> “is a disciplined practice”
Rhythm/Style	Varied sentence lengths with senior engineering commentary	“That approach worked in 2014.” “Keep your functions.php minimal.”
Hedging/Filler	Eliminated throat-clearing, generic intros, and contact URLs	Removed skrots.com links, CEO signature, and marketing pitches
Transitions	Connected technical topics through architectural logic	Modular progression from file hierarchy to caching
Soul	Injected real developer patterns and real-world gotchas	Added N+1 query prevention, theme.json lockouts, and @wordpress/scripts