Megan Perry-Thibault (Customer) asked a question.

Edited January 6, 2026 at 2:42 PM
15.4 Generating Links Incorrectly and Altering Them In the Backend

We have upgraded both of our development servers (test.website.com and edit.website.com respectively) from 14.4 to 15.4 and are running into a really weird two prong issue.

 

1) Our content authors have found that some document links are being generated incorrectly on the frontend side of the pages.

 

 

 

2) I have found that the links are being re-written back to the relative version no matter what I change them to.

  • I have rewritten these links using relative, full, or links to the documents directly on our production server (so https://website.com/docs-sf/provider/library/document.pdf rather than https://test.website.com/docs-sf/provider/library/document.pdf?sfvrsn=123_abc) the dev servers (test and edit) keep reverting the link back to the relative version. I've tried rewriting it directly in the HTML view and using SF's wysiwyg link tool, but both do the same thing.
  • test is on 15.4.8621 so I patched edit to 15.4.622 but the issue still occurs.
  • It is not the content just refusing to save changes as I have erased the links entirely, saved and published the content and it reflects the erasure as it should. Then I add it back fresh and it goes right back to the relative and generating incorrectly on the front end.
  • So far it seems to only be pdfs but it is not all pdfs and it seems like it is altering only the 1st document link in the block/list/etc, as there are several places where three documents in the same exact folder are linked but it is only the first one that is going screwy. BUT this is not consistent across all pages/content. It seems to be entirely random as to which pages have the issue.

 

The settings between all three servers should be that same aside from the CSPs as we cloned our production DB onto test and edit a few days before we ran the upgrades. So I am not sure why this is occurring. Any help/insight would be greatly appreciated. Thank you!

  • 6 answers
  • 120 views

  • Megan Perry-Thibault (Customer)

    UPDATE:

     

    While the issue itself is still present, we have discovered a work around.

     

    Per https://www.progress.com/documentation/sitefinity-cms/create-and-manage-links, with version 15.4.8622 and up there is an attribute you can add to anchor tags that will prevent it from appending the sfref information (data-skip-sfref="true").

     

    We have found adding that attribute to the broken links makes them render correctly.

     

    @Ian MacDonald (Customer)​ - This may help ya'll not have to go through the effort of creating short links to work around the issue. It seems to be working well for us thus far.

    Selected as Best

  • Stanislav Velikov (Progress Software)

    Hi,

     

    I suspect the problematic links are added to Sitefinity Content block widget.

    If this is so it is important to ensure all problematic links do include: SFREF attribute. Example of the attribute in a link to a document from content block.

     

    <a data-sf-ec-immutable="" data-sf-ec-document-immutable="true" href="https://www.sitefinitylocal.com/docs/default-source/documents/form-test-pdf-01z.pdf?sfvrsn=1868c793_1" title="Form-Test-PDF-01Z" sfref="[Telerik.Sitefinity.Libraries.Model.Document|OpenAccessDataProvider|9febd7c5-2ba1-412d-8625-23a2940ca273]bdd380ca-19bb-47cb-acec-bc63e63a4092">Form-Test-PDF-01Z</a>

     

    SFREF attribute takes care of Sitefinity always updating the url of the document when its url changes. This is the mechanism to eliminate 404/dead hyperlinks when using content on multiple pages and then changing urls.

    If SFREF attribute is missing then the document url must be manually typed into the content block, in this case best way to resolve is to re-add the document via the Add Document tool in the Content block widget, this will add SFREF and keep the document url always up to date.

     

  • Megan Perry-Thibault (Customer)

    Hi Stanislav!

     

    The issue is occurring in content blocks and lists and all the broken links include the SFREF.

  • Stanislav Velikov (Progress Software)

    Hi,

     

    Thank you for clarifying. Based on it I suspect the problem is not in the links, but the documents they link to. My suggestion is to choose one document with broken link. Go to Content -> Documents & Files module and run a test.

     

    Manually change the urls of this document and publish it, make a note of the original urls so in case the test bears no fruit to change back the document urls to what they were before the test. After publishing the document check if the content blocks which produced faulty urls now produce correct urls when browsing the page with content block on the frontend of the site.

  • Ian MacDonald (Customer)

    Hi Megan,

     

    We are seeing the exact same issue on that version of Sitefinity.

     

    We managed to work around it by using a URL shortener (like TinyURL) and adding them as external links. This prevents Sitefinity from altering them.

     

    I know it’s not ideal, but hopefully, it works as a stopgap until a patch is released.

  • Megan Perry-Thibault (Customer)

    UPDATE:

     

    While the issue itself is still present, we have discovered a work around.

     

    Per https://www.progress.com/documentation/sitefinity-cms/create-and-manage-links, with version 15.4.8622 and up there is an attribute you can add to anchor tags that will prevent it from appending the sfref information (data-skip-sfref="true").

     

    We have found adding that attribute to the broken links makes them render correctly.

     

    @Ian MacDonald (Customer)​ - This may help ya'll not have to go through the effort of creating short links to work around the issue. It seems to be working well for us thus far.

    Selected as Best