Allowing designers to update CSS

Is there a standard Sitefinity way to allow designers to update CSS without them working directly on the web server files?  Would be nice for these files to be versioned like pages, allow drafts and publishing, etc.  Right now we are using Feather Resource Packages and keeping the CSS in there but I would rather our designers have a means to update CSS without a developer having to deploy files to the production servers (which the designers can't and won't be able to do on their own).

Thanks...

Hi Jon,

Sitefinity has built-in file manager (Administration -> File Manager), in theory, designers can use that for uploading new css files

Right, but that doesn't give any type of versioning/publishing functionality.  We don't want them making changes directly to the live system but do want them to be able to preview their changes.  Plus since there doesn't seem to be any means to give fine grained control to the Administration section and we do not want them to have access to all of it, the File Manager is not really an option.

Would maybe placing the CSS files in a File Library work?  It does allow for publishing.  Not sure if it would work better as a Database or FileSystem library.

Hi Jon

That may work. Change your layout files to point to the resource in the library. If you make it a file system library that will be faster delivery than a DB library.

You may also want to consider adding the CCS widget which allows linking to a CSS file or create a custom one.

This would allow the designer to edit the page assign a different version and preview without affecting the whole site.  (This may or may not be a practical for your site)

Cool, I like the CSS widget idea.  I was wondering how the file libraries did drafts and if edits would show to the editor while logged in and viewing the site in order to preview it.  I'll have to play with that a little and see how well it works.

Thanks...

The file storage works just like the database. The file details are all in the database juts that the physical binary is stored on the file system rather than in a database column.

You will find they are all stored under App_Data/Sitefinity/Storage/.. (I forget exactly)

All the files are stored as GUIDs with no exten. The guid references the row in the database. If you do decide to use File storage keep in mind that when you backup your DB you also need to backup the Storage folder with the files.

When you restore you also need to restore the folder as the folder is now an extension to the database data.

Hopefully that makes sense.

By default I don't use FileSystem storage expect for very large files. (Videos and pdfs for example) Actually I always use FileSytem for videos otherwise performance is an issue)

Ok, I think I'll just stick with database storage for this if there is no real reason here to use the file system.  These files will get cached in the browser (and our reverse proxy) anyway.

What about cache busting?  For DB based files, is there something that automatically updates a version number in the query string when new versions are available?

You can try implement this into your solution

www.sitefinity-stuff.com/.../browser-cache-busting-for-your-javascript-files

I actually already have a method similar to this that we use for files such as css and javascript libraries.  But wouldn't this only work for files on the file system with non virtual paths?

The browser doesn't care. It looks at the url string you are providing in the markup. It has no idea if it is file system, web service, database or is even valid.

If it is different, then it considers it a new file and tries to get it.

Yea, I get that, but I wasn't talking about the browser, I was talking about the backend having to get the file date/time stamp that was in the code you sent.  Would that be available in a DB stored file?  Is it written somewhere that MapPath will see?  I figured it was writing to temp space or streamed directly from the DB.

That is a good point.

So that meta is stored in the database and the properties of the object when you retrieve it in your code.  

Looks like the problem with using the CSS widget is that it doesn't seem to be able to track the file version number like links in the content editor widget can, or at least if you can I don't see how.  You can add a css link via a content widget, but that would remove the option of easy switching of CSS files for the designer.  That may still be the best option though unless you can think of something better.