Only re-write font.css when CSS changes

This should happen in 7.x-2.x now.

Marked #1571002: performance problem when using Amazon S3 storage as a duplicate of this. Since that's causing actual problems, changing this to a bug.

I hadn't looked at that previously, but I just looked at it now. I think you're right that it could handle the writing and reading of CSS for us. Unfortunately it doesn't handle detecting changes in CSS, which is the big thing we're currently missing. It would have been good to use that when we started, but I'm not eager to add a new dependency now just to offload functionality we've already written.

I think what we need to do here is move the CSS re-writing to a function, and call that function whenever a font is changed in any way (enabling, disabling, changing selectors, etc.). The trick will be tracking down everywhere we're changing fonts.

Good idea tracking changes based on the actual file content, BarisW. I changed this a bit so it saves MD5 hashes of the CSS it writes, so it can compare the MD5 hash to see if there's a change and no longer needs to read the file. I think this should be faster, though I didn't do any formal testing.

I also split up the functionality in separate functions, fontyourface_generate_css() and fontyourface_rewrite_css(), so we could eventually trigger rewrites from somewhere other than fontyourface_preprocess_page(), e.g. when a font is enabled or on cache clear.

While there's still more we could do here, it's likely to be very small improvements (e.g. removing a variable) relative to what we've already done (removing unnecessary file writes). So I'm marking this as fixed and we can do more in separate issues.

This stil needs to be ported to D6. Should be pretty similar to the D7 version, which can be seen here:

http://drupalcode.org/project/fontyourface.git/commit/0779ceb

To be clearer, I'm not planning on writing the D6 change myself, as D6 is basically in maintenance mode now and it still works even without this fix. But I will commit a patch if someone else wants to write it.

There were two patches here, one that changed from always-write to always-read, then another that switched to hash comparison. So the current D7 code, which should form the basis of a D6 patch, determines if a write is necessary by saving a hash of the previous write, and only writing when the hash changes. This means one write for all changes between page loads, no writes on no changes, and no reads.

I said in #8 that we might move to a rewrite-on-change model in a separate issue, but after thinking about that more, I think it's actually a bad approach, with a lot of drawbacks and little real benefit.

There's no single change event we could use to trigger a re-write. Enabling and disabling fonts is a change, but changing selectors and fallback fonts is as well. In some cases, those changes happen individually, so we'd want the individual change to trigger the re-write, while in other changes they happen in bulk, so we wouldn't want to trigger a series of re-writes on each individual change. And because the preview pages need to load fonts that aren't enabled, moving to an on-change re-write approach would force us to use a completely separate method of loading those fonts.

And all of that additional complication would really only save us some simple string comparison, which is very fast. We'd still need to check which fonts are enabled on every page load, since we need to pass that info to the provider submodules.

So I think we should stick with the current D7 approach.

That's a good point on potential conflicting writes. I opened a separate issue for it: #1655066: Two users editing fonts at the same time could cause conflicting writes to fonts.css