Visualforce page not listed when overriding Tab.

edited June 25, 2020 in Questions
I'm following this tutorial
And I created a VF Page 'RamoTab' with the code:

<apex:page standardController="alas1__Ramo__c" recordSetVar="c" extensions="skuid.Redirects" action="{!redirect}?page=RamoTab">

But when trying to override the default Tab (Step 8 of the link) my page is not listed. If I try to override the List instead of the Tab I do get the page listed. What am I missing?

Consider that: I'm on an org with namespace 'labs01' which has Skuid installed and my 'alas1' managed package as well. The VF page 'RamoTab' is under 'labs01' namespace.


  • Emily DavisEmily Davis ✭✭✭✭
    edited March 2, 2017
    Hi, Sebastian,
    Are you trying to override the tab for the alas1__Ramo__c object? The object whose tab you are overriding has to match the standardController object in your Visualforce code.
  • edited June 25, 2020
    The issue here has to do with the Managed Packages. Here's the deal:

    From your org that has the "labs01" namespace, to override the Tab action for an object included in the "alas1" Managed Package, you have to NOT specify a Standard Controller. Rather, change the redirect override syntax to be:

    <apex:page controller="skuid.Redirects" action="{!redirect}?page=RamoTab"/>

    Moreover, you will not be able to override actions of any other type for objects in the "alas1" managed package, from the "labs01" org.  This is a very annoying restriction that Salesforce has in place for overrides, preventing you from overriding actions of objects that come in managed packages.
  • edited September 2, 2014
    You're correct. That is what I'm trying to do. The object name is alas1__Ramo__c as in the VF code.
  • edited September 2, 2014
    Thanks Zach. The VF page is now listed and can be selected as an override for the alas1__Ramo__c object tab.

    There's still an error when rendering the page:
    You've been INKED! (Something went wrong)
    Skuid was unable to redirect the user to standard Salesforce Page Layouts, and no Skuid Page could be used instead.
    And by
    you will not be able to override actions of any other type for objects in the "alas1" 
    What other actions do you mean? So far I have accomplished to override New, Edit and View actions in the same alas1__Ramo__c object.

    Furher notes:
    The whole scenario is this: we have a Salesforce app to be distributed through Trialforce only. We have a developer org and a packaging org. Since we are testing Skuid to see how it fits our goals, I used an old org (the one with the "labs01" namespace) to install Skuid and our managed package to test it out; but I'm starting to believe it would be better if we test it in a clean org (no namespaces) and deploy our app through ant from our developer org (no alas1 namespace either).
    Will this be a better environment for our purposes?
  • edited December 21, 2016
    Try either (a) swapping the ?page= for an &page= in the override, like this:

    <apex:page controller="skuid.Redirects" action="{!redirect}&page=RamoTab"/>

    or using the Skuid Page component approach:

    <apex:page readonly="true" doctype="html-5.0">
       <skuid:page page="RamoTab"/>

    Regarding your scenario, I'd avoid the hassle of setting up a fresh org, you should be able to test out Skuid pretty well using your current approach, and if you decide to make the jump and have your core managed package depend on Skuid, then at that point you can move your override VF pages into your packaging org.

  • edited September 2, 2014
    The ampersand worked well.
    Thanks for sharing your opinion as well. So the namespace "labs01" shouldn't interfere with our testing? I thought the source of this issue I'm posting was the namespaces.
  • edited December 21, 2016
    The only part of your testing it will interfere with is in creating Visualforce override pages, which is not necessary to do if you're justing testing out the functionality of Skuid, in my opinion.
  • edited September 2, 2014
    Thank you.
  • edited September 30, 2014
    I know this is old but to tie up what Zach was saying with how this ended is that, in the DE org it looks like you might be able to do multiple overrides, but once the package is installed it looks like Zach's comment about not being able to do multiple will apply.
  • Pat VachonPat Vachon 💎💎💎
    edited January 19, 2016
  • Anna WiersemaAnna Wiersema 🛠️ 
    edited January 19, 2016
    Implemented! Let me know how it looks... I tried to be as straightforward as possible (thank you, Zach)  The main change is the section Special considerations for managed packages.
  • Pat VachonPat Vachon 💎💎💎
    edited January 19, 2016
    Can page assignments still be used?
  • Anna WiersemaAnna Wiersema 🛠️ 
    edited January 19, 2016
    Yes! There are so many permutations! On that bright shiny future day when we overhaul documentation, this will be presented in a better manner.  In the mean-time, I'm adding it to that tutorial.  

    For now, the best tutorials for page overrides (in terms of getting a broad scope of what you can do) are the overview/ cheat sheet and the one on the skuid:page component  one (you may have already realized this).
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!