I am developing a Visualforce page which will be rendered when a Salesforce User arrives by clicking a specific Account.

The Apex page looks something like this:


 <c:MyComponentToBeShownOnAccountView tab="Account" />


After placing this component I am able to pick this Visualforce Page from Edit Account Layout in the org and drop it as a section which I currently use for development.

But After customer installed the Managed Package my Visualforce Page doesn't appear in Visualforce Page section of the Edit Account Layout.

I did a quick fix for now by adding standardController="Account".

Now fixed page looks like:

<apex:page standardController="Account"> 

 <c:MyComponentToBeShownOnAccountView tab="Account" />


My Apex Controller class is implemented as a generic class which fetches the PageReference.get('id') of the page and finds the Custom Object through SOQL. So I am not inheriting the Account Controller and handling the Account request with a separate controller.

MyCompponentToBeShownOnAccountView class looks like:

<apex:component controller="GenericObjectHandleController">

I am just confused why the first code shows up on Developer but not on Enterprise, and also whether this quick fix will work across all Types of orgs.

Should I re-implement the controller by the way Salesforce recommends?

Does the problem happened due to mismatch between versions of Developer and Enterprise org?

  • It's Visual force not Visual Source Aug 28, 2013 at 11:00
  • 2
    Normally a VF page as a section of a page layout is only possible when the page is using standard controller with the appropriate object type. This prevents silly implementation errors ensuring someone doesn't put a page for Lead on a Contact page layout and vice-versa. I'm surprised you were able to get it to work in your DE org, to be honest.
    – pchittum
    Aug 28, 2013 at 14:56
  • @Daniel Thanks. Corrected in appropriate places. Din't notice till you pointed out that its Force and not Source. Aug 28, 2013 at 15:11

1 Answer 1


You shouldn't be able to add a page to a layout without the standardController entity matching the layout's entity. It sounds like a bug in your DE org.

You should indeed use the standardController attribute on your page, and I would further recommend passing the standard controller to the component instead of grabbing the ID parameter. I use a class that looks (almost exactly) like this:

public with sharing class StandardController {
    public ApexPages.StandardController standardController { get; set; }
    public StandardController(ApexPages.StandardController standardController) {
        this.standardController = standardController;

It's used in a page like this:

<apex:page standardController="Account" extensions="StandardController">
    <c:myComponent standardController="{!standardController}"/>

Most of my components therefore use custom getter/setter methods, since it reduces my component's constructor to uselessness, but I consider it a worthy sacrifice, as I can then access the standard controller's PageReference's directly, such as cancel, view, and save.

public with sharing class myCompController {
    public ApexPages.StandardController controller {
        get; set {
            if(controller!=null) return;
            // do my component initialization here.

The standardController method works in all types of orgs. Not providing a standardController attribute is not supported and shouldn't work, so you should never rely on it working.

  • I think there is a bug in DE org. I couldn't replicate the same scenario in my partner DE org since I don't have Accounts enabled (creating a new case may resolve this). The above approach is much cleaner. Thanks Sep 6, 2013 at 6:44

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.