Debugging the Umbraco Tag Cloud package would be great. But it’s not possible and not necessary.
However, one thing is really helpful when having problems with the counted nodes. Checking which nodes are counted.

Over time I’ve got repeated mails regarding having problems with counting the nodes. The problem often was a wrong or misunderstood result of the xpath expression. The “problem” with the RenderTags method is, that it just returns a result and you have no glue which nodes where counted.

A very easy way to check if your statements counts the nodes you want to count is the following.

After your code for the cloud

It was time for an update of the Tag Cloud Package introduced with the post Tag cloud for Umbraco CMS blog package. The bug removed is about having only two tags which caused a weight of -2147483648 for one of the tags.

If you already using this package just download and replace the TagCloud.dll.

If you are new to the package read the original post about my package at the introducing post Tag cloud for Umbraco CMS blog package.

Feedback is welcome.

Related links can be very useful to give the visitor an easy way to find additional information. This could be a page on your site or even a link to an external site.
How can this be realized with Umbraco?

A built in functionality is not available addressing this issue.

But there's already an extension package available. It's called Related Links. The package provides a property type allowing to add multiple internal and external links to a document.

I really feel confident with Umbraco and it's flexibility. Hence, I always think twice before installing a package.

Working with built in Features

With a few steps we can solve this issue using built in features and even get more flexibility.

Create a document type

To solve this we introduce a new document type called "Alias" with two properties "Node" and "Url". For easier editing we add a tab called "Settings" and assign the properties to this tab.

We want to add documents of this type to other documents. Therefore we must set the Alias document type as "Allowed child nodetype" of the document type where want the aliases to add to.

Create an xslt file with macro

To render the links we create an XSLT file ListAliases.xslt with the corresponding macro.
In this xslt stylesheet we iterate over all child nodes and set the href attribute according to the kind of link.

Use the macro

The last step is to use the macro in the template where the related links should be displayed.

...
<h2>Related</h2>
<?UMBRACO_MACRO macroAlias="ListAliases" ></?UMBRACO_MACRO>

Working with the solution

To create related links we now just have to add a child node of type Alias to our document for each related link we need.

In this child nodes just set the Node or the url to link to.

In this example we have two related links - one external (Umbraco) and one internal (My Blog).

The resulting page could look like the following

Key Benefits

• First of all. A document type is the main feature of Umbraco and therefore this solution should work for all future releases and for all installations. See also CMS structure granularity - not only in Umbraco.
• You can decide when to publish and when to remove the link by using the built in functionality available for all nodes.
• This solution is very extensible. You could add additional properties to the Alias document type for instance:
  • an image to be displayed next to the link
  • a  flag for a special sort criteria
  • a description which is displayed with the tooltip of the link.
  • You could introduce a document type called "Alias group" for grouping the links in for instance "Related" and "Depends on".
  • You could even manage your links at the root of your content tree to reuse them at different nodes.

What is the content? What is the structure of the content? What is a document type? What is a property of a document type? How can I reuse documents? Flexibility versus usability? How to avoid different appearance of same kind of data? How to extend the system on the fly?

These are some questions that come along when designing the internal structure of a CMS based website. Depending on your CMS some of them will be addressed with built in features, some of them could be done with some effort and some of them may not be solvable.

Here I want to show a very simple case study concerning what could/should be a document type.

The site

We want to create a site providing news items. To keep it simple we forget about authors, date to appear, date to disappear, categories and so on.

I will use the naming of the Umbraco CMS for this case study.

Straight forward Solution

Our document template (NewsItem) contains only one dynamic property called "Content" of type "Rich text editor". The title of the article is the node name itself.

Really simple. Let's write articles. Create a new content node with a meaningful name. Fill in your text in the Content area. Publish it. Ready.

The authors of the content will write text, insert some pictures and everything will be fine. Style sheets are defined well, so all articles look just the same.

Content without structure

After a while you will realize that the authors add a section for related links to external resources in the content text. Some of them write a heading called "References" listing all links with a bullet list others add a bold text named "Related" and provide the links with a comma separated list.

The result are articles formatted in many different ways destroying the corporate identity of the site.

Approach 1

The first approach would be to tell the authors that they should use a heading, call it "References" and to list the links using a bullet list. Maybe it would solve the problem if the authors work really consistent. Let's face it. Don't event think about this approach. You are using a CMS!

Approach 2

The next approach would be to add a property called "References" of type "Rich text editor" to our document type. This property would be used to write the links (again using a bullet list). The difference would be that the designer can decide how to call this section and where to place it. Even the formatting could be easier changed. Still not happy? Right.

The authors must still ensure that the formatting of the links is consistent (bullet list). Changes of the formatting could only be done by rewriting each article (ok, style sheets would also help for some situations).

The solution

The solution in terms of a CMS is to introduce another document type called "LinkItem" containing a property "Url" of type "Text string". The Friendly name of this link would be again the name of the node. This LinkItem is then declared as a "Allowed child node type" of the "NewsItem" type.

To add related links to a news item the authors add one child node of type LinkItem for each link.

Benefits

With this solution the authors now can again force their energy to write content and to provide related links. The designer can decide where to place the links, how to format them and even if they should be hidden in a special situation.

That's why we use a CMS. Isn't it?

After finishing the Tag Cloud package the next step to improve my web site was to get rid of the ugly query URLs when filtering blog posts by tag.

The Goal

Instead of

/blog.aspx?filterBy=TagName

I wanted something like

/blog/tag/TagName

Why ?

1. As we all - techies of course - know search engines are not happy with URLs like this
2. I also had the impression that Google AdSense didn't distinguish the pages correctly.
3. I personally don't like URLs containing query parameters on a web page as they are not user friendly.
4. Some kind of perfectionism

The Solution

It's that simple that I was not sure if it's being worth posting. But it took me a while to find the solution. Like in most cases. It's easy if you know where and how to do it. It would be easier if the feature would be mentioned in the feature list or online help. However, here it is:

In the file /config/UrlRewriting.config one can place rules for rewriting URLs. Just add a rule like this.

<add name="tagfilter"
  virtualUrl="^~/blog/tag/(.*).aspx"
  rewriteUrlParameter="ExcludeFromClientQueryString"
  destinationUrl="~/blog.aspx?filterBy=$1"
  ignoreCase="true"
/>

A detailed description how it works can be found in the file itself.

One important thing is that without reconfiguring the IIS Server the URL must end up with .aspx. So the new URL looks like this

/blog/tag/TagName.aspx

which is very straight forward as all other nodes are also referenced using the aspx extension.

References

• This Umbraco feature is powered by the ASP.NET UrlRewritingNet component which can be found at http://www.urlrewriting.net/
• A Post where the feature is at least mentioned.
• A Post from Warren where he points to some problems using this feature.