Vote 590  points

Custom Button: Expose $Page in the URL Content Type

Salesforce Platform, Apex & Visualforce, Application Distribution, Customization

Under Point Threshold

One of our common uses for a Custom Button is to redirect the user to a VisualForce page, so all we need the button to be is a URL to the desired VisualForce page.
While this can be done by using a Custom Button with a Content Type of URL, creating the URL to go to the VisualForce page has to be done something like this:   {!URLFOR("../apex/MyPage", Campaign.Id, [parm1="A", parm2="B"])} 
The problem with this is that we produce a Managed Package (thus it has a namespace).  We do not do all of our new development directly on our Packaging Org, instead each developer has their own Development Org for doing new work, and we sync our code to a version control system.
This means that each developer's org does not have the same namespace as the package we release, so using the URLFOR method above means that a button that works on our Development Orgs will not work in our Packaging Org, and a button that includes the namespace will work on our Packaging Org but not our development orgs.
If we could use the $Page global variable in the URL field, it would hopefully get around that so that we could do something like this: {!URLFOR($Page.MyPage, Campaign.Id, [parm1="A", parm2="B"])} 
and system would be smart enough put the name space (if present) into the URL for us.

If your org is grandfathered in, you can do this with S-Controls, but it would be nice to have this small part of the feature gap between S-Controls and VisualForce closed by allowing programmatic access to VisualForce where we have programmatic access to S-Controls.

This problem only crops up when the VisualForce page you want to link to is a generic/dynamic page that supports being called from multiple objects.  In this case there's only 2 workarounds that I know of:
1. Create 2 buttons for each object that we want this button on: one with the Namespace that we do package and 1 without the name space that we use in our Development orgs.
Not ideal since it means we're using something different in development than what we're packaging and we'd have to esure that we test both, and we have to be sure not to accidentally package the developer version of the button.
2. Create a 2nd VisualForce page and instead of having a button of Content Type URL, have the button be a content type VisualForce page with a controller that uses the standard controller for the object we want to put the button on.  This Interstitial Visualforce page can then redirect on to the more generic Visualforce page.
Better, in that it avoids the namespacing issue, but now instead of creating an extra button per object, we're creating an extra page per object and introducing a delay in having that page process the input and redirect the user.

4 years ago · 8 Comments ·Merge Idea · Report Abuse

1 to 8 of 8



from AppExchange


Help us to keep IdeaExchange clean by pointing out overlapping ideas. We'll investigate your suggestion and merge the ideas if it makes sense.



Thanks for your merge suggestion. We will review it shortly and merge the ideas if applicable. takes abuse situations very seriously. Examples of abuse include but are not limited to posting of offensive language or fraudulent statements. To help us process your request as quickly as possible, please fill out the form below describing the situation. For privacy and security reasons, the final outcome of an abuse case may not be revealed to the person who reported it.


Thank you for your feedback. We take abuse seriously and will investigate this issue and take appropriate action.