A couple of thoughts regarding asset management.
First off, we could offer a wealth of features by integrating a third-party component like this one - no point in reinventing the wheel.
The other thing that occurred to me today is, the whole idea of publishing files from a protected folder into a public folder, with generated filename/path based on a hash of the original filename and modification time.
I it’s a good time to scrutinize this idea, and wonder if this design is really good or right.
For one, what happens when you clear your assets folder? Currently, any page that has cached an asset URL, is going to get a 404 if the URL of that asset changes.
Perhaps atypical, and you may not care, but in terms of search-indexing, the changing URLs could also be an issue - let’s say Google indexes an image you published, perhaps your company logo, and the URL keeps changing, with the old image becoming a 404. (might even affect search engine ranking, not sure.)
As mentioned above, I like the idea of producing assets on-demand, via a controller.
Let’s say the URL “http://site.com/assets/28b3cc8e/yii/jquery.js” mapped to an actual controller, which then generated that file. In the case where that file is updated, when the hash no longer matches, that controller could instead return a permanent redirect, thus solving the issue with 404 errors.
In effect, you can put whatever you want in the hash then, it’s no longer important - search-engines can update as needed, and browsers showing a cached page will be redirected to get the latest version of each asset.
Of course, this means there has to be some kind of unique identifier for the asset-collection (e.g. module-name) in every URL, since the hash no longer means anything and is only used as a means of forcing cache updates on browsers and other agents.