13

We just noticed an issue today with some links we had on our Force.com site where some links to download some PDFs (stored as Documents in SF) were broken in our test environment (Winter '14) but not on production (still Summer '13)

The code looks something like this:

<apex:outputLink value="/mySite/servlet/servlet.FileDownload?file={!consentFormId}&oid={!$Organization.Id}"
styleClass="standard-blue-button" target="_blank">
{!$Label.lnk_PrintConsentForm}
</apex:outputLink>

In production, the link is fine, but in our staging environments, it seems like Winter '14 is automatically adding in the site prefix, even though I didn't ask it to, so I end up with /mySite/mySite/servlet/....

Anybody else experiencing this?

PS - didn't find anything in the release notes related to outputLink or site prefix.

EDIT: clarification on this....the original bug that raised this issue for us was that we have two separate sites that use the same code base, and the hard coded "/mySite/" url was working fine for the one site, but for the other, Salesforce was throwing in "/mySite2/mySite/..." This behaviour was seen in both environments, so it wasn't a Winter '14/Summer '13 issue, but rather it worked in one site but not the other because of the hard coding.

The issue is that SF appears to be parsing the outputLink's value attribute and massaging it if it thinks there's an error in there, like not having the right site prefix, so it throws it in there for you. Appears to be an undocumented feature for outputLink.

This can be avoided all together by using the solution in the answer below. (at least for my particular scenario, see comments)

1 Answer 1

11

Try the following change:

<apex:outputLink value="{!URLFOR($Action.Document.Download,consentFormId,[file=consentFormId,oid=$Organization.id])}" styleClass="standard-blue-button" target="_blank">
{!$Label.lnk_PrintConsentForm}
</apex:outputLink>

This should construct the correct URL in all cases (including internal pages, etc).

8
  • With one exception: URLFOR doesn't add the oid (org id) param to the download link, so it doesn't work in VF Email Templates, since the link will be clicked outside of a logged in session. Oct 5, 2013 at 13:53
  • Email templates are generated on the server, not in the email client, so it should work there as well; outputLink renders itself as an "A" HTML tag.
    – sfdcfox
    Oct 5, 2013 at 15:19
  • The issue is that the link generated will contain the doc id, but not the orgid; you will click the link from the email client. I have recently tested using URLFOR($Action.Document.Download, ...) as an alternative to manually constructing an image view URL(e.g., /servlet/servlet.ImageServer?...) in a VF Email Template; the resulting link only works if I'm already logged into the org. Oct 5, 2013 at 15:24
  • That's not the case... it's something else going on. Is the URL /servlet/servlet.FileDownload or /servlet/servlet.ImageServer? One is internal use, the other external.
    – sfdcfox
    Oct 5, 2013 at 15:25
  • 1
    For the record, I got a response back from Salesforce, and it looks like an undocumented feature of the apex:outputLink is that it parses the "value" attribute and it will look for the appropriate site prefix. If it doesn't find it, it will try and be helpful by adding it in certain scenarios. Also, I added a clarification to the original post, this turned out to not be a Winter '14/Summer '13 issue.
    – Stephen
    Oct 7, 2013 at 15:28

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.