Fonts for non universal themes

[MaggieCabrera]

Thinking about updating the plugin to include non universal themes, the problem with choosing fonts for the theme comes to mind. Here's an idea:

On the form we can include the option to add a specific font, then generate a functions.php file that enqueues that. We would have to add that same font to the theme.json file we are generating too.

How many fonts can a user choose for a theme? How do we handle different weights/styles? Do we include the font files or do we use google fonts links?

[MaggieCabrera]

I'm thinking that maybe we want to include these fonts first, so that the experience of editing the templates and GS is consistent with the end result. But that will require some extra work so we don't enqueue every single font on the generated theme.

[scruffian]

On the form we can include the option to add a specific font, then generate a functions.php file that enqueues that. We would have to add that same font to the theme.json file we are generating too.

I think that's fine.

Do we need to give them a list of fonts to choose from? What if they just supply font files and a name, and we generate the code based on that?

[pbking]

I like the idea of being able to offer any of the fonts provided by Blockbase as font options by which to build derived themes. Leveraging the existing interface mechanisms (Customizer, FSE, Global Styles) to do the customizations rather than offering specific form items by the plugin sounds like the best mechanism to supply that customization (of all types) including the Font Selection.

If we're building a mechanism to supply fonts then I think it's something we should focus on building that in the FSE (or Blockbase perhaps as a stop-gap) to be leveraged by the plugin rather than adding in as functionality of the plugin itself.

[scruffian]

The benefit I see of putting it in a plugin is that it enables theme builders to create block themes easily before the tools are in Gutenberg.

[pbking]

The benefit I see of putting it in a plugin is that it enables theme builders to create block themes easily before the tools are in Gutenberg

Yea I (now) agree. @MaggieCabrera convinced that we should be building this out to be what we need today and expect Gutenberg/FSE to ultimately provide.

[MaggieCabrera]

we are aiming to expand on WordPress/gutenberg#36619 when we bring these functionalities to GB

[pbking]

I believe that handling fonts will ultimately need to be responsibility outside of the realm of this plugin. Other solutions (such as this JetPack solution) would work will with a workflow involving this plugin, but I don't believe that managing those fonts (or any details of a theme beyond the metadata at construction) should be this plugin's responsibility.

I suggest closing this in deference to the JetPack solution (or similar).

[MaggieCabrera]

I agree with that, but we should test how the jetpack solution interacts with the plugin. Not everyone has Jetpack installed and in our particular use case as theme devs we are mostly want to add the font files bundled in the theme so that they work on a .org environment, so we may need to do some extra leg work to get there.

I suggest we keep this open to decide how we want to approach that but without adding the overhead of handling the font options to the plugin. This can be done on a later version of the plugin as an enhancement.

[pbking]

This feels further and further from the realm of this plugin. There's too much complexity there and it will need to be handled well in some other area. I think for now manually handling fonts is our best bet. I'mma take this off of the project board but leave it open so that we can continue dialog here as needed.

[MaggieCabrera]

I think for the scope of the plugin what feels like a good idea right now is to add the option to upload fonts by the theme developer

[jffng]

Is this solved by #113 and subsequent work?

[mikachan]

Yeah, I think #113 addressed this, so I'll close this now.