The code that adds vars to the asset files to force refreshing (known hence-forth in this post as the assetFile system) of them needs two things fixed and I'll do both shortly.
One of these things is that updating the CSS fields in the Options table doesn't register as a change to the assetFile system. So my question is: Does anyone see a use for having a updated field on the Option table?
If it's something that'll get used by anyone else than I'll do it that way, otherwise I'll just let the assetFile system store a hash of the fields in a hidden option and compare that instead of an updated timestamp.
I just don't want to bloat the table with an extra field of nobody will ever use it, nor do I want to end up with several plugins using the hash method either.
The code that adds vars to the asset files to force refreshing (known hence-forth in this post as the assetFile system) of them needs two things fixed and I'll do both shortly.
One of these things is that updating the CSS fields in the Options table doesn't register as a change to the assetFile system. So my question is: Does anyone see a use for having a [code]updated[/code] field on the Option table?
If it's something that'll get used by anyone else than I'll do it that way, otherwise I'll just let the assetFile system store a hash of the fields in a hidden option and compare that instead of an updated timestamp.
I just don't want to bloat the table with an extra field of nobody will ever use it, nor do I want to end up with several plugins using the hash method either.