tag:help-archives.hannonhill.com,2010-02-09:/discussions/bug-reports/2868-caching-issue-related-to-indexing-againCascade CMS: Discussion 2017-01-12T14:48:22Ztag:help-archives.hannonhill.com,2010-02-09:Comment/389145472016-01-14T13:42:42Z2016-01-14T13:42:42ZCaching Issue Related to Indexing Again<div><p>Hi Wing,</p>
<p>It definitely sounds as though you are running into the same
cacheing issue that stems from essentially nested Index Block
content. I went ahead and attached the known defect to this
discussion so you can track it's progress in the upper right-hand
corner of this page. I will also try to bump this up a bit in
priority since we've had a couple of other clients run into this as
well.</p>
<p>In the meantime, I was reading back over your <a href="http://help.hannonhill.com/discussions/bug-reports/1736-caching-issue-related-to-indexing">
original discussion</a> to get a better picture of where you had
left off. I am assuming the end result was your
<strong>RWD1</strong> implementation?</p>
<blockquote>
<p>After a folder has been converted (by switching the content type
of pages within using web services), when I navigate from one
sub-folder to another sub-folder, the left menu from the first
sub-folder sticks when I am actually in the second sub-folder and
is not updated. ... The only thing I can say is that RWD2 relies on
indexing more heavily then RWD1. For example, I no longer need a
breadcrumb block/region. I also mix $contentRoot with the Locator
Tool to solve the original caching problem.</p>
</blockquote>
<p>I'm assuming you are using the main, or a nested, Index Block to
look for the calling page and build out your navigation. This would
explain the incorrectly cached data. Is this Index Block contextual
and based on the calling page? Would it possible to use the Locator
Tool at this point to generate the navigation as a workaround for
the caching issue?</p>
<blockquote>
<p>I know that this problem cannot be easily reproduced, because it
involves several sites at the same time. I just want to ask if
there is any plan to fix this caching problem in the near future.
Since more and more people are adopting the one-template approach,
sooner or later, other people will be making similar complaints
too.</p>
</blockquote>
<p>Completely understand, and I apologize for the inconvenience.
Looking over the developer comments on the original issue, it
appears this is quite a complex issue and might take some time to
work through a solution.</p>
<p>With Cascade 8 being the main priority at the moment, I am not
able to provide a timeline at this time. As I mentioned, I will try
to push this issue up in the priority list.</p>
<p>Please let me know if you have any questions.</p>
<p>Thanks!</p></div>Ryan Griffithtag:help-archives.hannonhill.com,2010-02-09:Comment/389145472016-01-14T14:21:07Z2016-01-14T14:47:46ZCaching Issue Related to Indexing Again<div><p>Ryan,</p>
<p>Thank you for looking into this again.</p>
<p>This problem was generated by the following configuration: an
index block named left-menu is attached to a data definition block
named _left-column, which in turn is picked up by indexing. Later
on, the indexed information is processed and stored in the region
named STORAGE.</p>
<p>Now I change my design and remove left-menu altogether. Instead,
I change the indexing behavior of the index block named
calling-page so that the option <code>Start at the current page
with folder hierarchy, and also include siblings</code> is
selected. Since the information of the calling page is always
updated properly, I don't need to worry about caching anymore. Now
I can generate both the breadcrumb and the left menu within
DEFAULT, and the relevant div's are moved to the right places by
the template-level format.</p>
<p>I have also considered using the Locator Tool. My only
concern—I haven't tried this approach yet—is the folder
order of the children in the current folder. If the Locator Tool
does not return information on folder order, then I may need to
query the database directly to get that information. Any thought on
this one?</p>
<p>Wing</p></div>Wing Ming Chantag:help-archives.hannonhill.com,2010-02-09:Comment/389145472016-01-14T15:32:31Z2016-01-14T15:32:31ZCaching Issue Related to Indexing Again<div><p>Not a problem at all, Wing, thank you for the additional
information.</p>
<blockquote>
<p>Now I change my design and remove left-menu altogether. Instead,
I change the indexing behavior of the index block named
calling-page so that the option Start at the current page with
folder hierarchy, and also include siblings is selected. Since the
information of the calling page is always updated properly, I don't
need to worry about caching anymore.</p>
</blockquote>
<p>This does make sense since contextual Index Blocks wouldn't be
cached, so that top-most Index Block wouldn't contain incorrect
information.</p>
<p>Another possible workaround, you could index a really simple
Feed Block with your chosen Index Block. As long as that Feed Block
never becomes invalid (a known issue), that chosen Index Block's
content should not be cached.</p>
<blockquote>
<p>I have also considered using the Locator Tool. My only
concern—I haven't tried this approach yet—is the folder
order of the children in the current folder. If the Locator Tool
does not return information on folder order, then I may need to
query the database directly to get that information. Any thought on
this one?</p>
</blockquote>
<p>Currently, the order of the children is based on their relative
order (ie folder order); however, that is not something we
officially documented so I can't guarantee it will always be that
way. I can't think of an immediate reason to change this behavior
and not use relative order since generally that is the preferred
order method when traversing children, but I don't want to make any
promises.</p>
<p>Please let me know if you have any questions.</p>
<p>Thanks!</p></div>Ryan Griffithtag:help-archives.hannonhill.com,2010-02-09:Comment/389145472016-01-14T15:42:52Z2016-01-14T15:42:52ZCaching Issue Related to Indexing Again<div><p>When I have time, I will try using the Locator Tool.</p>
<p>I have just made a suggestion to my boss. Since the config block
named _left_column is used mainly to house the index block
left-menu, if the left menu is generated elsewhere, then there is
no use of _left_column anymore, unless we want to add more blocks,
besides the left menu, to the left column. My suggestion is to ban
this practice altogether, and we can remove _left-column from the
design.</p>
<p>Wing</p></div>Wing Ming Chantag:help-archives.hannonhill.com,2010-02-09:Comment/389145472016-01-14T16:03:48Z2016-01-14T16:04:25ZCaching Issue Related to Indexing Again<div><p>You are right. The folder order is preserved when using the
Cascade API. I used the following code to confirm that:</p>
<pre>
#set( $parent_folder = $currentPage.getParentFolder() )
#set( $siblings = $parent_folder.getChildren() )
#if( $siblings.size() > 0 )
<ul>
#foreach( $sibling in $siblings )
<li>$sibling.getPath()</li>
#end
</ul>
#end
</pre>
<p>Wing</p></div>Wing Ming Chantag:help-archives.hannonhill.com,2010-02-09:Comment/389145472016-01-14T16:10:47Z2016-01-14T16:10:47ZCaching Issue Related to Indexing Again<div><p>Thank you for confirming, Wing. Locator Tool with Cascade API
might be slightly slower than a cached Index Block, but if you just
need a handful based on the calling page it could be an option.</p>
<p>As you mentioned, if you can nix the nav all-together as an
option, that's definitely another solution.</p>
<p>I'm going to go ahead and close this discussion, please feel
free to comment or reply to re-open if you have any additional
questions.</p>
<p>Have a great day!</p></div>Ryan Griffith