Handle local fonts better with Features

There are two ways to move a local font from one server to another: 1) move your entire database and file system together or 2) re-add the font on the new server and re-apply the configurations. The Features export shouldn't be trying to export local fonts, since it can't export the files, the same reason we can't load from a theme.

What we might try is to enable exporting local fonts using Features, but add an extra check to see if the font files exist on the server. Would this be doable?

Yeah, that could work. I don't know if that's outside what people expect of Features, though, since it wouldn't necessarily work when enabled. I think maybe the general expectation of a Features export is it will just work when enabled. But I'm not sure.

I'm wondering if, when exported as a feature, the feature could get all packaged up with the font - the feature implementation provides its path to the fonts which local fonts could then make the appropriate connection to (right now, local fonts only checks against the upload directory so updating that could be a nicety). I hope that made sense - I'm doing something very similar with webfont loader (though it doesn't use features) if you want to look at how it looks for paths.

Some research on this:

Our ability to stuff the feature with font files would depend on #1064340: Allow export of additional files/assets. which does not seem to be going anywhere (no activity for more than a year).

A workaround could be shamelessly grabbing files from the original site; this would introduce a requirement for the original site to be online - a bit weird but not insane. This could be facilitated by #1796736: Get URL of font files stored locally via fontyourface_get_fonts which was originally unrelated.

First attempt at it. (It sort of works, but I'm unsure about error handling - should those be sent to the screen or watchdog)

Requires the patch in #1796736: Get URL of font files stored locally via fontyourface_get_fonts to be applied first.

Small issue:

    $stream_wrappers = file_get_stream_wrappers();
    if($stream_wrappers['public']) {
      $scheme = 'public';
    }

This is currently inside the font loop, but it should be exactly the same every time, so I think it should be moved before the loop. Also, needs a space after if.

Beyond that, I feel like there should be a warning somewhere in the feature export process that this will only work if the source of the feature is online, since that's not how Features exports normally work. But I don't know where that somewhere would be. Probably not a good idea to directly alter the Features UI, since that's in the middle of changing right now, and Features doesn't seem to have a way to provide notes on exports.

Shouldn't the warning be on import?

The worst that can happen is probably the warning getting lost if Features interface changes.

Another attempt at a patch attached.

I am trying to export 4 local fonts with our university installation. The fonts live in sites/all/libraries/fontyourface. The idea is to bundle the font configs with our out of the box features so any site can use the fonts without having to add anything to their own theme. I'd like to always source the font from sites/all/libraries/fontyourface. Is this a possibility? I tested this patch but it looks like it just picks up the paths of already uploaded fonts. Thanks.

vinmassaro, Features currently doesn't have any way to bundle files with the font, so what this patch does is include a path to the original server where the feature was generated, and then download the files from there when the feature is enabled. This requires the generating server to be publicly accessible when you enable the feature, but otherwise, it should result in something similar to what you're describing. It's as close as we can get right now, until #1064340: Allow export of additional files/assets. is resolved in Features.

What about being able to point at sites/all/libraries? I don't really want to bundle the fonts with the feature, I just want to point to them in the same location. This will be in a Drupal install for a few hundred university sites.

Support for sites/all/someplace has been discussed before - #1825494: Consider "sites/all/fonts" folder support, or Libraries API support with Fonts sub-folder - but we were generally skeptical of the idea. Fonts are more than just files, and nobody has yet proposed a good way to keep files and db in sync and prevent sites from interfering with each other.

I'm going to give this another round of thought over the weekend, but can't really promise an eureka. :)

vinmassaro, could your same location be sites/default/files or is that not an option with your setup? If that's an option, this may just be a matter of checking if the files are already there before downloading them.

I'd forgotten #1825494: Consider "sites/all/fonts" folder support, or Libraries API support with Fonts sub-folder and thinking about that again in the context of the current patch makes me wonder if we're doing too much here. Maybe instead of automatically downloading the files, we should just be informing the site builder of where we're looking for the files (which could be multiple locations, including sites/all/libraries) and suggesting possible download links (i.e. the origin server for now, maybe something like fontserv.com in the future). That would put more work on the site builder to get the files in the right place, but it's the kind of work site builders are already doing with a lot of 3rd party JS. And it would have the benefit of increased flexibility in how the files get where they belong. For example, if you want to keep your dev site offline and move the files with git or scp or whatever, that would still be an option.

+1 this is really what I am looking for. The idea for us in our university installation is that most sites will use our included theme, but others may use their own custom theme. We'd rather have the font available for all to use via FontYourFace than having to manually add it to your theme.

Back to me. Actually, had I read #2 carefully, I'd probably seen the light sooner.

@ Drave Robber: any update on this? Thanks.

My plan was to approach this during the Next Big Push, which unfortunately hasn't materialized yet - mostly because there are already 13 issues needing review.

If you (or someone else reading this) can help getting that number down to something less obscene, it would be... well, just great.

@Drave Robber: I'll try to take a look at some of those issues, and test your patches. Thanks!

Might this whole idea work better if you worked with System Stream Wrapper and/or Remote Stream Wrapper instead of trying to reference the old site?

For others trying to find a good solution to this problem, here's a patch-less solution: have your .install file copy the files over for you on install. Features will preserve the .install file and the subdirectory where you store your fonts, so you can put these here safely. For the sake of this example I put mine in "your_feature/local_fonts/YourFont-normal-normal". Here's the code to put in your .install file:

/**
 * Implements hook_install().
 */
function your_feature_install() {
  // List of all font files to copy.
  $fonts = array(
    'YourFont-normal-normal' => array(
      'YourFont-Regular.woff',
      'YourFont-Regular.ttf',
      'stylesheet.css',
    ),
  );
  // Define common directories.
  $module_path = drupal_get_path('module', 'your_feature');
  $local_fonts_directory = dirname($_SERVER['SCRIPT_FILENAME']) . '/' . file_stream_wrapper_get_instance_by_scheme('public')->getDirectoryPath() . '/fontyourface/local_fonts';

  // Create local font directory if it doesn't already exist.
  file_prepare_directory($local_fonts_directory, FILE_CREATE_DIRECTORY);

  // Copy all files into the public file directory.
  foreach ($fonts as $folder => $filenames) {
    foreach ($filenames as $filename) {
      // Define and create our destination directory.
      $destination_directory = $local_fonts_directory . '/' . $folder;
      file_prepare_directory($destination_directory, FILE_CREATE_DIRECTORY);

      // Build file object and copy the file.
      $filepath = "$module_path/local_fonts/$folder/$filename";
      $file = new stdClass();
      $file->filename = $filename;
      $file->filepath = $filepath;
      $file->filemime = file_get_mimetype($filepath);
      $file->filesize = filesize($filepath);
      $file->uid = 1;
      $file->status = FILE_STATUS_PERMANENT;
      $file->uri = $filepath;
      $file->display = 1;
      $file->description = '';
      $file = file_copy($file, "public://fontyourface/local_fonts/$folder/$filename", FILE_EXISTS_REPLACE);
    }
  }
}

Thanks @chromix, that's great.

A small note on #21 - this will fail if you enable your module via drush.

To fix this I changed

$local_fonts_directory = dirname($_SERVER['SCRIPT_FILENAME']) . '/' . file_stream_wrapper_get_instance_by_scheme('public')->getDirectoryPath() . '/fontyourface/local_fonts';

to

$local_fonts_directory = file_stream_wrapper_get_instance_by_scheme('public')->getDirectoryPath() . '/fontyourface/local_fonts';