This project is read-only.

Theme XSLT Changes Requiring IISReset - Workaround?

Topics: Enhanced Blog Edition
Mar 16, 2009 at 1:04 AM
I'm a big fan of the modular theme framework, however one aspect I'm having difficutly with is the fact that an IISReset (or app pool recycle likely) is required in order to see xslt changes. At first I thought this was related to something being cached behind the scenes with the compiled XSLT so I made some modifications on the methods used to load the stylesheets but with some further investigation I've found that its the SharePoint plumbing itself that is doing the caching. I have several blogs that I'm using the same custom theme with. I'm relying on the fact that the xslt is not customized so i can go into the feature and update the XSLT and all the blogs get updated who use that theme. Additionally some users go into the theme folder directly and upload a new xslt file . Unfortunatly it takes someone jumping on the box and recycling app pools (or a quick IISReset) before the change is visible which has caused some problems at times. A simple way to reproduce this behavior is to go directly to the XSLT file in the theme folder and preview the XSLT in the browser, then jump on the server - goto the theme feature folder and modify one of the xslt files. Refreshing the page does not load the new updates. You will not see the modification until the next reset. I'm assuming the answer here is that features don't support upgrades so SharePoint is caching the file, but has anyone heard of any way to get around this behavior?

Thanks in advance.

Mar 25, 2009 at 4:53 PM

Sounds like you have something else going on there as I have never seen this behaviour. I would suspect caching of some kind.