New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Item field is "$name" #15

Closed
klinden opened this Issue Feb 1, 2013 · 10 comments

Comments

Projects
None yet
4 participants
@klinden

klinden commented Feb 1, 2013

After publishing an item there is a short window of time (anywhere from 1-10 minutes) during which sometimes an item displayed on my site will have "$name" in a particular field (which is the StandardValues value for the field). I'm assuming this has something to do with the period of time in which the index is being rebuilt, but it still seems odd to me as my code is actually reading the real item, not the SkinnyItem.

http://pastebin.com/1GaKN9ek - Configuration
http://pastebin.com/n9bnBw72 - Item retrieval

@enordberg

This comment has been minimized.

Show comment
Hide comment
@enordberg

enordberg Feb 1, 2013

Is it possible that your item is publishing, but the version is not yet published? In that case, the search might be finding the item without a version.

I have seen similar issues, but not related to search directly. Where I've seen it, it tends to be from one of the following:

  • Workflow prevents an item version from being published, though the item is published.
  • Multiple languages exist and some languages do not have item versions.

If this is the case, it might work to check for item==null or item.Versions.Count==0. That should detect an empty item version.

I hope this helps. thanks,
Eric

enordberg commented Feb 1, 2013

Is it possible that your item is publishing, but the version is not yet published? In that case, the search might be finding the item without a version.

I have seen similar issues, but not related to search directly. Where I've seen it, it tends to be from one of the following:

  • Workflow prevents an item version from being published, though the item is published.
  • Multiple languages exist and some languages do not have item versions.

If this is the case, it might work to check for item==null or item.Versions.Count==0. That should detect an empty item version.

I hope this helps. thanks,
Eric

@klinden

This comment has been minimized.

Show comment
Hide comment
@klinden

klinden Feb 1, 2013

Thanks, this is helpful. In the particular instance this morning, though, my content editor was approving version 2 of an item so worst case I would have thought version 1 would have been retrieved instead of version 2. I could put in a check for item.Fields["Title"].Value != "$name", but I'd really like to get to the core of the problem so I don't have to put this "hack" everywhere I use indexing. Sounds like it might be a Sitecore problem though not a problem with this module. I'll try submitting a support ticket and see if I can get them to help :)

klinden commented Feb 1, 2013

Thanks, this is helpful. In the particular instance this morning, though, my content editor was approving version 2 of an item so worst case I would have thought version 1 would have been retrieved instead of version 2. I could put in a check for item.Fields["Title"].Value != "$name", but I'd really like to get to the core of the problem so I don't have to put this "hack" everywhere I use indexing. Sounds like it might be a Sitecore problem though not a problem with this module. I'll try submitting a support ticket and see if I can get them to help :)

@enordberg

This comment has been minimized.

Show comment
Hide comment
@enordberg

enordberg Feb 1, 2013

The best resources I have seen on this issue are from the language Fallback module. That module checks for items without language versions and substitutes the fallback version.

This might help if you do end up digging into the code behind this: http://marketplace.sitecore.net/en/Modules/Language_Fallback.aspx.

enordberg commented Feb 1, 2013

The best resources I have seen on this issue are from the language Fallback module. That module checks for items without language versions and substitutes the fallback version.

This might help if you do end up digging into the code behind this: http://marketplace.sitecore.net/en/Modules/Language_Fallback.aspx.

@klinden

This comment has been minimized.

Show comment
Hide comment
@klinden

klinden Feb 1, 2013

Thanks for the insight. We only have a very small handful of items in our solution that have more than one language and none of them are the items that are causing problems so I'm not sure this will help this particular issue.

klinden commented Feb 1, 2013

Thanks for the insight. We only have a very small handful of items in our solution that have more than one language and none of them are the items that are causing problems so I'm not sure this will help this particular issue.

@klinden

This comment has been minimized.

Show comment
Hide comment
@klinden

klinden Mar 7, 2013

Turns out this actually is a bug with the module. After a pretty extensive back and forth, one of the support techs at Sitecore was able to figure this out. Alex, I'm not sure if you can see support tickets or not, but the ticket in reference is 381588. Basically, there's a line of code in the SearchHelper class which needs modified that deals with how the item's URI is retrieved. See the full Sitecore response by Ivan Domashchenko below:

I investigated the code and found a potential cause.

According to the code, items are retrieved from the web database corresponding to item URI’s. These URI’s are stored in the indexes, each of these URI’s contains an ID of an item, a language and a specific version(!).
During auto publishing, a previous version of an item was deleted and a new was published. Since the process of index updating was not finished (or even started), the indexes still contain URI’s that refer to previous versions and every time when you refresh a page, the code renders versions of items that don't exist.

