Why is Font Awesome so very old in Zammad

Technical assistance
1

Infos:

  • Used Zammad version: 7.0.3
  • Used Zammad installation type: package
  • Operating system: Ubuntu 24.04
  • Browser + version: Microsoft Edge

Hey,

we are using the Knowledge Base for our information pool. The icons for the categories are displayed by font awesome. Some icons are not present, because the version is 4.7 in Zammad (latest ist 7.3.1 by the way) and too old. The icons are exists since version 6 or later.

Is there a reason for the very old and not maintained version? How can I get a new icon? Is there a way to update this package to 7.3.1?

Thanks!

2

I’m seeing the same limitation with the available Knowledge Base icons on 7.0.3, so the Font Awesome 4.7 bundle is a real constraint rather than just a browser rendering issue. An upgrade path or documented way to register newer icons would make this much easier to manage.

3

I can’t recall what the response was when I noted that a year or two ago… it’s been too much and long. By now the migration path to a new FA version might be a bit painful.

But help me to understand please. You’re saying that not all icons are displayed? Are you trying to set non existing ones in FA4.x or what are you doing? Because all icons Zammad allows you to select in the UI should (ideally ;D) be there and available.

4

Hey,

thanks for your reply.
I need two icons which I’ve found on awesomes website but I cant find it in zammad because the old version. The icons are published in v5. So the gap is here the problem :blush: an update would fix the problem.

The only thing what is changed is the code for the icon like fa-icon is now fas fa-icon and so on

5

Okay but intermediately no broken icons, but “just” missing ones you’d like to use?

6

I’ve had Claude cycle through this. Thought about “just bumping it” but… honestly the answer doesn’t exactly find my liking. I’ll refrain from doing it, because I expect that the woff variant will be phased out (which technically makes sense) and that’s a bit too much of fishing in the dark for my taste.

My guess is that this kind of PR wouldn’t be accepted.

Just for reference Claudes response for whoever is interested. (I explicitely pointed out Fontawesome, but didn’t restrict it to it, so Claude expects to touch all icon bases which, honestly, should be done)

Microwaved content

  1. Legacy font-glyph icon sets — this is where FontAwesome 4.7 lives

    FontAwesome isn’t a package dependency at all (no npm/bower entry) — it’s vendored as raw static assets: public/assets/icon-fonts/FontAwesome.woff (110KB, 675 glyphs) + a .json glyph-metadata file. The version is hardcoded as a string in
    app/assets/javascripts/app/lib/app_post/iconset_picker.coffee:4-7:

    FontAwesome:
  version: '4.7'
  website: 'https://fontawesome.com/v4.7.0/'

    It’s injected at runtime via JS (App.Utils.loadIconFont in utils.coffee), which appends a block with a @font-face pointing at the .woff, then renders glyphs as &#xF1XX; using Unicode code points — not FontAwesome’s official .fa fa-* CSS classes at all (zero hits for that pattern repo-wide).

    This mechanism is scoped entirely to Knowledge Base categories. Four other font sets ship alongside it the same way: anticon, material, ionicons, Simple-Line-Icons — a KB picks one iconset, and each KnowledgeBase::Category stores a category_icon column that’s actually a hex Unicode code point (e.g. ‘f115’), not a class name. Admins pick it via App.IconPicker/App.IconsetPicker (CoffeeScript components), and it’s rendered server-side for the public KB via _icon_from_set.html.erb.

  2. Legacy general-purpose SVG sprite

    Everything else in the old CoffeeScript app (ticket priority icons, buttons, sidebars) uses App.Utils.icon() → an inline <svg><use xlink:href="#icon-name"/></svg> against a separate sprite (public/assets/images/icons.svg), built via a Gulp pipeline. Unrelated to FontAwesome.

  3. New Vue 3 frontend

    CommonIcon.vue uses its own build-time SVG-symbol sprite (Vite plugin + svgo), sourced mostly from Bootstrap Icons — no FontAwesome involvement whatsoever.

The migration gap

A very recent commit (9159d8f253, “Browse knowledge base categories and answers”) adds a Vue CategoryCard.vue that fetches categoryIcon over GraphQL but doesn’t render it — it’s hardcoded to a generic folder icon with the comment // set default icon for now. This is the exact unbridged seam: the legacy FontAwesome-glyph category_icon values (Unicode code points tied to a specific font/version) have no defined mapping into the new SVG icon-name space yet.

No upgrade plans found

No CHANGELOG, BREAKING_CHANGES, or doc/ mentions of upgrading FontAwesome or migrating the iconset system — the version-4.7 pin appears to just be legacy/unmaintained since the org’s real investment has shifted to the Bootstrap-Icons-based Vue sprite system.

Practical implication: if you want to modernize category icons, the work isn’t “bump FontAwesome” — it’s deciding how to remap ~675 possible legacy Unicode glyphs (across 5 font families) to the new SVG icon set, or introduce a compatibility shim, since the two icon spaces don’t overlap in naming or lookup mechanism at all.