I ran into this particular bug when upgrading a client to Sitecore 8.2 update 2. Whenever a RichText block had both a link to a media document (like a PDF) and an anchor with no HREF the processing pipelines that update the HREF links would blow up. For those who may google it in the future, here are the details!
IMPORTANT UPDATE (2017-09-18): Thank you to Viktor who has pointed out that this is now fixed in 8.2 update 5!
Exception
18340 14:00:52 ERROR A rendering error occurred: Xsl file could not be processed (details: System.Xml.Xsl.XslTransformException: An error occurred during a call to extension function 'field'. See InnerException for a complete description of the error. ---> System.ArgumentOutOfRangeException: Length cannot be less than zero. Parameter name: length at System.String.Substring(Int32 startIndex, Int32 length) at Sitecore.Pipelines.RenderField.ProtectedImageLinkRenderer.ReplaceReference(String tagHtml, String urlAttribute) at Sitecore.Pipelines.RenderField.ProtectedImageLinkRenderer.HashReferences(String renderedText, String tagName, String urlAttribute) at Sitecore.Pipelines.RenderField.ProtectedImageLinkRenderer.Process(RenderFieldArgs args) at (Object , Object[] ) at Sitecore.Pipelines.CorePipeline.Run(PipelineArgs args) at Sitecore.Pipelines.DefaultCorePipelineManager.Run(String pipelineName, PipelineArgs args, String pipelineDomain) at Sitecore.Web.UI.WebControls.FieldRenderer.RenderField() at Sitecore.Xml.Xsl.XslHelper.field(String fieldName, XPathNodeIterator iterator, String parameters) --- End of inner exception stack trace --- at System.Xml.Xsl.Runtime.XmlExtensionFunction.Invoke(Object extObj, Object[] args) at System.Xml.Xsl.Runtime.XmlQueryContext.InvokeXsltLateBoundFunction(String name, String namespaceUri, IList`1[] args) at <xsl:template match="*">(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime, XPathNavigator {urn:schemas-microsoft-com:xslt-debug}current) at Root(XmlQueryRuntime {urn:schemas-microsoft-com:xslt-debug}runtime) at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer) at Mvp.Xml.Common.Xsl.MvpXslTransform.TransformToWriter(XmlInput defaultDocument, XsltArgumentList xsltArgs, XmlWriter xmlWriter) at Mvp.Xml.Common.Xsl.MvpXslTransform.Transform(XmlInput input, XsltArgumentList arguments, XmlOutput output) at Sitecore.Web.UI.WebControls.XslFile.DoRender(HtmlTextWriter output, Item item))
Cause
The ProtectedImageLinkRenderer looks for media links and updates the HREF with a correct value for output. The current code in this renderer, however, doesn’t know how to process an anchor tag that has no HREF attribute. You can reproduce this scenario with a clean vanilla install of Sitecore and the following markup in the rich text field of the default home page that is installed:
<p><a>Empty HREF</a></p> <p><a href="-/media/094AED0302E7486880CB19926661FB77.ashx">Media link</a></p>
Solution
An easy solution is to get rid of empty anchors in your content. However, you may not know how many of these anchors are in your solution. If you’ve upgraded from a previous version where this combination of anchors worked, you may not have the time or ability to clean up all the links.
Alternatively, you can patch the pipeline with your own version and add the following check in to escape the method for empty anchor tags:
//Handle empty tags if (!tagHtml.Contains(urlAttribute)) return tagHtml;
Affected versions
I tested this starting at 8.2 update 2 and going back to 8.0 Service Pack 1. Sitecore 8.0 and 8.1 seem unaffected, but 8.2 updates 1-4 will simulate this bug. It is corrected in 8.2 update 5.
Jay that github link doesn’t work. How can I get access to this fix. I have the same error
Thanks for the heads up Jonathan. I’ve updated the post to provide instructions to contact Sitecore Support with the number. Between the number and the GitHub repo link, hopefully you can get the same fix sent to you!
Hi,
You can add that the issue is fixed in 8.2-U5.
Thank you Viktor! I have updated the post to make sure it is clear that an upgrade to Update 5 will fix the issue!