As a result, you see the standard values of this item until the indexes are not updated.

Please modify the code of the GetItemsFromSearchResult method of the SearchHelper class and try to reproduce the issue:

public static void GetItemsFromSearchResult(IEnumerable searchResults, List items, bool showAllVersions)
{
foreach (SearchResult result in searchResults)
{
Field field = result.Document.GetField(BuiltinFields.Url);
if ((field != null) && !string.IsNullOrEmpty(field.StringValue()))
{
ItemUri itemUri = new ItemUri(field.StringValue());
itemUri = new ItemUri(itemUri.ItemID, itemUri.Language, Sitecore.Data.Version.Latest, itemUri.DatabaseName);
SkinnyItem item = new SkinnyItem(itemUri);
...
}
}
}

klinden commented Mar 7, 2013

Turns out this actually is a bug with the module. After a pretty extensive back and forth, one of the support techs at Sitecore was able to figure this out. Alex, I'm not sure if you can see support tickets or not, but the ticket in reference is 381588. Basically, there's a line of code in the SearchHelper class which needs modified that deals with how the item's URI is retrieved. See the full Sitecore response by Ivan Domashchenko below:

I investigated the code and found a potential cause.

According to the code, items are retrieved from the web database corresponding to item URI’s. These URI’s are stored in the indexes, each of these URI’s contains an ID of an item, a language and a specific version(!).
During auto publishing, a previous version of an item was deleted and a new was published. Since the process of index updating was not finished (or even started), the indexes still contain URI’s that refer to previous versions and every time when you refresh a page, the code renders versions of items that don't exist.

As a result, you see the standard values of this item until the indexes are not updated.

Please modify the code of the GetItemsFromSearchResult method of the SearchHelper class and try to reproduce the issue:

public static void GetItemsFromSearchResult(IEnumerable searchResults, List items, bool showAllVersions)
{
foreach (SearchResult result in searchResults)
{
Field field = result.Document.GetField(BuiltinFields.Url);
if ((field != null) && !string.IsNullOrEmpty(field.StringValue()))
{
ItemUri itemUri = new ItemUri(field.StringValue());
itemUri = new ItemUri(itemUri.ItemID, itemUri.Language, Sitecore.Data.Version.Latest, itemUri.DatabaseName);
SkinnyItem item = new SkinnyItem(itemUri);
...
}
}
}

@alexshyba

This comment has been minimized.

Show comment
Hide comment
@alexshyba

alexshyba May 5, 2013

Owner

Thanks guys!
@klinden, I've fixed the issue in SkinnyItem.GetItem() method, see my comment here: 5964598

Owner

alexshyba commented May 5, 2013

Thanks guys!
@klinden, I've fixed the issue in SkinnyItem.GetItem() method, see my comment here: 5964598

@alexshyba alexshyba closed this May 5, 2013

@rhamille

This comment has been minimized.

Show comment
Hide comment
@rhamille

rhamille Nov 13, 2013

Hi Alex,

We are experiencing the exact same issue although we are already using the latest code.

Anything else that I should be checking?

Thanks!

rhamille commented Nov 13, 2013

Hi Alex,

We are experiencing the exact same issue although we are already using the latest code.

Anything else that I should be checking?

Thanks!

@ghost ghost assigned alexshyba Nov 13, 2013

@alexshyba

This comment has been minimized.

Show comment
Hide comment
@alexshyba

alexshyba Nov 13, 2013

Owner

Indeed, it looks like there is another bug in SearchHelper. Looking into it.

Owner

alexshyba commented Nov 13, 2013

Indeed, it looks like there is another bug in SearchHelper. Looking into it.

@alexshyba alexshyba reopened this Nov 13, 2013

alexshyba added a commit that referenced this issue Nov 13, 2013

@alexshyba

This comment has been minimized.

Show comment
Hide comment
@alexshyba

alexshyba Nov 13, 2013

Owner

Should be fixed now. Please report if the problem does not go away.

Owner

alexshyba commented Nov 13, 2013

Should be fixed now. Please report if the problem does not go away.

@alexshyba alexshyba closed this Nov 13, 2013

@rhamille

This comment has been minimized.

Show comment
Hide comment
@rhamille

rhamille Nov 15, 2013

Thanks Alex! Looks ok on my local and waiting for the code promotion to our UAT server.

rhamille commented Nov 15, 2013

Thanks Alex! Looks ok on my local and waiting for the code promotion to our UAT server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment