Opened 11 years ago
Closed 11 years ago
#25391 closed defect (bug) (fixed)
Twenty Thirteen: Standardize And Update Genericons
Reported by: | celloexpressions | Owned by: | lancewillett |
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 3.6 |
Component: | Bundled Theme | Keywords: | has-patch |
Focuses: | Cc: |
Description
Since Genericons updates are backwards-compatible, there is no reason that we shouldn't update the version of Genericons packaged with Twenty Thirteen (and eventually Fourteen), just like plugins are doing. Including an old version could eventually break plugins using Genericons (unless version comparison for enqueuing styles is added to core), if Twenty Thirteen's version wins out in the loading process and is missing ore recent changes that the plugin requires. While this scenario is not particularly concerning in the short term (ie, we don't need to worry about the frequency of updates), it will become much more of a problem if we never update Genericons in themes and plugins.
In addition to updating to version 3.0 (which should be a no-brainer), we should standardize the bundled css to the version packaged with Genericons, which is the standard way of loading them as documented in #24864. The issue is the [class*="genericon"]
selector, which should just be .genericon
(the directory structure of Genericons bundled with Thirteen should also be standardized to facilitate easier updates). It's been mentioned that that selector can cause a lot of problems in WordPress anyway. Making this change could very well break child themes (Twenty Thirteen itself doesn't use the helper css, and its use is discouraged), but the issue is that they're already broken even if they don't know it. If a plugin's version of genericons.css
is loaded instead of Twenty Thirteen's, the child theme will break (at the fault of Twenty Thirteen).
The only way to make theme-plugin-child-theme interactions work consistently well is to make sure they're all using the same Genericons base css, and until that happens, things will be broken in the wild (which they are currently). It's too bad that we might break child themers' code (which is already broken in certain environments) because we were doing it wrong, but the best solution at this point is to fix the source of the problem so that the problem doesn't continue escalating.
Attachments (4)
Change History (10)
#2
@
11 years ago
- Keywords needs-patch added
If we can do all those changes without breaking things, go for it. I think a patch would be good to have though.
@
11 years ago
Full patch to update to Genericons 3.0.3 and match the directory structure used in Twenty Fourteen for easier updating.
#4
@
11 years ago
- Keywords has-patch added; needs-patch removed
Not sure if the full patch worked, so I broke out the functions.php changes as well. The other changes are to delete the fonts/
directory and to add a genericons/
directory containing the contents of Genericons 3.0.3. As with Twenty Fourteen, we should just keep the contents of that directory a complete copy of the Genericons package.
None of the child themes in the .org repo touch anything related to Genericons, and these updates don't require changing anything in the theme itself. It's possible that this could break other custom implementations or plugins, but plugins need to load their own version of genericons anyway, which is likely updated with some frequency. And, as mentioned previously, this fix is the only way to ensure that there are minimal plugin/theme conflicts long-term.
We should work out a plan for how to update genericons in Twenty Thirteen and Fourteen each time the themes are updated and there's a new version of Genericons.
I'm not including a patch because of the previous issues with patching Genericons. Committer just needs to download Genericons 3.0 and replace the contents of
wp-content/themes/twentythirteen/fonts
with the contents of the zip. Could also delete license.txt and example.html from that zip if/hopefully when we decide to move forward with this.