Page MenuHomePhabricator

Refreshed skin doesn't automatically include WikiFont git submodule
Closed, DeclinedPublic


The Refreshed skin doesn't include the WikiFont git submodule in it's own repository source code. It's a necessary code dependency, and causes the skin to break (result in a ton of PHP errors) without the WikiFont project. There are 3 solutions so far:

  1. Make Refreshed fail gracefully without WikiFont icons
  2. Tell other people in MediaWiki documentation that they must install WikiFont also and give a sensible PHP error that detects with a simple if/else statement checking whether or not WikiFont exists
  3. Find a way to get WikiFont to be automatically downloaded with Refreshed
  4. Get WikiFont to be pre-installed within the MediaWiki core

I'm not sure how the process for number 4 would work (I remember seeing a page on but can't seem to find it). Anyone know the chance of this one happening?

Original author: MtMNC @MtMNC
Original posted date: June 16th, 2015
Original title: WikiFont not included in Refreshed ZIP Download
Original comments and issue at Github:

Event Timeline

@Volker_E @Quiddity Thoughts on figuring out how to include the WikiFont module? It was originally included in the repo source code at GitHub but not included in the ZIP download, now it's not in the code at all :(

MacFan4000 changed the task status from Open to Stalled.Jul 11 2016, 4:58 PM
MacFan4000 triaged this task as Medium priority.
MacFan4000 edited subscribers, added: MacFan4000; removed: Zppix.
ashley added a subscriber: ashley.

I'm no git guru, so I'm not able to fix this (at least in an elegant way). I think we'd need to include the submodule somehow, but if that's not possible, we can always add something like this into or somesuch:

if ( !file_exists( $wgStylePath . '/Refreshed/refreshed/wikifont/wikiglyphs.css' ) ) {
	die( 'This is where we show a nice and informative message to the end-user informing them about what they need to do to initialize WikiFont...' );

Maybe it could degrade to FontAwesome? What do you guys think?

@SamanthaNguyen I think that may be more trouble than it's worth. It'd require a new font and quite a bit of PHP changes to create icons for what's just a fallback.

That said, maybe if we get more consistent with versioning Refreshed (and creating branches for each release), we could put the current version of WikiFont in each releases's files. So the WikiFont for 4.0.0 would be the current version as of then, then 5.0.0 would have a newer version, etc.

Yeah that makes sense, which means option 1 isn't very plausible. So I shall ask the following person...

@Volker_E Do you have experience with developing skins, and if so would you know whether or not if 3 would be possible? Could you also figure out whether or not if number 4 on the list here would happen any time soon or if you could make it happen? I have no idea whether or not you have core rights (but I suspect you do since you work with WMF officially, right?) Just wondering, thanks! :D

Edit: I'd just like to point out that number 2 just feels like the lazy work around, maybe that's just me though. Thoughts?

Maybe a warning isn't the most elegant solution, but it's better than the alternative of no warning that we have currently. Another thing to consider is that the people installing skins on MediaWiki are probably people comfortable with a couple of extra installation steps.

@SamanthaNguyen I'm not quite sure if I understand the proposed options thoroughly. What do you want to have in Refreshed? Always the latest Github font files (.eot, .svg, .ttf, .woff, .woff2) directly pointing to the github repo?
Is it for the sake of being up-to-date with latest glyphs?
I'm not quite sure if that's needed, I'd probably just include the font files in your skin and update it from version to version of your skin…

Right, I'm closing this as DECLINED. Installing WikiFont only takes a few steps. :)

I'm not quite sure if that's needed, I'd probably just include the font files in your skin and update it from version to version of your skin…

There is some follow up in that sense on T154806. The CI / Jenkins job is breaking because it does not process submodules. So maybe embedding the fonts directly in the font will fix both the build and people installing from a zip file not having the submodule :]