# Hands-on With the WordPress 7.1 Icon Registration API > [!question] Lingering Questions > - Does `wp_register_icon()` interact with block theme `theme.json` declaratively, or is registration PHP-only in 7.1? > - Is there a `wp_unregister_icon()` (or equivalent) for a plugin that needs to remove or override a previously registered icon? > [!tip] Article Ideas > - The backed-enum-vs-array pattern shown here is worth its own short piece independent of icons — a general "closed registry, PHP 8.1+" writeup that could reference this tutorial as the worked example. > [!link] Cross Reference > - [[3. Resources/Literature Notes/Registering and Rendering SVG Icons in WordPress 7.1]] — the core dev note this tutorial builds on; that note covers the registry/sanitization mechanics, this one covers the applied build-along and the enum pattern > [!quote] Vocabulary > - **Backed enum** — a PHP 8.1+ enum whose cases are bound to scalar values (here, strings), letting each case carry methods (`label()`, `handle()`, `filePath()`) while remaining a real, IDE-autocompletable type rather than a bare string ## Bib capsule WordPress.org Developer Blog, "Hands-on With the WordPress 7.1 Icon Registration API" (2026-08-18): <https://developer.wordpress.org/news/2026/08/hands-on-with-the-wordpress-7-1-icon-registration-api/> ## Author's thesis (Q1+Q2) WordPress 7.1 finally gives developers a public way to register custom icons for the Icon block, closing a gap left when the block shipped in 7.0 with a fixed, closed set. The tutorial's real contribution isn't the two-function registration API itself but the pattern it demonstrates for organizing the data behind it: a PHP 8.1 backed enum with per-case `label()`, `handle()`, and `filePath()` methods stands in for what would otherwise be an array of magic strings, trading a silent-typo failure mode for one PHP and the IDE can catch before runtime. The piece stays honest about what's unfinished — a restricted SVG allowlist, stripped `stroke` attributes, no editor component for embedding icons in other blocks yet. ## Key arguments (≤3) 1. The Icon block shipped in 7.0 without a registration API; 7.1's `wp_register_icon_collection()` / `wp_register_icon()` closes that gap on the standard `init`-hook pattern. 2. A backed enum with per-case methods is a strictly safer way to represent a closed registry (icons, but generalizable) than an array of string keys, because PHP and IDEs can check it statically instead of failing silently at runtime. 3. The API's stated 7.1 limitations — narrow SVG element allowlist, stripped `stroke`, no cross-block editor component — are named as deliberate sequencing (sanitizer work must land first) rather than oversights. ## Claim atoms ### Backed enums beat arrays for closed, type-checked registries > [!quote] ID:rw_atom1 > Icon::Cake is a real, checkable type that PHP validates and IDEs can autocomplete, whereas an array key like $icons['cake'] is just a string a typo and can silently break with no error until runtime. Where/why: the article's core architectural argument for the example plugin's design — general PHP practice, not WordPress-specific. ### The Icon block shipped in 7.0 with no registration API > [!quote] ID:rw_atom2 > When WordPress 7.0 launched the Icon block earlier this year, it was one of the most exciting moments I'd felt in a while. But it was also a bit of a letdown because there was no public API for registering custom icons. Where/why: sets up the article's premise — the concrete gap 7.1's new API closes, a release later. ### SVG sanitization gaps limit the API's element allowlist today > [!quote] ID:rw_atom3 > Currently, only <svg>, <path>, and <polygon> are allowed elements for an SVG icon. Everything else is stripped out. Part of this is because WordPress does not yet have a formal function for sanitizing SVGs. Where/why: the biggest stated 7.1 limitation, framed as deliberate safety-gating rather than an oversight. ## Permanent candidates - **New**: a closed registry gains compile/static-analysis-time typo and unhandled-case detection when modeled as a PHP backed enum instead of an array — checked the vault for existing coverage (backed enums, type-safe registries, static checking) and found none; the adjacent registry notes ([[3. Resources/Permanent Notes/Namespaced Registries Let Extensions Share Assets Without Sharing Ownership]], [[3. Resources/Permanent Notes/Registration Success Does Not Guarantee Render Success Under Lazy Loading]]) are about registry *sharing* and *lazy-load timing*, not type-safety of the data representation itself — promoted below as [[3. Resources/Permanent Notes/A Backed Enum Makes a Closed Registry Statically Checkable Where an Array Cannot]] ## Processing checklist - [x] Checked for existing Literature Note — none found for this exact tutorial; found and cross-referenced the companion core dev note it's built on ([[3. Resources/Literature Notes/Registering and Rendering SVG Icons in WordPress 7.1]]) - [x] Checked for existing Permanent Notes — no existing note covers backed-enum-vs-array type safety; nearest neighbors (namespaced registry sharing, lazy-load render timing) are distinct claims, not duplicates - [x] Connected into no MOC — this is a self-contained technical tutorial; none of the candidate MOCs (WordPress Hosting Security Stack, DevRel, Personal Knowledge Management) are a genuine fit for either the enum-practice atom or the registration-API atom ## Links - [[3. Resources/Permanent Notes/A Backed Enum Makes a Closed Registry Statically Checkable Where an Array Cannot]] — because it is the Permanent claim drawn from this tutorial's enum-over-array argument. - [[3. Resources/MOCs/WordPress Platform Design MOC]] — because a registration API with a closed type set is a platform-design decision about what extenders may declare. - [[3. Resources/Permanent Notes/Registration Success Does Not Guarantee Render Success Under Lazy Loading]] — because both concern registries in WordPress 7.x, one about how entries are typed and the other about when a registered entry actually renders.