Typography and Fonts

settings.typography also holds the editor switches covered in theme.json Settings: customFontSize, dropCap, fontStyle, fontWeight, letterSpacing, lineHeight, textColumns, textDecoration, textTransform and writingMode (appearanceTools turns on the ones that default to off).

With the theme active, wp_print_font_faces() prints two rules, and the family values become preset custom properties in the global stylesheet:

Source: Code Reference: wp_print_font_faces()

Source: Code Reference: WP_Font_Face_Resolver

The URLs are http:// because WP-CLI has no HTTPS request to detect; in a page served over HTTPS, is_ssl() is true and the same rules use https://lumenpress.test/.... The system-stack family prints no rule.

wp_print_font_faces() reads theme.json, so a classic theme that ships one (such as a hybrid lumen-classic) gets the same output by declaring fontFamilies there. Without theme.json, a classic theme enqueues a stylesheet with its own @font-face rules (see functions.php, Theme Supports and Assets). Either way the files ship inside the theme.

defaultFontSizes (theme.json version 3 default true) controls whether core’s own size presets (small, medium, large, x-large, xx-large) are output. Since version 3 a theme preset with a core slug no longer replaces core’s when defaultFontSizes is true; Lumen sets it to false so that its four sizes are the only ones and keep core’s slugs, which keeps content portable between themes.

wp_get_typography_font_size_value() turns a preset (or any array( 'size' => ... )) into the value WordPress outputs. A short wp eval prints it for Lumen’s presets and for three ad hoc sizes, as if an editor had typed them in a block’s typography panel:

Source: WordPress 7.1.3: wp-includes/block-supports/typography.php

Source: WordPress 7.1.3: wp-includes/block-supports/typography.php

The same strings appear as --wp--preset--font-size--{slug} custom properties in the global stylesheet. These functions have no Code Reference page; the source file above is the authoritative description.

The function wp_get_computed_fluid_typography_value() builds:

Source: WordPress 7.1.3: wp-includes/block-supports/typography.php

All lengths are first converted to the unit of the minimum size (1rem = 16px for the conversion), and min_rem is the minimum expressed in rem. Since 1vw is one hundredth of the viewport width W, the middle term equals min + (W − vw_min) × (max − min) / (vw_max − vw_min): a straight line that passes through min at vw_min and through max at vw_max. clamp() holds the value at the bounds outside that range. Starting the line from a rem value keeps the text responsive to browser zoom and to the user’s default font size, which a pure vw size would ignore (WCAG 1.4.4, Resize Text).

For Lumen’s x-large preset (3rem, no explicit minimum), step by step:

The other rows follow the same rules:

Pitfalls: units other than px, rem and em (such as pt, % or a calc() value) are returned unchanged; minViewportWidth equal to maxViewportWidth disables the calculation; and a wideSize in % or vw cannot be used as the maximum viewport, so the 1600px default applies. Setting maxViewportWidth explicitly avoids depending on the layout width.

Deleting a family deletes its faces, and deleting a face deletes its files (_wp_before_delete_font_face()). Font posts belong to the site, not to the theme: they survive a theme switch and are not part of a theme export.

Every route requires edit_theme_options; an anonymous request gets 401 rest_cannot_read. The following session installs Inter (rsms/inter 4.1, OFL, InterVariable.woff2 from its GitHub release) as a user font, authenticated with an application password stored in WP_APP_PASSWORD (application passwords need HTTPS, or WP_ENVIRONMENT_TYPE set to local, as explained in REST API: Using It):

Source: WordPress 7.1.3: class-wp-rest-font-faces-controller.php

The responses, without their _links:

Source: WordPress 7.1.3: class-wp-rest-font-families-controller.php

The stored rows and file:

Source: WP-CLI: wp post list

Source: Code Reference: wp_get_font_dir()

At this point wp_print_font_faces() still prints only the two Source Serif rules: Inter is installed, not active. The Fonts screen activates it by writing the family into the user’s global styles, which the same REST API does with POST /wp/v2/global-styles/<id> (the id of the theme’s wp_global_styles post) and this body, which also uses Inter for headings:

Source: REST API Handbook: Global Styles

Afterwards the front page’s <head> carries a third rule, with the default font-display: fallback because the face has no fontDisplay:

Source: Code Reference: wp_print_font_faces()

Errors met on the way, as returned by 7.1.3:

Font names are sanitized on the way in: a fontFamily of Source Serif 4 is stored as "Source Serif 4", quoted because of the spaces.

A font collection is a catalogue shown on the Install Fonts tab. Core registers one, google-fonts, whose catalogue is a JSON file on s.w.org (google-fonts-with-preview.json for 7.1). Plugins add their own with wp_register_font_collection() and remove one with wp_unregister_font_collection(), both on init.

Installing from Google Fonts is opt-in. The tab first asks for permission to connect to Google’s servers (stored in the browser, revocable from the tab’s menu). After that, the administrator’s browser downloads the chosen files from Google and uploads them to /wp/v2/font-families/<id>/font-faces, exactly like the Inter upload above. Visitors receive the files from the site’s own domain and never contact Google.

That is the correction to older books, Pro WordPress in particular, which load Google Fonts by enqueueing a fonts.googleapis.com stylesheet. Loading from the CDN sends every visitor’s IP address and user agent to a third party, which under the GDPR needs a legal basis and usually a consent banner; it also adds a DNS lookup and a connection to another origin before text can render. Self-hosting (bundled fontFace files in the theme, or the Font Library) removes both problems. Google Fonts files are under the OFL or the Apache License, so redistributing them inside a theme is allowed; for the Lumen theme they are taken from the font project’s own release rather than from the Google Fonts API, which serves subsets tuned per browser.

On production, Lumen Press lets only the theme decide which fonts exist. A must-use plugin removes the Google Fonts collection and hides the Font Library UI in the editors:

Source: Make WordPress Core: New Feature: Font Library

Saved as wp-content/mu-plugins/lumen-fonts-policy.php, GET /wp/v2/font-collections returns [] and the editor settings carry fontLibraryEnabled: false. The filter hides the Font Library inside the editors only; the REST routes and Appearance > Fonts remain for users with edit_theme_options. To close the API as well, the 6.5 dev note sets show_in_rest to false for wp_font_family and wp_font_face through register_post_type_args, and removes the /wp/v2/font-collections routes with rest_endpoints.

Fonts are writable even when DISALLOW_FILE_MODS is true, because the files go to the uploads directory like media. Uploaded font files are binary data that the browser parses, so only trusted administrators should hold edit_theme_options; see Security Hardening.