Loading, licences and filters

The stylesheet is not loaded on pages without icons#

This is the reason the plugin exists. The official Font Awesome plugin — 400,000 installs, 3.6 stars — enqueues its stylesheet on every page of the site. Your home page, your checkout and your privacy policy each make a render-blocking request and download a webfont for an icon that is in the footer of one post.

Here, at wp_enqueue_scripts — which runs before wp_head, so the stylesheet lands in the head rather than flashing the icons in after paint — the plugin looks at:

• the post being shown, and every post in an archive or search result
• block widgets and classic text widgets
• menu items with an icon chosen for them

for a [dicon shortcode, a wp:devix/icon block, or a bare dxi- class — the last because a theme may write the class itself and that has to work too.

If none of those turn anything up, nothing is enqueued at all.

There is a test for the decision, in both directions: a page with an icon must load it, and a page whose content merely mentions the word "dicons" must not.

When the scan cannot see#

A page builder that stores icons in its own data has no content for us to read. Either tick Load the stylesheet on every page in Settings → Dicons, or:

add_filter( 'devix_dicons_load', '__return_true' );

It takes null to mean "decide normally", so it can also be conditional:

add_filter( 'devix_dicons_load', function ( $load ) {
    return is_page( 'pricing' ) ? true : $load;
} );

And from a template, at any point:

DevixDicons\Assets::enqueue();

A shortcode or block that renders after the scan asks for the stylesheet itself, so an icon inside something unusual still appears — just later in the document than it would have.

Nothing is shipped#

The plugin is a few kilobytes of PHP. The icons are a subsetted webfont served from the Devix CDN, so a page downloads the families and weights it uses and nothing else.

There is no SVG in this plugin, and a test asserts that none ever appears in the output. That is both how the subsetting works and why the plugin cannot leak an icon set.

The consequence, stated plainly: this needs the CDN. A site that has to serve every asset from its own origin is not the customer for it.

Licences#

Settings → Dicons, paste the key. It is checked against the CDN rather than trusted, and the answer is cached for an hour.

A key that cannot be checked keeps working. If the CDN is unreachable the plugin assumes the key is good, because a site losing its icons over a momentary network problem is a worse failure than a lapsed key working for another hour.

Changing the key clears the cached icon list, so the picker refills with whatever the new key allows.

Filters#

What it stores#

One option, and one meta value per menu item that has an icon. Two transients cache the icon list and the licence answer. Uninstalling removes all of it; there is no table, because there is nothing worth keeping.