Index block not pulling in dynamic metadata for folder being indexed
Support Staff2 Posted by Tim on 05 Apr, 2012 12:39 PM
It sounds like you may be running into this known issue.
It has been around for quite some time (dating back to the initial
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
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?
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
Is the folder you're trying to index the Base Folder of your
Please let me know if I'm correctly understanding the problem
you're running into.
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?
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.
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
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
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.