Syntax error on referenced fonts with multiple font-family items

As a work-around, you could remove the quotes from line 572 of fontyourface.module. Those quotes are necessary for some fonts, but not for Typekit. As a full fix, we'll need to treat Typekit a little differently. I think it's the only provider that uses multiple family names for the same font.

This should probably be higher than minor priority, even with a work-around.

Marked #1659508: Typekit & Version 2.3 as a duplicate of this.

Thank you, removing the single quotes on line 572 fixed the problem.

I couldn't quite reproduce the issue at hand as I could not find any such fonts in the trial version of Typekit (how does one recognize them - or am I missing something?), but the patch attached should deal with it.

A downside of this approach is that we're passing a sort of half-baked string to another module - these things easily break when something changes at one or another end. (That's why I at least added a comment.)

An alternative would trying to explode/re-implode the string in fontyourface.module (on condition of $font->provider == 'typekit_api'), but that would fly even worse. See, font-family: 'Boom, bang!'; is actually a valid declaration, and even if Typekit doesn't use anything like that now, we'd need to account for all possibilities and let loose a hungry regexp or two, which wouldn't help performance at all.

We're currently saving valid font-family strings and making them invalid on output (for Typekit). Saving invalid strings and making them valid on output will fix the immediate problem, but seems likely to introduce new problems in the future (with anything else that uses those string), and fixing those problems with invalid strings in the database sounds like a problem worth trying to avoid. I think instead we should focus on making the output smarter.

I think originally the output didn't add quotes at all and relied on the provider to add the quotes. That was probably a better approach, but not practical to go back to that now. We could do a more targeted step back toward that. Rather than adding a Typekit-specific exception, we could add exceptions that look at the string itself. Specifically, if a string already starts with a quote, we shouldn't be adding new quotes. If we add that condition on output, then we just need to add a start and end quotes to your patch, and we'll have valid strings in both the database and output.

Am I missing anything?

Makes sense. I'll roll a new patch.

(Blame my general disbelief in existence of 'third ways')

This patch implements sreynen's suggestions from #7.

This is committed.

I changed if (strpos("'", $font->css_family) === 0) { to if ($font->css_family[0] === "'") { which should be a bit faster as it doesn't need to search through the whole string.

Note: to fix this problem on an install that already has Typekit fonts imported, you'll need to re-import Typekit after updating the code.