Replacing an existing file or document changes the document Url - Bugs & Issues - Bugs & Issues - Progress Community

Replacing an existing file or document changes the document Url

 Bugs & Issues

Replacing an existing file or document changes the document Url

  • Replacing an existing file or document changes the document Url
  • This is new in SF 9, first I thought it's a bug because the behavior did not exist in my previous version (SF 7) but I got it confirmed by Telerik that it's not a bug and it's done by design.

    Long story short, when you replace an existing file or document, if the name of the new file is different than the one already uploaded on the website, then Sitefinity 9 changes the Url of the file/document based on the new file name.  

    Example: is your current document Url, when you replace this document with a file with a different name, let's say "agenda_feb_08.pdf" then the document Url changes to and all the references to the old Url will be broken, the old Url stops working without a fallback solution or a redirect. 

    This change in design is not a good practice at all and it was not communicated.  Is there anyone else being effected by this?


  • I only upgraded to the latest version recently and did not notice the change yet. Sounds like bad design. URLs should never change unless specifically asked for.  Changing it is bad for SEO and user experience in general. Seems like the Sitefinity SEO expert has not been consulted on this one.
  • This should be fixed. It might be done by design but that does not mean it makes sense. Mistakes need to be fixed :-) Is there a bug report I can vote on?
  • 3be2551e-37c1-6deb-a958-ff0000446526_replace_docs.jpg

    I can't agree more.  

    So after you replace a document the Url changes but the "Allow multiple URLs" is still pointing to the old Url which is not active anymore (screenshot attached) enabling the checkboxes basically does nothing.

    Also, as you can see in the screenshot, the URL stays intact but the URL to file changes which it does not make any sense. (Btw, just to be clear, I replace a file named brochure.pdf with 2017-Web-Catalog.pdf)

  • Ok, thanks. Please share the URL once you filed it.

    I was told it was changed to allow different file names for multilingual documents (, but that is no reason to change the URL on each document update. It was a bad decision and now unfortunately it consumes everybody's time.

  • They should've also thought about those customers that are not using the multilingual feature and the documents that are already established by Google crawlers.  I don't get it, how something this simple has been overlooked?

    By the way, I found this, when I read the explanation it still doesn't make sense to me:

  • Support is telling me to file a feature request to correct this bad design decision. Did you file one? If so I will vote for it.
  • I just heard back from Telerik's Dev team, doesn't sound there's a fallback solution and this change in "design" was made in Sitefinity 9. 

    I have not filed a feature request yet, but I will.

  • Hi Marz, 


    Can you use a 301 Redirect to work around the issue?  Forget about the multiple urls and instead control it with the 301?   

  • I just recently upgraded to Sitefinity 9 and discovered this issue. THIS IS A TERRIBLE DESIGN DECISION. We have hundreds, if not thousands of files, stored in Sitefinity and this is a huge issue.


    I'm going to have to tap into EventHub and fix this issue myself.

  • The issue is resolved in Sf 10.0.6402.0

    Now I have to do another upgrade. Great!

  • You have got to be kidding. They should release an update for version 9