8

Sitecore has a number of encodeNameReplacements in config OOTB, I fully understand what they are and what they do since I have previously posted about it.

The issue we have is we have a number of compressed (software) files, which are of the format filename-something.tar.gz. By default, when the files are uploaded Sitecore takes only the last part of the file (.gz) as the extension and then see's the dot in the rest of the filename (filename-something.tar) and this fails default ItemNameValidation regex (at this point the file is internally renamed to filenamesomethingtar.gz instead of a complete failure, but still not acceptable to us). Following a Sitecore Support ticket we updated this setting to allow dots in the filename...

The issue is the encodeNameReplacements kick in:

<encodeNameReplacements>
  ...
  <replace mode="on" find="." replaceWith=",-d-,"/>
  ...
</encodeNameReplacements>

With this in place, the media url is being generated as filename-something,-d-,tar.gz

I could remove this replacement, but is this likely to raise other issues elsewhere in Sitecore backend?

EDIT:

We are running Sitecore 8.1 Update-3

As I said, I understand how the encoding and decoding works and the ,-d-, is set by the encodeNameReplacement setting I mentioned (which also applies to media url generation since Sitecore 7.2). But some of these values are valid URL characters. I can only assume they were added for a particular reason in the first place, namely to get around some issues in the back-end system. Removing this setting will require extensive testing of standard Sitecore features which we would like to avoid. I'm confident nothing in our own code will not break, not so much about Sitecore's so am trying to understand this so we can minimize issues.

  • How are you uploading these files? From sitecore package installer? – scFootsteps Oct 19 '16 at 1:50
4

From what I can find - the encodeNameReplacements are only used in MainUtil.DecodeName, MainUtil.EncodeName and MainUtil.EncodePath - These are used in both resolving url's and building them. So if the encoding is not there or if it encoded to something different it should still work ok. I could not find anything that explicitly set ,-d-, in the Url. Everything goes through one of those 3 methods.

If you go with removing the encoding completely and are running v7.2u1 or earlier, you may need to set the relaxedUrlToFileSystemMapping attribute to true so that IIS doesn't try to map it to a valid Windows file path. This was updated in v7.2u2 and later.

<httpruntime relaxedUrlToFileSystemMapping="true" />
  • As I said, I understand how the encoding works and the ,-d-, is set by the encodeNameReplacement setting I mentioned. But some of these values are valid URL characters. I can only assume they were added for a particular reason in the first place, namely to get around some issues in the backend system. Can you provide details why instead of just saying "it should be ok" – jammykam Oct 18 '16 at 17:45
  • We are running Sitecore 8.1 update-3 btw, question updated. – jammykam Oct 18 '16 at 17:47
  • 1
    Well Sitecore came back and the change affects only url generation and resolving, they are not aware about other side effects when removing this replacement. So I guess this is as good an answer as I will get. We'll be doing further testing in this so will update if we find any issues. – jammykam Oct 21 '16 at 10:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.