[wp-trac] [WordPress Trac] #25085: Twenty Fourteen: Fix Genericons Loading
noreply at wordpress.org
Fri Sep 13 02:03:06 UTC 2013
#25085: Twenty Fourteen: Fix Genericons Loading
Reporter: celloexpressions | Owner: lancewillett
Type: defect (bug) | Status: reopened
Priority: normal | Milestone: 3.8
Component: Bundled Theme | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch |
Comment (by celloexpressions):
Replying to [comment:6 lancewillett]:
> In [changeset:"25417"]:
> #!CommitTicketReference repository="" revision="25417"
> Twenty Fourteen: prefix Genericons enqueue handle so that the theme uses
the its own version of the font CSS. Fixes a few display issues when
plugins like Jetpack enqueue a different version of Genericons. See
The purpose of this ticket is specifically '''NOT''' to do that. If we use
a different handle, then we're only trying to step around the problem
instead of actually fixing it. Using different handles, multiple versions
of Genericons will load (bad for performance) and they will likely
conflict with each other. Keep in mind that it's very possible that
multiple plugins will load Genericons; sites could quite easily get to the
point of having three or more versions of Genericons loading, which is
just bad all around.
If we absolutely must load our own specific version of Genericons, the css
and font-family name should ALL be prefixed to avoid conflicts. That's
also a bad idea, of course, as it makes updates unwieldly.
The only big problem with the raw Genericons css is that it adds styles to
`.genericon` instead of `.genericon:before`, which is why Twenty Fourteen
can get pretty nasty with that (see [attachment:twenty-fourteen-
genericons-2.09-from-plugin.png]). @obenland, did Joen have a reason for
doing that, or was it accidental and forgotten to be fixed (see [comment:1
comment 1])? If that's staying, we should adjust our uses of those classes
in Twenty Fourteen so that we can use the bundled css.
More broadly, this is really demonstrating that we need Genericons
packaged in core (#24864). Having a canonical version would solve all of
the problems we're having and make it significantly easier to use them in
plugins. There are a lot of arguments that have been made both ways (I
summarized them in the most recent comment), but I think that needs
serious consideration. We would look at it from the perspective that we're
using Dashicons for wp-admin, but those are admin-specific; Genericons are
available for front-end uses by both themes and plugins because they're
generic and there's interest in having an easily-accessible icon font for
Otherwise, we need to figure out a better way to make Genericons tenable
for use in both themes and plugins. We should really never load them more
than once, but perhaps the only commonly loaded css should define the
fonts themselves and everything else should be left to the specific
implementation. There also needs to be some sort of a better mechanism for
updates; the only big problem with different versions is the addition of
new icons in new versions, but I don't think we need to worry about
updates breaking things unless the bundled css is significantly changed.
With that, all we need is to make `wp_enqueue_style` do a version-compare
if multiple copies of the same item are enqueued.
We should probably update Twenty Thirteen to Genericons 3.0 also. And note
that it uses `wp_enqueue_style('genericons'` to play nicely.
I'll also point out that Jetpack caused all of the issues by loading a
different piece of css from everyone else, but since we don't have a
standard (which could be documented on Genericons.com), that's excusable.
But [http://plugins.trac.wordpress.org/changeset/770391 that caused the
Genericon'd plugin to switch from doing-it-right as well].
At the moment, if a site were to run Twenty Fourteen, Jetpack, my
QuickShare plugin, and Genericon'd (if they wanted the shortcodes, for
example), '''four''' different versions of Genericons would be loaded.
That's not an unlikely set of plugins. And for the record, things still
break in Twenty Fourteen in that scenario, even after . The only
thing that that fixed was the fact that Jetpack didn't load the bundled
genericons.css file with its `wp_enqueue_style` call.
Ticket URL: <http://core.trac.wordpress.org/ticket/25085#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac