Index block not pulling in dynamic metadata for folder being indexed

Nate's Avatar


04 Apr, 2012 09:03 PM

I'm indexing a folder, but see no way to get the dynamic metadata of the folder I'm indexing. The System Metadata and User Metadata checkboxes are checked and the metadata for the underlying files/folders is there. Am I missing something or is there no way to get the metadata of the indexed folder itself? I need to be able to pass my formats information about the folder they're indexing. Using the "start at the current page" methods wouldn't work in all cases for me because the page pulling the information in isn't always in the same folder hierarchy. Is this possibly a bug that has been fixed in newer version than v6.8.2?

  1. Support Staff 1 Posted by Tim on 05 Apr, 2012 12:39 PM

    Tim's Avatar

    Hi Nate,

    It sounds like you may be running into this known issue. It has been around for quite some time (dating back to the initial 6.0 release).

    This is definitely an inconsistency with Index Blocks that we'd like to correct, but we tend to avoid any changes like this if at all possible due to the potential far-reaching ill effects it could have on clients. For example, if someone happens to be using one of these options and we change the behavior ('fix' the issue), their implementation will likely break. So, we have to keep this in mind during any modifications that we make to indexing schemes.

    I hope this makes sense. Let me know if you have any further questions.

    Thanks for the report!

  2. 2 Posted by Nate on 05 Apr, 2012 06:17 PM

    Nate's Avatar

    Thanks, Tim. Yes that does seem to be the issue I'm running into. Specifically I'm running into this part of that issue..."In Sites, this becomes more of an issue, because the Base Folder of a site is often used as a place to store site-wide metadata..."

    I'm not sure this is a question of if it's a "fix" or not. When you index a folder and say you want metadata, you are expecting to get the metadata. While I do understand that fixing the issue could cause some people problems, not fixing the issue is causing issues as well and is problematic because it will only get worse as more and more people build on the incorrect functionality. In my case I can't do what I need to do and any sort of workaround would be very hacky at best.

    In my experiences I've always seen this sort of thing dealt with by having a setting that allows people to operate that feature in legacy mode, and say that the legacy mode will be deprecated after two or so releases. This would allow anyone that updated and had problems to quickly change a setting and it would be fixed, and would then give them time to fix their formats.

    So what is the status of this issue? Is it something where it's ultimately not on anyone's plate to fix?

  3. 3 Posted by Bradley Wagner on 19 Apr, 2012 04:58 PM

    Bradley Wagner's Avatar

    Hi Nate,

    I think there's been some confusion with respect to CSI-324 that I want to attempt to clarify. That issue is addressing a inconsistency that appears to have been introduced around Cascade 6.0 between the "start at the current page" Rendering Behaviors (options 2, 3, and 4 in the Rendering Behavior radio button). Specifically, options 2, 3, and 4 do different things when deciding to include the the "base folder" (the root most folder in a Site or the Global area) in the index as they work their way up the asset's ancestor tree back to the root.

    As I understand it, the issue you're describing is that when you use option 1 ("Render normally, starting at the indexed folder"), there is no information in the index about the folder you have selected. That part is not related to CSI-324 and unfortunately is not a bug. That is the way the system has behaved as far back as I remember. Starting at the Index Folder actually means rendering the contents of the folder rather than the folder itself. The only child elements of the <system-index-block> are the actual assets within the folder.

    As Tim mentioned, addressing CSI-324 is difficult because it will affect existing customer implementations. As for the issue you're dealing with, we're not likely to change the default behavior for index blocks when rendering with option 1 both because it's been that way and because we have lots of clients relying on it working that way.

    However, I could see an improvement to the system that includes the folder's information in the index using an option similar to our "Append Calling Page Data" option called "Append Index Folder Data". This would allow users like yourself to include the selected Folder's metadata in the index where necessary.

    Is the folder you're trying to index the Base Folder of your site?

    Please let me know if I'm correctly understanding the problem you're running into.


  4. 4 Posted by Nate on 25 Apr, 2012 03:13 PM

    Nate's Avatar

    Thank you, Bradley. I believe you're understanding correctly. I am not trying to index the base folder of our site, but rather folders that contain "subsites" (admissions, alumni relations, etc.). An option like "Append Index Folder Data" would be extremely useful. The best place to store subsite-wide information seems to be it's parent folder. Unfortunately we have have pages outside of that folder hierarchy that need to pull in the nav and that information held in the folder metadata. Option 1 lets us pull in the navigation, but not the metadata. That checkbox you mentioned would be the only way I could see us being able to achieve what we need to achieve. What would be the best way to help that happen? Thanks again.


  5. 5 Posted by Bradley Wagner on 25 Apr, 2012 05:52 PM

    Bradley Wagner's Avatar

    Thanks for clarifying Nate.

    This would go through our typical evaluation process for new features and improvements. Many start as ideas on our idea exchange. I found one that looks somewhat similar and am trying to get clarification from the person who filed it. After that, ideas typically get some support from our community and we get a better idea if it will be useful to the majority of our clients.

    I have an idea for a possible solution in the interim. Would it make sense to create an Index Block that starts at your Site's Base Folder rather than the subsite folders and just goes 1 level deep? This would allow you to get the metadata of these subsite folders and would keep the index pretty small.

  6. 6 Posted by Nate on 26 Apr, 2012 08:51 PM

    Nate's Avatar

    Hmm...I'm not sure that would help. The information stored in the subsite folder helps in how we format the navigation used on those pages and also for a page outside of that folder. I believe we'd need both the full navigation for the subsite and that information stored in the subsite home folder so that the format has all of the necessary information.

    Yes, please let me know if I need to start a new idea in the idea exchange.

  7. 7 Posted by Bradley Wagner on 30 Apr, 2012 05:58 PM

    Bradley Wagner's Avatar

    Nate, how many assets are you indexing? Are you including the content of the assets? If you're just doing metadata you could probably get away with using a single index block that indexes all the site's content if it's only for building navigation.

    I'm still trying to get confirmation about the purpose of the idea that I linked to earlier. I think it's the same thing you're talking about.

  8. 8 Posted by Nate on 03 May, 2012 11:37 PM

    Nate's Avatar

    It is only being used for building the navigation, so possibly that would work, although I feel like it would have to go pretty deep since not everything is two levels deep and sites can really be at any depth. That worries me about getting out of hand since it would have to basically index the entire site's metadata. Also, does the block stay cached or would it have to re-render for each page? Our site publishes are already kind of slow and I worry about adding to the time.

  9. 9 Posted by Bradley Wagner on 04 May, 2012 03:40 PM

    Bradley Wagner's Avatar


    You could definitely test it out. Full-site indexes of metadata-only should be pretty fast.

    When 7.0 is released, it will cache index blocks like that until something is changed.

  10. Tim closed this discussion on 02 Oct, 2012 03:46 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac