Glass Mapper not mapping some item properties - sitecore

Question

(I'm using Sitecore 8.1 Update 3 with Glass Mapper.Sc version 4.1.1.66)
I've run into an issue where some of the properties of a Sitecore item are not being populated in code through Glass Mapper. The values in our Content Base item (Id, Name, Display Name, typical Sitecore fields) seem to be getting populated correctly, but the child item's fields (I'll call it Overview) aren't mapped at all. They're all strings but they all end up null, even though the Content Base's values look to be correct. We also have child class maps working in other areas of the same, so that may not be the cause here.
Earlier in this project, we had an issue with Glass Mapper where field names that included spaces were not being read. However, I've made sure to leave out any spaces in field names, but this doesn't solve the issue.
Another possible contributor to the issue is that we have multiple languages on the site, so it's conceivable that language fallback may be complicating things. However, we have fallback enabled and working properly across the site without issues.
I can post code if needed, but for the most part, it's just POCO's and mapping classes.
Any ideas on what other parts I should be looking into?

Answer 1

You need to use the VersionCountDisabler(), you can find more details about it in this previous question and this blog post.
The use of the disabler is not supposed to be required on Sitecore 8.1 and when using Language Fallback, but I can confirm that this is an issue and using the VersionCountDisabler() solved the issue for us.
Internally Glass will check if a version of an item exists, if not it returns null. It seems that Sitecore will return a version count for Items with Layout, but not for datasource Items.
We have wired out the disabler slightly different than using the global.asax file, instead patching into the http request pipelines:
using Glass.Mapper.Sc;
using Sitecore.Pipelines.HttpRequest;
namespace MyProject.Custom.Pipelines.HttpRequest
{
public class ItemVersionCountDisablerBegin : HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
Sitecore.Context.Items["Glass::VersionCountDisabler"] = new VersionCountDisabler();
}
}
public class ItemVersionCountDisablerEnd : HttpRequestProcessor
{
public override void Process(HttpRequestArgs args)
{
VersionCountDisabler disabler = Sitecore.Context.Items["Glass::VersionCountDisabler"] as VersionCountDisabler;
Sitecore.Context.Items["Glass::VersionCountDisabler"] = null;
disabler?.Dispose();
}
}
}
And then patch this into http request begin and end pipelines:
<pipelines>
<httpRequestBegin>
<processor type="MyProject.Custom.Pipelines.HttpRequest.ItemVersionCountDisablerBegin, MyProject.Custom" patch:before="*[1]"/>
</httpRequestBegin>
<httpRequestEnd>
<processor type="MyProject.Custom.Pipelines.HttpRequest.ItemVersionCountDisablerEnd, MyProject.Custom" />
</httpRequestEnd>
</pipelines>

Answer 2

After some experimentation, I found the cause of the issue.
In my mapping class, you'll see this line:
config.Field(f => f.HeaderPrefix).FieldName("AssetOverviewContentHeaderPrefix");
The field name seems kinda long, right? We were prepending the category name onto the field name in order to avoid any duplicate names in items since we do a fair amount of inheritance.
That's where the problem lies. When I removed the "AssetOverviewContent" from the field names, everything worked fine. Based on this, I did some more experimentation.
I found that field names up to 23 characters long worked just fine. 24 or more and they won't map. I have no idea why this number in particular is the limit, but my guess is that there's some other mapping going on somewhere that's hitting a limit.
A little more experimentation also found that mapping using FieldId also doesn't work. Guids are going to be more than 23 characters long, so that makes some sense. However, you can't really do a guid in less than 23 characters so I can't confirm.
I may end up looking at the Glass Mapper code sometime soon to see if I can track down the answer. But now that I know there's a problem, I can avoid it.