Hi,

Not quite sure I follow what you're doing - so check my workings! This repeatable text fields field on your document is being used as a tag? What you want is to interrogate all pages and group and count the number times a particular value exists?

This is perfectly possible - I'd advice you ensure it's a cached macro (so each page load doesn't do this on each page load!) and I'd question the use of these multiple text fields.. are you happy that your editors are going to not miskey these? Wouldn't the tags field be better here?

This do you?

Remember to cache this!

@inherits Umbraco.Web.Macros.PartialViewMacroPage
@using System.Collections
@{
    var rootNode = Model.Content.AncestorOrSelf(1);
    Dictionary<string, int> tagsDict = new Dictionary<string, int>();

    // remember to change "repeatingValues" to that of your doctype field 
    foreach (var descendantNode in rootNode.DescendantsOrSelf().Where(x => x.HasProperty("repeatingValues")))
    {
        var tags = descendantNode.GetPropertyValue<string[]>("repeatingValues").Length > 0 ? descendantNode.GetPropertyValue<string[]>("repeatingValues") : new string[0];

        foreach (var curTag in tags)
        {
            // add to the dictionary
            if(tagsDict.ContainsKey(curTag))
            {
                tagsDict[curTag] += 1;
            }
            else
            {
                tagsDict.Add(curTag, 1);
            }
        }

    }

    foreach (var curTag in tagsDict.OrderBy(x => x.Key))
    {
        <p>@curTag.Key (@curTag.Value)</p>
    }
}

In short - it's not really best practise - you should try to avoid traversing the entire content tree as much as possible. That's why I empathised caching.

You should definitely target that code to change from the site root node to just the root node of the News Articles or whatever contains those documents that you need to track. It might help to filter by doc type too so that fewer iterations are required.

That said - if you need this sort of functionality there is always going to be a performance cost but you mitigate it with caching / node targeting and try to keep things sensible.

I've seen sites where people traverse the entire site structure to find a "include in menu" checkbox to build their menus. This is obviously bad and more easily solved with a multi-node content picker.

Often where sites are running slowly it's too many of these sorts of things running.. but caching and being aware will keep your site snappy.

So in short - please update that code to only include the node it needs (unless it is a site wide sweep!?).

HTH

Steve

is working on a reply...