Dicons for WordPress
Dicons as a block and a shortcode.
wp plugin install devix-dicons --activate
Live demo coming soon
The official Font Awesome plugin has 400,000 installs and 3.6 stars: sixteen of its sixty-one reviews are one star, more than its four- and three-star reviews put together, and every other icon plugin on WordPress.org rates 4.5 or better. The one everybody installs is the one nobody likes, and the reason is that an icon plugin loads its stylesheet on every page of the site — a render-blocking request and a webfont download on the home page, the checkout and the privacy policy, for an icon that is in the footer of one post. This one decides before wp_head, by reading the post, the posts in an archive, the block and text widgets and the menu items: a page with no icon on it loads nothing at all, and there is a test for the decision in both directions. Nothing is shipped either — the plugin is a few kilobytes of PHP and the icons are a subsetted webfont from the CDN, so a page downloads the weights it uses and no more. There is no SVG in the plugin at all, and a test asserts none ever reaches the output. The free set needs no account, no API key and no kit.
What you get
Nothing loads on a page with no icon
The decision is made at wp_enqueue_scripts, which runs before wp_head — so the stylesheet lands in the head rather than in the footer, where it would flash the icons in after paint. A page with none loads nothing at all.
It looks everywhere an icon can be
The post, every post in an archive or search result, block widgets, classic text widgets, menu items — and a bare dxi- class, because a theme may write it itself and that has to work too. There is a test for the decision in both directions.
There is no artwork in the plugin
A few kilobytes of PHP. The icons are a subsetted webfont from the Devix CDN, so a page downloads the families and weights it uses and no more. A test asserts that no SVG ever reaches the output — which is how the subsetting works, and why this plugin cannot leak an icon set.
No account for the free set
No API key, no kit, no sign-up — the step that turns a five-minute job into an afternoon with the incumbent. Install it and the Icon block is there. A licence key unlocks the rest, and is checked against the CDN rather than trusted.
A block, a shortcode, a function and menu icons
All four produce the same element, so an icon placed by an editor and one written into a theme are the same thing on the page. And you do not need a second plugin for menu icons.
Hidden or named, per icon
An icon beside the word Home must be hidden, because a screen reader saying 'home home' is worse than saying nothing. One alone in a toolbar needs a name. Both are right, so it is a choice you make per icon rather than a setting.
The block renders in PHP
An icon inserted today comes out with whatever class names the current release uses, rather than the markup being frozen into a thousand posts. An icon set versioned on a CDN cannot afford saved markup.
A lapsed check does not take your icons away
The licence answer is cached for an hour, and if the CDN cannot be reached the key keeps working. A site losing its icons over a momentary network problem is a worse failure than a lapsed key lasting another hour.
Dicons for WordPress — overview
The one everybody installs is the one nobody likes
| Installs | Rating | |
|---|---|---|
| font-awesome (official) | 400,000 | 3.6 ★ |
| menu-icons | 100,000 | 4.9 ★ |
| advanced-custom-fields-font-awesome | 90,000 | 4.9 ★ |
| better-font-awesome | 60,000 | 4.5 ★ |
| icon-block | 40,000 | 5.0 ★ |
Sixty-one reviews, and sixteen of them are one star — more than its four-star and three-star reviews put together. Its support forum shows one thread resolved out of four. Every other icon plugin on that list rates 4.5 or better.
Why an icon plugin gets disliked
It loads its stylesheet on every page of the site.
That is a render-blocking request and a webfont download on the home page, the blog index, the checkout and the privacy policy — for an icon that appears in the footer of one post. On a site where performance is measured, an icon plugin is one of the first things blamed, and usually correctly.
The second thing is weight. A plugin that ships SVG sprites ships megabytes; one that ships a whole icon font ships hundreds of kilobytes, and a visitor downloads all of it to see three icons.
What this does instead
It decides before wp_head. At wp_enqueue_scripts the plugin reads the
post being shown, every post in an archive, block and text widgets, and menu
items, looking for a [dicon shortcode, a wp:devix/icon block, or a bare
dxi- class — that last one because a theme may write the class itself. Finding
none, it enqueues nothing at all.
Before wp_head matters: a stylesheet enqueued later lands in the footer and the
icons flash in after the page has painted, which is a worse experience than
loading it everywhere.
There is a test for the decision in both directions — a page containing an icon must load it, and a page whose prose merely mentions the word "dicons" must not.
Nothing is shipped. The plugin is a few kilobytes of PHP. The icons are a subsetted webfont from the Devix CDN, so a page downloads the families and weights it uses and no more. There is no SVG anywhere in the plugin, and a test asserts none ever reaches the output — which is both how the subsetting works and why this plugin cannot leak an icon set.
No account for the free tier. No API key, no kit, no sign-up — which is the step that turns a five-minute job into an afternoon with the incumbent. A licence key in the settings unlocks the rest, and is checked against the CDN rather than trusted.
A block, a shortcode, a template function and menu icons, all producing the same element — so an icon placed by an editor and one written into a theme are the same thing on the page.
A small decision worth stating
An icon is aria-hidden unless you give it a label, in which case it becomes
role="img" with that name.
Both are right, and which is right depends on the icon: one sitting beside the word "Home" must be hidden, because a screen reader announcing "home home" is worse than announcing nothing, and one standing alone in a toolbar must have a name. Making it a per-icon choice rather than a global setting is the only way to get both.
What we do not claim
That Font Awesome is a worse icon set. It is enormous, it is free, and for many sites it is the right answer. What is compared here is the plugin, which its own users rate 3.6.
That this works offline. It is a CDN runtime by design. A site that must serve every asset from its own origin should not install it.
How it compares
Questions
Why is the official Font Awesome plugin rated 3.6?
Sixty-one reviews, sixteen of them one star — more than its four- and three-star reviews combined — and one support thread resolved out of four. Every other icon plugin on WordPress.org rates 4.5 or better. We are not comparing icon sets here: Font Awesome is enormous and free and for many sites the right answer. We are comparing the plugin, which its own users rate.
Does it work offline, or on an intranet?
No, and it says so plainly. It is a CDN runtime by design — that is how a page gets only the weights it uses and how licensed sets are honoured. A site that must serve every asset from its own origin is not the customer for this.
My page builder draws icons and they are not appearing
The scan reads post content, widgets and menus; a builder that keeps icons in its own data has nothing for it to read. Tick 'Load the stylesheet on every page' in Settings, or add_filter('devix_dicons_load', '__return_true'), or call DevixDicons\Assets::enqueue() from your template.
Is any SVG included in the plugin?
None. What goes on the page is a class name, and the glyphs come from a webfont. There is a test asserting that no <svg>, no <path> and no path data ever appears in the output.
What does it leave behind if I uninstall it?
Nothing. One option, one meta value per menu item that had an icon, and two transients — all removed on uninstall. There is no database table, because there is nothing worth keeping.