This is annoying. I have a site where I've created a Document Type that I use to define links in a menu bar running along the top of the page ("SectionType"). I also have some XSLT that >>used<< to pull content nodes based on nodeTypeAlias:
<xsl:for-each select="$currentPage/ancestor::root//node[((@nodeTypeAlias = 'SectionType') or (@nodeTypeAlias = 'NewsSectionType')) and (string(data[@alias = 'hideFromMenu']) = '0')]"> <a href="{umbraco.library:NiceUrl(current()/@id)}"><xsl:value-of select="current()/data[@alias='naviText']" /></a> </xsl:for-each>
NewsSectionType is another Document Type derived from SectionType.
This morning I created another Document Type derived from SectionType called SidebarType. Nodes based on SidebarType are destined to end up in (you guessed it) a sidebar menu using some very similar XSLT.
Unfortunately, the XSLT for SidebarType didn't generate anything. I wasn't able to figure out why that was happening, so I deleted SidebarType, the related XSLT and the macro.
And now the original SectionType XSLT has stopped pulling anything as well!!!
What in the heck is going on here? Has the database gotten corrupted somehow? If so, how do I fix it?
- Mark
p.s. one oddity I noticed along the way is that when I deleted SidebarType the content nodes I'd created based on that document type disappeared from the content panel. Was I supposed to delete the content nodes first before deleting the type they were based on?
Sigh. I figured it out...and I believe it's a bug, or at least something that should be emphasized in the documentation on creating types (maybe it is and I didn't see it).
One other thing I did along the way to creating a new SidebarType derived from SectionType was to change the alias of a property that I use to hide a page from navigation.
It turns out that if you change the alias of a property after you create it the values in the content nodes of that property will not be visible under the new name. Instead, they'll be visible under the old name.
I suppose from a programming point of view what's happening under the hood is that property values are looked up by alias, not by a hidden unique ID # that is linked to the alias.
I can understand that. However, I tend to think of things like aliases as being properties of a "thing" that has an independent existence separate from it's value/name. Which is why I ended up having the problem.
Why do you think republishing the entire site would fix the problem? I thought publishing was something that affected content, not the structure of the content.
Disappearing Document Type?
This is annoying. I have a site where I've created a Document Type that I use to define links in a menu bar running along the top of the page ("SectionType"). I also have some XSLT that >>used<< to pull content nodes based on nodeTypeAlias:
<xsl:for-each select="$currentPage/ancestor::root//node[((@nodeTypeAlias = 'SectionType') or (@nodeTypeAlias = 'NewsSectionType')) and (string(data[@alias = 'hideFromMenu']) = '0')]">
<a href="{umbraco.library:NiceUrl(current()/@id)}"><xsl:value-of select="current()/data[@alias='naviText']" /></a>
</xsl:for-each>
NewsSectionType is another Document Type derived from SectionType.
This morning I created another Document Type derived from SectionType called SidebarType. Nodes based on SidebarType are destined to end up in (you guessed it) a sidebar menu using some very similar XSLT.
Unfortunately, the XSLT for SidebarType didn't generate anything. I wasn't able to figure out why that was happening, so I deleted SidebarType, the related XSLT and the macro.
And now the original SectionType XSLT has stopped pulling anything as well!!!
What in the heck is going on here? Has the database gotten corrupted somehow? If so, how do I fix it?
- Mark
p.s. one oddity I noticed along the way is that when I deleted SidebarType the content nodes I'd created based on that document type disappeared from the content panel. Was I supposed to delete the content nodes first before deleting the type they were based on?
Hi Mark
could you please provide us with the version of Umbraco that you are currently using? This will make it easier to help you out if it's possible.
/Jan
Sigh. I figured it out...and I believe it's a bug, or at least something that should be emphasized in the documentation on creating types (maybe it is and I didn't see it).
One other thing I did along the way to creating a new SidebarType derived from SectionType was to change the alias of a property that I use to hide a page from navigation.
It turns out that if you change the alias of a property after you create it the values in the content nodes of that property will not be visible under the new name. Instead, they'll be visible under the old name.
I suppose from a programming point of view what's happening under the hood is that property values are looked up by alias, not by a hidden unique ID # that is linked to the alias.
- Mark
Did you go to the content section and choose "Repulish entire site" when you changed the alias? I believe that should fix it.
I think it's only natural that your XSLT does not work when you change the alias you are referencing.
/Jan
I can understand that. However, I tend to think of things like aliases as being properties of a "thing" that has an independent existence separate from it's value/name. Which is why I ended up having the problem.
Why do you think republishing the entire site would fix the problem? I thought publishing was something that affected content, not the structure of the content.
- Mark
Yes that part of my post did not make sense. I got some things mixed up. Off course that would not do any good. Sorry 'bout that :)
But if you think that it is a bug, please report it on codeplex so the core team can adress it. http://umbraco.codeplex.com/WorkItem/Create.aspx
/Jan
is working on a reply...