is there another xslt translation before umbraco invokes macros
I've been playing with fresh install of umbraco and blog plugin and modifying site templates (I was refactoring existing templates to make blog fit into a more complex website that would have other custom pages). All of a sudden BlogListPosts.xslt stopped returning anything.
I ran the website through the debugger and noticed that $currentPage has the following structure: <root>/<node>/<data>/.... (which is the structure in umbraco.config file). However the xslt file is expecting to see Blog/.../BlogPost.
Can anyone tell me how the $currentPage get converted from what's stored in the umbraco.config file into the element structure that blog4umbraco is expecting to see?
Current page returns all the values associated with the node ID of the page you are currently viewing.
If the ID of the page with the currentPage variable is not the one you are expecting then you are not viewing a Blog Post. However you can get any xml from anywhere within your site using a macro so don't be concerned if you want to view information that is not in the currentPage variable.
For example a 'latest blog post' macro might be placed on any page and can work independently of the currentPage variable, which can in turn be viewed anywhere on the site.
Hi Rich, thank you for quick reply. Everything you said makes perfect sense, however I already knew all of it.
I think I'm missing something fundamental. The problem is that I know enough about visual studio and XSLTs to be dangerous but not quite enough to know how this stuff works. So I went down the path of attaching a debugger and stepping through .NET macro control and XSLT itself to see if I can figure it out.
The XPath that's supposed to find elements but finds nothing is this: "$currentPage/ancestor-or-self::Blog//BlogPost". I read this as: 1) start at the node in $currentPath, that node could be <Blog> or a child element; 2) walk up the tree (and check self) until we find <Blog>; 3) return all descendant <BlogPost> elements (any level down). However, the XML document the code is working with is wwwroot/data/umbraco.config and when I open that file in XML editor, I do not see <Blog> or <BlogPost> elements. Instead, I see <root>, <node> and <data>, and this is also the input that the xslt translation is receiving.
So if I change above XPath to be something like (currently at work, so don't have exact syntax): $currentPage/ancestor-or-self::node[@nodeTypeAlias='Blog']//node[@nodeTypeAlias='BlogPost'], then everything works. But it is something I changed somewhere else that made this break in the first place because originally Blog//BlogPost was working fine, so $currentPage must have been pointing at a different XML document. I checked another umbraco installation I have and confirmed that it's umbraco.config has the same format that my file has, so now my only guess is that something in the code converts <root>/<node>/.../<node> into <Blog>/.../<BlogPost> before xslt's get invoke.
I really appreciate you taking the time to help, especially with the whole train catching thing.
My webserver, currently has 4.0.x installed but when I was setting up my development environment, at first I loaded latest and greatest (4.5 Umbraco and Blog4Umbraco 2.0.26, the install that's one marked compatible with 4.5). I was getting a bunch of quirks so after several reinstalls, I noticed that the only difference between my webserver and development machine is 4.0 vs. 4.5 so I downgraded to 4.0. If you are curious, specific issue was that when creating new blog post, the post would appear right under Blog node and the UI would never create the tree for year/month/day. Because of that, archive never displayed anything.
I understand xpath and that I can start with the root (as opposed to walking up before walking down). There are definitely ways I can fix this, but if I have to convert everything to use <root> element, that means none of the xslt's work as they are in the package. And that can't be the case. When I first installed things, everything worked. Then I modified some master templates and all of a sudden things broke. I'm not trying to find initial cause (that's got my name written all over it... master templates) but how the actual thing works and how originally xlt's worked fine with assumption that the document has <Blog>/..../<BlogPost> when on disk that structure never existed. Ideally, I'd like to get to a point where I can have my custom master templates and not brake existing functionality.
I seems your Blog* XSLT file is expecting the 4.5 Schema, whereas your umbraco.config (and thus the in-memory XML tree) clearly has legacySchema "written all over it" - so I'd either rewrite the XSLT (there's a couple of online converters available) to use the old schema, or get back up to version 4.5 on the app.
So to be clear about your initial question(s): There's no pre-XSLT step happening and $currentPage is not being converted or anything. It's just a mismatch between versions.
I knew I was missing something fundamental. Thank you, both for helping me identify the user error.
So originally when I installed 4.5, I fixed small bug with the date in the xslt and because I made a change, I copied the file into my source control directory. Then I discovered the thing I mentioned where for whatever reason DateFolder nodes would not get created for new blog entries. After reinstalling 4.5 about 6-7 times, I decided to revert back to 4.0.4.2 for the time being. And clearly, completely forgot about that one-line change I made in the xslt.
A week later when I modified the master templates and ran a script to copy files from source tree into the website, in addition to getting new templates, I also ended up installing an xslt file that screwed everything up.
Well, on the bright side, I learned about debugging websites and xslt's through visual studio. That was definitely an interesting experience.
is there another xslt translation before umbraco invokes macros
I've been playing with fresh install of umbraco and blog plugin and modifying site templates (I was refactoring existing templates to make blog fit into a more complex website that would have other custom pages). All of a sudden BlogListPosts.xslt stopped returning anything.
I ran the website through the debugger and noticed that $currentPage has the following structure: <root>/<node>/<data>/.... (which is the structure in umbraco.config file). However the xslt file is expecting to see Blog/.../BlogPost.
Can anyone tell me how the $currentPage get converted from what's stored in the umbraco.config file into the element structure that blog4umbraco is expecting to see?
Current page returns all the values associated with the node ID of the page you are currently viewing.
If the ID of the page with the currentPage variable is not the one you are expecting then you are not viewing a Blog Post. However you can get any xml from anywhere within your site using a macro so don't be concerned if you want to view information that is not in the currentPage variable.
For example a 'latest blog post' macro might be placed on any page and can work independently of the currentPage variable, which can in turn be viewed anywhere on the site.
Make sense?
Rich
Hi Rich, thank you for quick reply. Everything you said makes perfect sense, however I already knew all of it.
I think I'm missing something fundamental. The problem is that I know enough about visual studio and XSLTs to be dangerous but not quite enough to know how this stuff works. So I went down the path of attaching a debugger and stepping through .NET macro control and XSLT itself to see if I can figure it out.
The XPath that's supposed to find elements but finds nothing is this: "$currentPage/ancestor-or-self::Blog//BlogPost". I read this as: 1) start at the node in $currentPath, that node could be <Blog> or a child element; 2) walk up the tree (and check self) until we find <Blog>; 3) return all descendant <BlogPost> elements (any level down). However, the XML document the code is working with is wwwroot/data/umbraco.config and when I open that file in XML editor, I do not see <Blog> or <BlogPost> elements. Instead, I see <root>, <node> and <data>, and this is also the input that the xslt translation is receiving.
So if I change above XPath to be something like (currently at work, so don't have exact syntax): $currentPage/ancestor-or-self::node[@nodeTypeAlias='Blog']//node[@nodeTypeAlias='BlogPost'], then everything works. But it is something I changed somewhere else that made this break in the first place because originally Blog//BlogPost was working fine, so $currentPage must have been pointing at a different XML document. I checked another umbraco installation I have and confirmed that it's umbraco.config has the same format that my file has, so now my only guess is that something in the code converts <root>/<node>/.../<node> into <Blog>/.../<BlogPost> before xslt's get invoke.
Am I making any sense with this or am I way off?
Got to catch a train, but pretty much you can forget where currentPage is and work it out from the root, something like this
Then use something like
I'm not sure which Umbraco version you are using but the above is for >= 4.5
Sorry, for being so short, gotta run.
Rich
I really appreciate you taking the time to help, especially with the whole train catching thing.
My webserver, currently has 4.0.x installed but when I was setting up my development environment, at first I loaded latest and greatest (4.5 Umbraco and Blog4Umbraco 2.0.26, the install that's one marked compatible with 4.5). I was getting a bunch of quirks so after several reinstalls, I noticed that the only difference between my webserver and development machine is 4.0 vs. 4.5 so I downgraded to 4.0. If you are curious, specific issue was that when creating new blog post, the post would appear right under Blog node and the UI would never create the tree for year/month/day. Because of that, archive never displayed anything.
I understand xpath and that I can start with the root (as opposed to walking up before walking down). There are definitely ways I can fix this, but if I have to convert everything to use <root> element, that means none of the xslt's work as they are in the package. And that can't be the case. When I first installed things, everything worked. Then I modified some master templates and all of a sudden things broke. I'm not trying to find initial cause (that's got my name written all over it... master templates) but how the actual thing works and how originally xlt's worked fine with assumption that the document has <Blog>/..../<BlogPost> when on disk that structure never existed. Ideally, I'd like to get to a point where I can have my custom master templates and not brake existing functionality.
Hi Dennis,
I seems your Blog* XSLT file is expecting the 4.5 Schema, whereas your umbraco.config (and thus the in-memory XML tree) clearly has legacySchema "written all over it" - so I'd either rewrite the XSLT (there's a couple of online converters available) to use the old schema, or get back up to version 4.5 on the app.
So to be clear about your initial question(s): There's no pre-XSLT step happening and $currentPage is not being converted or anything. It's just a mismatch between versions.
/Chriztian
I knew I was missing something fundamental. Thank you, both for helping me identify the user error.
So originally when I installed 4.5, I fixed small bug with the date in the xslt and because I made a change, I copied the file into my source control directory. Then I discovered the thing I mentioned where for whatever reason DateFolder nodes would not get created for new blog entries. After reinstalling 4.5 about 6-7 times, I decided to revert back to 4.0.4.2 for the time being. And clearly, completely forgot about that one-line change I made in the xslt.
A week later when I modified the master templates and ran a script to copy files from source tree into the website, in addition to getting new templates, I also ended up installing an xslt file that screwed everything up.
Well, on the bright side, I learned about debugging websites and xslt's through visual studio. That was definitely an interesting experience.
-- Dennis
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.