Developer guidesEasy SVG Pro developer reference

Easy SVG Pro developer reference

What developers can build on in Easy SVG Pro: hooks, the register function, Twig helpers, WP-CLI, the licence constant, and how features are switched on.

API status

Live uptime of the Updates, Downloads, Composer and Account APIs. Check here first when an update or a Composer install fails.

Easy SVG Pro is the agency layer on top of the free Easy SVG Support plugin: unlimited icon collections, icon sets, theme and folder sources, packs, WP-CLI, the SVG cleaner and integrations with page builders and field plugins. For developers it offers a small set of promised entry points, plus a larger set of internal ones you can read about but should not build on. This page explains which is which, how the licence and the feature switches decide what runs, and how to read the reference pages.

What you can build on

What is promised to stay

The plugin's readme has a section "For developers: the hooks", and the WP-CLI commands are named in its description. That is the line this reference follows.

StatusWhat it coversWhat it means for you
StableThe hooks named in the readme, easy_svg_register_icon_collection(), the three Twig helpers, the seven WP-CLI commands and EASY_SVG_PRO_LICENSE_KEYNames and behaviour stay. Build on these.
InternalEverything else: the REST routes, the abilities, the remaining filters (easy_svg_pro_parse_manifest, easy_svg_pro_collection_icons, the source caps), options, post meta, the feature flags' storage and every namespaced functionDocumented so you understand the plugin. They can change in any release.

The readme is explicit about one family: the functions in includes/core/integration.php (the integration_ and icon_field_ functions) "exist; they are not promised".

Internal functions live in the namespace UWP\EasySvgPro. A rename does not raise an error in your code: function_exists() simply turns false and your feature quietly stops. Prefer the stable entry points, and when you must use an internal one, check for it every time.

Licence and feature switches

Two things decide whether a Pro surface is there: the site is activated with a licence, and the feature is switched on.

The licence. Activate the site under Icons → License, with your UnleashWP account or a licence key. Without an active licence the Pro features stay off.

The feature switches. Every Pro feature is off by default, even on a licensed site, and is switched on under Icons → Features. Sanitizing and hardening are not a switch; they always run.

The switches that decide whether a developer surface exists:

Switch (Icons → Features)KeyWhat it turns on for developers
Theme & folder sourcessourcesassets/icons, drop-in folders, easy_svg_register_icon_collection() and the source filters
Multiple collectionscollectionsHanding collections to the core Icon block, easy_svg_pro_registered_icon
Icon set editoreditorThe easy_svg_set post type, sets as collections, the set routes, the set screen redirect
WP-CLIcliEvery wp easy-svg subcommand
AI agent abilitiesabilitiesThe four abilities (the set abilities also need Icon set editor)
Timber / TwigtwigThe three Twig helpers
Preset icon setspresetsThe preset catalogue and its two filters
Icon historyhistoryRevisions for sets, hooked to easy_svg_pro_set_icons_written

The configurator and its filters (easy_svg_pro_dangerous_tags, easy_svg_pro_dangerous_attrs) need only the licence, not a switch. The import caps apply on every import path, whichever switch opened it. EASY_SVG_PRO_LICENSE_KEY and the Licence tab work on unlicensed sites, because that is how a site gets licensed.

There is no promised function to ask whether a switch is on. Write code that degrades: check function_exists() for what you call, and treat an empty icon or an empty list as "not available here".

Requirements

NeedsVersion
WordPress6.6 or newer
PHP8.2 or newer
Easy SVG Support4.3 or newer; bulk renaming in the free library and styles in the Icon block need 5.3.3
Core Icon block with Pro collectionsWordPress 7.1 (the icon registry)
AbilitiesWordPress 6.9 (the Abilities API)
Timber helpersTimber 1 (tested with 1.23.1) or Timber 2

When things run

Most Pro surfaces are wired on init. If your code depends on them, the order matters.

Hook and priorityWhat happens
plugins_loadedPro starts; a notice appears when the site is not activated
init 8The easy_svg_set post type is registered (Icon set editor)
init 9Published sets, the theme folder and drop-in folders fill the collection registry
init 10The free library registers; call easy_svg_register_icon_collection() here
init 11The registry is handed to the core Icon block (easy_svg_pro_registered_icon runs)
init 20Icon history, block bindings and patterns
timber/twigThe Twig helpers are added
wp_abilities_api_initThe abilities are registered

How to read a reference page

Every hand written item page has the same sections, in the same order:

  1. Header line: the kind (Filter, Action, Function, Twig function, WP-CLI command, Constant), the product and the status.
  2. A short plain introduction.
  3. Usage: the exact signature or synopsis, and where it is applied.
  4. When to use it: real situations, and when to reach for something else.
  5. Parameters: what each argument holds.
  6. Return value: what your callback must return, or what the command prints and its exit code.
  7. Default: the value when nobody changes anything.
  8. Examples: a basic case, a realistic agency case, and a defensive one that checks for the plugin first.
  9. How it works: what the code really does, in which order, behind which licence and switch, and what is cached.
  10. Pitfalls: mistakes taken from the code, with security notes in red boxes.
  11. Related: the neighbouring items and tutorials.

Pages for internal items are generated from the code and are shorter. They tell you what exists; they do not promise it stays.

Tutorials

All stable items

Sources and collections

Icon block

Presets

Import

Configurator

Sets

Twig

Constants

WP-CLI