functions.php, Theme Supports and Assets

$content_width is a global, in pixels, that tells WordPress the maximum width of the content column. Core reads it in two places: oEmbed (wp_embed_defaults() sizes YouTube and other embeds to it) and the editor, where large images inserted into the content are constrained to it (image_constrain_size_for_editor()). Setting it through a filterable function rather than a bare $content_width = 680; at file level lets a child theme or plugin change it.

A theme with a theme.json does not need the global: settings.layout.contentSize plays the same role and also generates the layout CSS. The block theme lumen uses 680px there for the same column.

post-thumbnails support enables the Featured Image panel. Passing an array of post types restricts it, which is why lumen-classic lists lp_book explicitly: a theme that supports thumbnails only for post hides the panel on books, however the plugin registered the post type (the post type also needs thumbnail in its supports).

Sizes are generated when an image is uploaded. Images uploaded before the theme was activated do not have the new sizes until they are regenerated with wp media regenerate (WP-CLI) or a plugin. Every registered size costs disk space and upload time for every image, so a theme registers only the sizes its templates print. Responsive images (srcset), the big-image threshold and the core sizes are covered in Media Library and Images and Media API.

add_editor_style() registers a stylesheet, relative to the theme folder, for the editor; editor-styles support is what makes the block editor actually load it. The block editor rewrites the selectors so they apply only to the editing canvas (body becomes .editor-styles-wrapper), so the file targets plain elements and the theme’s own classes, never editor class names:

Source: Block Editor Handbook: Theme Support

Since 7.1 the post editor is always iframed: add_editor_style() files and enqueue_block_assets styles load inside the iframe, while admin_enqueue_scripts CSS stays outside it. wp_enqueue_block_style() attaches per-block CSS that loads only where the block appears.

With block-template-parts, lumen-classic keeps its footer as block markup in parts/footer.html and prints it from PHP, so an editor can change the footer in the Site Editor without touching the theme:

Source: Code Reference: block_template_part()

Source: Code Reference: block_template_part()

The Site Editor opens in a template-parts-only mode for such themes: parts can be edited, but not created or deleted. Going further (block templates, theme.json) is the hybrid path described in Hybrid Themes and Migration to Block Themes.

The site used below is the standard local stack with lumen-classic active and a stand-in registration of lp_book (the real one lives in the lumen-catalog plugin; see Custom Post Types and Taxonomies). The Compose file is the one from Themes Overview; other setups are in Local Development Environments.

WP-CLI loads the active theme, so after_setup_theme has run when wp eval executes:

Source: Code Reference: get_theme_support()

What the output shows:

The registered sizes, including the theme’s two:

Source: Code Reference: wp_get_registered_image_subsizes()

wp_enqueue_style( $handle, $src, $deps, $ver, $media ) and wp_enqueue_script( $handle, $src, $deps, $ver, $args ) share their first four parameters. wp_register_style() and wp_register_script() take the same ones and only make the handle known; a later wp_enqueue_*( $handle ) or a dependency on it prints the file.

Source: Theme Handbook: Including Assets

lumen_classic_asset_version() uses filemtime() on the file that get_theme_file_path() resolves, so the URL changes whenever the file changes, without bumping the theme version on every edit. It falls back to the theme version if the file is missing. On servers that deploy every file with the same timestamp (some container images and release tools do), the modification time stops changing and the theme version is the safer choice; build tools that write a content hash (such as the index.asset.php files generated by @wordpress/scripts for blocks) are better still. The main style.css keeps the theme version from its header, so its handle matches what Child Themes expects.

A plain <script src> in the <head> blocks HTML parsing until it has downloaded and run, which is why older themes moved every script to the footer. Since 6.3 a script can ask for a loading strategy instead:

The strategy is a request. WordPress computes an eligible strategy from the dependency tree so that execution order is never broken: a delayed script must have only delayed dependents, and a script is never upgraded from defer to async. Four variations on lumen-classic-navigation were enqueued from a must-use test plugin to see what core prints:

Source: Make WordPress Core: Registering scripts with async and defer attributes in WordPress 6.3

The resulting tags (URLs shortened to the file name):

Data a script needs before it runs (configuration, a REST nonce for a script that calls the API) is therefore passed with wp_add_inline_script( $handle, $code, 'before' ) or wp_localize_script(), both of which print before the file and keep it deferred. Since 6.5, JavaScript modules have their own API (wp_register_script_module(), wp_enqueue_script_module()), which prints type="module" scripts, deferred by nature; the Interactivity API uses it.

wp_add_inline_style( $handle, $css ) prints CSS in a <style id="<handle>-inline-css"> element right after the handle’s stylesheet. lumen-classic uses it to turn an accent colour stored as a theme modification into a CSS custom property. The value comes from the database, so it is validated with sanitize_hex_color(), which returns an empty value for anything that is not a #rgb or #rrggbb colour, before it is concatenated into CSS. The function returns false and prints nothing if the handle is not registered, and passing a string that contains </style> triggers a "called incorrectly" notice: the $css argument is the CSS only, without tags. How the accent setting is registered and sanitised in the Customizer is shown in Customizer API.

lumen-classic-reading-time is enqueued only on single book pages (is_singular( 'lp_book' )): conditional tags work inside wp_enqueue_scripts because the main query has run by then. Its JavaScript uses wp.i18n from the wp-i18n dependency, and wp_set_script_translations() loads the theme’s JSON translations for it (see Internationalization):

Source: Plugin Handbook: How to Internationalize Your Plugin

comment-reply is a core script, registered but not enqueued; themes enqueue it only on singular views with threaded comments open. Other bundled libraries (jquery, wp-api-fetch, wp-dom-ready) are used through their handles too, never through a copy shipped in the theme or loaded from a CDN. jQuery runs in noConflict mode, so code that uses it wraps itself: jQuery( function ( $ ) { … } );.