Xslt debugging your umbraco powered website
Rating: 4.7 / 5 stars - 13 vote(s).
Finally found some spare time to dive into something that was already annoying me since I returned from the Level 2 training in cph last November. Niels has shown us how to do xslt debugging. I was writing down some notes on how to do this but apparently did not take enough notes, so I was unable to reproduce until yesterday! Hooray! Here’s a very short how-to enable xslt debugging for your umbraco sites…
First things first: I’ve set up a complete new site using the latest nightly build available from http://nightly.umbraco.org. Steps taken to set up the new site:
- Create a new folder “nightly” in my inetpub folder.
- Create a new website “nightly” in IIS pointing to the inetpub\nightly folder. Added a site binding nightly.local
- Updated my hosts file (in windows\system32\drivers\etc) folder to map nightly.local to my localhost’s IP 127.0.0.1
- Create a new database/database user for the new site, and adjusted the web.config to point to my database instance.
- Run the umbraco website installer at http:/nightly.local/install (Do not install anything yet as we will be installing CWS2 from Warren)
After installation of umbraco, install Warren’s amazing CWS2 package available from http://umbracocws.codeplex.com (I’ve been using the 2.0.1 version)
I’ve used Warren’s package because I wanted to have a play with it and because I knew it has a bunch of xslt files already in place (I’m a bit lazy…)
Ready! Ok, let’s move on… we’re almost ready to debug our first xslt. You’ll be surprised how easy things will be…
- Open up a new instance of Visual Studio.net 2008.
- File –> Open –> Web Site…
- Click ‘File System’ and browse to the folder we’ve created before inetpub\nightly and click ‘Open’.
At this point, you might get a warning (this one’s from another website…)
Just hit ‘No’ here and continue.
If you now try to run the default.aspx page (‘Set As Start Page’ and hit F5), you’ll run into an error because the ‘Virtual path’ is not configured correctly. In order to make it run without error, remove ‘nightly’ from the ‘Virtual Path’ (it should now read as ‘/’) and hit F5 again. You’ll be able now to browse the umbraco website.
Enable xslt debugging is as simple as putting a breakpoint on any of the xslt statements in any of the xslt files. For this example, we’ll be browsing the ‘News and Events’ page (link available in left navigation). But let’s get that breakpoint in first.
Don’t put your breakpoint on <xsl:param name=”currentPage” /> or <xsl:param name=”MaxNoChars” select=”100” /> because those won’t get hit… Now browse the ‘News and Events’ page and it should break on the breakpoint set in the ListNewsAndEvents.xslt file.
I’ve added some watch expressions for $currentPage (the complete xml document for the page requested), the $MaxNoChars parameter and an XPath expression $currentPage/data [@alias = ‘metaDescription’]
Bottom line: is it that simple? Yes, it is! umbraco FTW!
I’ve also discussed this with Richard who’s using a slightly different approach but which also works flawlessly. He’s creating a new project, copying all relevant files and attaches the debugger to the IIS process instead of running the website from within Visual Studio.net
Happy debugging!