Fix Font Awesome 6 loading Font Awesome 5 glyphs (blank X/Twitter icon) - #350
Merged
Conversation
…5 set
The X (Twitter) icon in the footer social links rendered as a blank gap. The
markup and the CSS were both correct -- <i class="fa-brands fa-x-twitter"> and
.fa-x-twitter:before{content:"\e61b"} -- and assets/css/fontawesome6/webfonts/
does contain U+E61B. The browser was simply never given that file.
assets/css/fontawesome6/all.min.css referenced its fonts as "../webfonts/".
From assets/css/fontawesome6/ that resolves to assets/css/webfonts/, which held
a Font Awesome *5.15.3* set left behind by an earlier upgrade. Confirmed on the
live demo, which requested:
/themes/shapely/assets/css/webfonts/fa-brands-400.woff2
with no request for the fontawesome6 copy at all. Measuring rendered ink in the
browser: facebook-f 548 px, linkedin-in 721, youtube 1249, instagram 759, the
retired twitter bird 894 -- and x-twitter 0.
So every icon whose codepoint already existed in 5.15.3 worked by coincidence,
and anything added afterwards was blank. In this theme that is fa-x-twitter and
fa-section; it would silently affect any FA6 icon added later too.
The 20 url() references now point at webfonts/, keeping the Font Awesome 6 6.4.2
directory self-contained. With the path corrected nothing referenced the old
Font Awesome 5 files at all, so they are removed: the release zip goes from
3.16 MB to 1.88 MB.
Folded into 1.2.21 rather than a new version, as 1.2.21 has not been published
to WordPress.org yet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…isitors
The enqueue passed Font Awesome's own '6.4.2' as $ver, so the URL is a constant
even when the file behind it changes. Combined with the cache-control this asset
is served under, that is a year-long lock:
cache-control: public, max-age=31536000, immutable
cf-cache-status: HIT
Deploying the corrected webfont path to the demo changed nothing for exactly
this reason -- the origin served webfonts/, and every edge and returning browser
kept serving ../webfonts/ from the immutable copy.
SHAPELY_VERSION changes on each release, which is precisely when the bundled
file can have changed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Folded into the unreleased 1.2.21.
The blank X (Twitter) icon
Reported on the demo: the footer social row showed a gap where X should be.
Everything looked right —
<i class="fa-brands fa-x-twitter">, the rule.fa-x-twitter:before{content:"\e61b"}, andassets/css/fontawesome6/webfonts/fa-brands-400.woff2genuinely contains U+E61B (verified with fontTools: 576 codepoints, "Font Awesome version: 6.4.2").
The browser was never given that file.
all.min.cssreferenced its fonts as../webfonts/, which fromassets/css/fontawesome6/resolves out toassets/css/webfonts/— a Font Awesome 5.15.3 set (462 codepoints) leftbehind by an earlier upgrade. The live demo requested:
and never requested the fontawesome6 copy at all.
Measured rendered ink in the browser, before:
So every icon whose codepoint already existed in 5.15.3 worked by coincidence.
Anything added later was blank —
fa-x-twitterandfa-sectiontoday, andsilently any FA6 icon added in future.
After: x-twitter 615, threads 701.
Changes
url()references now point atwebfonts/, keeping the 6.4.2 directory self-contained.SHAPELY_VERSIONinstead of the literal'6.4.2'.That last one mattered more than it looks. The asset is served
cache-control: public, max-age=31536000, immutable, and?ver=6.4.2neverchanges when the file does — so deploying the corrected path to the demo changed
nothing until the version string moved. A constant
$veron a mutable file is ayear-long lock on every edge and returning browser.
Verified on the live demo
Deployed to https://colorlibhub.com/shapely/ and re-checked: all five social
icons render, 5/5 pages pass with 0 blank icons, 0 broken images, 0 JS errors.