Only show fonts on the default theme

I think there are simpler ways to solve this without adding new code: Use a separate admin theme, add a unique body class to the non-admin theme, and prefix all your selectors with that class. You could also strip the CSS back out in your theme's page preprocess. Lastly, you might consider paying Fontdeck. :)

With these alternatives, I'm not inclined to add this functionality. If you think I'm missing something, please don't hesitate to re-open the issue.

I believe that this request goes one step too short. I would argue that adding a usability layer where this theme has profiles, then for each profile putting in a selector of some sort (checkboxes probably) to indicate which themes this profile should/shouldn't apply to is the way to go. This is going to be a theme-dependent module - it adds fonts for a certain look of a site, and to assume that for all possible themes on the site and also the admin interface, the same font applications are called for is really missing the mark.

Making everything in the module optionally theme-specific will involve changing a lot of code, which probably won't happen until the Drupal 8 version. Of course, if anyone wants to write the Drupal 7 code for this, patches welcome.

Alternately it could be a separate module ( fontyourface_profiles or similar). I haven't looked at the code architecture for fontyourface but perhaps the fontyourface_profiles module could hook into fontyourface and modify its behavior per-theme, if hooks are provided and such.

Before moving to D8, can we consider only loading the fonts on the default theme?
We could also add this as a setting too, in the admin interface ("Load fonts on all themes?").

The first could be done easily, see patch.

Makes sense and has good cost/benefit ratio. Works to the effect advertised, too.

However, ability to change this from admin interface is a must, and default setting must be to continue loading fonts in all themes. Otherwise, the update would remove fonts for sites that have admin backends beautified (yes, people do that*). Would you want to explain to a client where did all the eye-candy go?

* here's an example: just today, someone was looking for a "colorable admin theme" on the forum; Seven is gray and boring, mind you. :)

Yeah, that definitely sounds like a simple-enough change for D7. I think it needs to default to the current behavior, at least on existing installs, so upgrading doesn't cause fonts to disappear. So maybe a checkbox in the config for "only apply fonts to default theme" and apply the code in #6 when that box is checked. Or we could set the box to auto-checked and do a hook_update_N() to uncheck it for existing installs, if people think that's worth doing.

Patch follows.

I've renamed the Logging fieldset to Advanced to make space for the extra textbox.

Forgot to clean-up the variable in the hook_uninstall.

(ignore this :)
I wonder if we can somehow (and whether we should) get the checkbox on admin/appearance/fontyourface instead of admin/config/user-interface/fontyourface - this seems more related to application of fonts than to configuration of providers.

(status was changed due to cross-post)

I'd suggest to refine wording a bit to explain what happens if this is touched, for example:

        '#title' => t('Load fonts in all themes, including admin themes'),
        '#description' => t('If unchecked, fonts will be loaded only in default theme.'),

That's where you native English speaking people need to jump in ;)

Done.

This looks good to me. I was thinking we'd need to set the variable with hook_update_N(), but just making the default TRUE in variable_get() is much simpler.

Committed.

Y'all are awesome!

@hermes_costell: the original issue has been fixed, but you might want to open a new issue about 'profiles'.

TBH, I'm a bit skeptical as to whether there is any real demand for such advanced features. The dominant mode d'emploi seems to be 'fire-and-forget'. I already burned my fingers with #1820954: Review Live webfont preview module for potential inclusion - invested quite a lot of time only to find out no one is interested in it.

Oh man - I hear you! The prospect of spending hours (days) for $0 making something hardly anyone ever uses isn't exactly inviting. :)

It seems like currently the only way to gauge community interest in module development is to see how many people "+1" a feature request in the issue queue. I'd imagine it would be useful to have a feedback system of some kind for module developers to help them get a sense of which feature requests are popular.

Maybe something like a "send the module maintainers feedback" section where users can help module maintainers know why they used their module over others that may be similar, or alternately why they skipped over the module in favor of another one (because it's missing some critical feature), suggest combining their functionality with another module, or simply give an easy interface for "I would also like this feature" when a feature is requested by another user.

Ha. We just broke all font previews (well, almost all - not for FontSquirrel and not for those users who do not use a separate admin theme). But admin/appearance/fontyourface/browse/* by default uses Seven, and I reckon most users leave it at that.

The caveat here is we must not write CSS, but still do $vars['fontyourface'] = $fonts; - so we are exiting early.

I'll post a patch shortly. (edit: erm, not so quick. This approach in turn is sort of incompatible with Fonts.com)

Well, need to think about this. Alternatively, we could just add a warning about this. (Default setting is displaying in all themes anyway)

Let's leave this alone and open a follow-up issue.

#1913976: Missing font preview potentially confusing