mikeedwards83 / Glass.Mapper

Version 5 of the Glass mapping framework, the best ORM for Sitecore.
Apache License 2.0
124 stars 120 forks source link

Possible rendering issue? Link.aspx in Rich Text #326

Open cubeberg opened 6 years ago

cubeberg commented 6 years ago

Occassionally, after a server has been online for a few days - we start seeing Rich Text fields not expanding links - so we see a href="~/link.aspx?_id=431B60A4F58C40E8A5FD592E3139EC5A&_z=z" instead of the friendly URL. It's like the rich text is coming directly out of the database. It seems to get stuck like this until the app pool is reset. Clearing cache didn't fix the problem.

I've been trying to get some assistance from Sitecore. They provided a diagnostic dll to log a message during the RenderField pipeline if the links weren't expanded. It's happening on one of the environments with the logging - but oddly nothing is being logged.

Sitecore is 8.2R0, Glass.Mapper version 4.4.0.199 (recently upgraded, was seeing this earlier as well)

cubeberg commented 6 years ago

Based on some additional research, it looks like until the Application Pool was reset - the renderField pipeline wasn't running at all. We've been having this issue for a while, but recently added a custom processor to renderField that stopped working at the same time.

mikeedwards83 commented 6 years ago

Hi

The render field pipeline is only called for Rich Text fields by Glass. To determine if the field should go via the render field pipeline Glass uses this logic:

https://github.com/mikeedwards83/Glass.Mapper/blob/master/Source/Glass.Mapper.Sc/DataMappers/SitecoreFieldStringMapper.cs#L77

You should check to see what TypeKey is being returned by Sitecore when the server stops rendering the fields properly. Additionally you should check to see if other parts of the rich text field are being replace correctly, e.g. images.

jorrit commented 5 years ago

I have a custom rich text field. The TypeKey of the default rich text field seems to be hard coded and the algorithm that determines if a field is rich text can't be configured. Would it be an acceptable change to make the type keys of rich text fields configurable?

Also, currently the only check that is used to determine is field.TypeKey == RichTextKey. This is quite cheap to execute. Why cache this in a dictionary?