When setting up fonts on a local dev and syncing my updates up to dev, stage, and prod, all font displays need to be manually re-saved in-order-to bring the fonts onto the local filesystem.

I wouldn't expect this manual step, unless I am just not doing something I am supposed to be doing when importing fontyourface configuration.

All I would expect to do when importing configuration is:

  1. drush config-import

What I need to do with the current version of fontyourface is:

  1. drush config-import
  2. navigate to appearance > fonts > Settings > Import all fonts
  3. navigate to appearance > fonts > Font Display
    1. Open every font display and re-save every font display

Comments

frob created an issue. See original summary.

philosurfer’s picture

philosurfer CreditAttribution: philosurfer commented

dumping the table: fontyourface_font
And then trying to import fails as well because of the entity UUID.

I think we need a faster way of importing the data. This is getting painful to manage on large multisite platforms.

BTMash’s picture

BTMash CreditAttribution: BTMash as a volunteer commented
Assigned: Unassigned » BTMash

Thinking through this, there needs to be another config entity for when fonts get enabled so the enabled fonts can be imported. I have some ideas around it though its going to take some time.

If someone has something already working, feel free to unassign me from it.

philosurfer’s picture

philosurfer CreditAttribution: philosurfer commented

Ok,

So we have a default config for the module that gets loaded during a site install and preset fonts are selected. In order to get around the very long google fonts API import via the UI, which tends to timeout (in ajax), just keep a site install with the font dB loaded and just sql-dump
eg.
drush @source.env sql-dump --tables-list=fontyourface_font | drush @self sqlq;

frob’s picture

frob
Primary language English
CreditAttribution: frob at Clarity Innovations, Inc. commented

@philosurfer, are you suggesting that as a possible workflow. As a rule, any workflow which requires a user to touch the db directly (even via drush sql-dump) shouldn't be considered user friendly enough.

philosurfer’s picture

philosurfer CreditAttribution: philosurfer commented

I guess I am suggesting a Drush plugin that allows us to do 2 things:

1- kick off import jobs to queue api and then run the queue (negating the possibility for AJAX timeouts that can occur with large datasets like Google fonts)
2- Allow us to export and import large tables to JSON files so we can add to a repo and speed up site provisions that require this table to be populated. Drastically lowering the overhead for getting a working site up and running that has this module as a dependency (from 3+ minutes to less than 2 seconds with sql import!)

Currently, I have kludgely solved this by adding a class to our provision library that executes the drush command listed above. But this requires a source to be working and populated with latest font library data. Not terrible, but not ideal either. I cannot always expect our dev/build environments to have access to a remote Drupal instance.

I will add the above tasks to our backlog and try and get a patch out in the coming weeks.

frob’s picture

frob
Primary language English
CreditAttribution: frob at Clarity Innovations, Inc. commented

Why not just create config entities like BTMash was talking about instead of doing a bunch of DB dump stuff. This is D8 none of this should be this hard.

Not saying the drush plugin is a bad idea, it would be great for moving config from dev->stage prod->dev but that is also what the config management system is for. I don't see the need to reinvent the wheel.

philosurfer’s picture

philosurfer CreditAttribution: philosurfer commented

I guess my only argument is that this is not really config... It is entity data. (content)

ecj’s picture

ecj CreditAttribution: ecj commented

Hello!

Does anyone have a solution yet (temporary or in code/patches/drush)? I tried the @philosurfer method, but doesnt work for me :(.. what exactly in the code needs to be done/kicked/refreshed ? Anybody any idea what works?

dahousecat’s picture

dahousecat CreditAttribution: dahousecat commented

Just dumping the fontyourface_font table to an sql file and then importing that after drush si works for me.

// dump the table
mysqldump drupal fontyourface_font -u drupal -pdrupal -h mariadb --no-create-info > fontyourface_font.sql

// setup the site
drush si your_profile
`$drush sql-connect` < your_path/fontyourface_font.sql
liquidcms’s picture

liquidcms CreditAttribution: liquidcms commented

Can someone explain the reasoning behind importing 16k fonts when i only want 1? Is this simply to have the font selector that shows samples of each font (why would i need that?).

This doesnt seem to be a deployable/kube workable solution as this will need to be done every build. The theme (non Drupal) people on my project want to just include the file by adding it to the html.tpl. At first this module seemed like a better way to manage this; but now not sure if there is no way to deploy this.

Is the only thing required for deployment this table? When i first deploy i see this as well in the page head:

<link rel="stylesheet" media="all" href="/sites/default/files/fontyourface/font_display/primary_font_family.css?rhhluw" />

but this is 404.