Debugging and Troubleshooting Umbraco XSLT (and .NET)
06/01/2011 1 Comment
First and most important – append this to whatever URL is not working:
?umbDebugShowTrace=true. This gives you quite an amazing amount of information.
It’s based on the default ASP.NET trace – but the Umbraco people have (as always) been very diligent, and provided us with a ton of extra information written to the trace.
For example you will find that on the PreInit ASP.NET page life cycle event, the node matching the current URL is fetched using XPATH (of course), and then added to the cache, so you will only see this XPATH being executed on republish.
After this, in the Init page event, cached macros are loaded in, and then any XSLT transformations are handled after this.
If you go change your Macro settings in some way (or just recycle the app pool to flush all caching), you will see the Macro being rendered- and then loaded from the Umbraco cache next time round.
What’s interesting is that XSLT is not cached, the transformation are always executed. As XSLT is extremely fast and in this case working on the cached Umbraco XML (every time you publish something, the entire site structure is rendered as XML and saved on disk (/app_data/umbraco.config) and also cached in-memory on the server), there’s of course no need to cache the results of this work, as the process is already very efficient.
There’s loads more stuff like this in the trace – but what is really, really useful – is that you get the full XSLT exceptions in stead of the default “failed to load XSLT file…” error.
If umbDebugShowTrace does not provide you with enough info to solve your problem, you will find that you can attach Visual Studio to whatever local process your site is running in (Casini or the IIS w3p) – and from here debug everything, even your XSLT files (try it, setting a breakpoint in your XSLT actually works).