We started a new project last week and decided to implement an interesting architecture for storing articles in a hybrid bucket-hierarchy approach. The new site is for a magazine that publishes both online articles and hard copies of the magazine. Therefore, articles hosted on the site can be online-only articles or online articles that are also associated with a particular issue of the magazine. Also, another important factor for this site is that an article can only be associated with a single magazine issue and not to multiple issues.
The site in question has thousands of articles that can be cross-tagged to dozens of categories so it was a pretty easy decision to use item buckets in some way. And for categorization, we’re just going to use a simple multilist of flat tags that can be selected for each article.
At this point we had a single bucket filled with articles but the interesting part was figuring out how to associate an article with a particular issue of the magazine. At first we were looking at using a traditional tagging approach by storing issues as meta-data and then allowing content authors to select an issue for each article from a droptree field. This approach would solve the problem from a technical perspective but I did have some concerns from a content author perspective. I wanted a more intuitive and easy way for content authors to view all articles for a particular magazine issue and add a new article to a magazine issue. At this point we talked about adding bucket facets for each year and issue but we decided to take another approach for dealing with magazine issues and their articles.
The Bucket-Hierarchy Approach
The image below shows the structure we decided upon for storing articles.
The important thing to note is that the top level “Articles” item is not a bucket in this case. But the “Online-Only Articles” item is a bucket that holds articles that are not part of an issue. Nothing crazy there as the “Online-Only Articles” bucket is just a standard item bucket. However, under the top level “Articles” item we have also created an issue hierarchy that holds articles that are not bucketed by default. In general, most issues will not have more than ~50 articles so we can show the articles like normal by default and trigger the auto-bucketing feature in Sitecore if a particular issue grows too large on occasion.
I think this is a far more intuitive way for content authors to add articles to an issue and allows them a quick way to see which articles have already been added to an issue. Since we’re not dealing with a lot of articles per issue, each issue is not a bucket by default and users can easily navigate the articles in a hierarchical format like they are used to in Sitecore.
I really like this item bucket setup for this particular scenario. It might not allow for the greatest flexibility but it does make it easy for content authors to find and add content as part of a hierarchy (in this case it is a hierarchy of magazine issues) instead of everything in a bucket. However it is important to note that for this setup to be possible, each article must only be associated with a single issue. If an article could be cross-linked to multiple issues then this structure no longer makes sense.
Problems with multiple buckets in a hierarchy
I originally attempted to make the top level “Articles” item a bucket in my scenario but I ran into some unexpected behavior when “Issue” items were auto-bucketed after passing the child item threshold (My solution was set to auto-bucket an “Issue” item when more than 60 child articles were added).
In general, I have found it problematic to have buckets in a hierarchy. By default, if you have an item bucket with a subitem that is also a bucket then you are no longer able to properly revert (un-bucket) and then re-bucket either item. Doing a revert (un-bucket) on either bucket will cause bucketed items to restructure in an unexpected way that makes it impossible to then re-bucket the item and get back to its original state.
In my example if the top level “Articles” item was a bucket and an issue (sub-item) also became a bucket (after auto-bucketing was triggered) then things started to go sideways. Everything seemed OK at first but if I was to un-bucket and then re-bucket the top level “Articles” item then items held under the sub-bucket would try to restructure themselves under the top level “Articles” bucket. Confusing, I know. Long story short, I decided on the structure explained above because it is a more simple example of using buckets. If a site administrator starts playing around with the buckets at some point in the future then I am confident they will not break the site structure.
So I learned my lesson. Be careful when your architecture makes it possible to have multiple buckets in a hierarchy. Even if this is caused by the “Auto-bucket” feature in Sitecore that you might not be thinking about.
Thoughts, concerns, let me know!