Currently, I'm working on overriding standard pages to visualforce on case object which has different record types.

My problem is overriding standard layout to custom vf page for record detail page.

I don't want to use the detail tag because I need to customize the details and I need related lists with hover links.

Please guide me is there any way to achieve this.

My Code:

<apex:page standardController="case" extensions="Risk_Alignment" standardStylesheets="true">
<style type="text/css">

 <apex:sectionHeader title="{!$ObjectType.Case.label}" subtitle="{!case.casenumber}" printUrl="Print" help="Help for this Page"/>
 <button id="myButton1" class="btn" onclick="myFunction()" >Show</button>
function myFunction() {
    var x = document.getElementById('myDIV');
    var y = document.getElementById('myButton1');
    if (x.style.display === 'none') {
        y.innerHTML = 'Hide';
        x.style.display = 'block';        
    } else {
        y.innerHTML = 'Show';
        x.style.display = 'none';
<div id="myDIV" style="display:none">
<chatter:feed entityId="{!$User.Id}" />
<apex:pageBlock title="Case" mode="view">
   <apex:pageBlockButtons styleClass="false" >
   <apex:form >
   <apex:commandButton styleClass="false" value="Save" action="{!save}"/>
   <apex:commandButton value="Save & Close" action="{!save}"/>
   <apex:commandButton value="Save & New" action="{!save}"/>
   <apex:commandButton value="Cancel" action="{!cancel}"/>
  • 1
    I've done this before by keeping apex:detail and using jQuery to hide/insert portions of the SFDC-generated detail page DOM.
    – cropredy
    Commented May 9, 2019 at 21:03
  • Sounds interesting. Could you please elaborate a little more it would be very helpfull
    – Pavan tej
    Commented May 10, 2019 at 23:49

1 Answer 1


So, here's an example of some jQuery that hides sections of an OrderItem detail page (Classic) based on the recordtype of the parent Order.

<apex:page id="OrderProductDetail" standardController="OrderItem">
<!-- OrderProduct doesn't support record types so we can't have a Pre-shopify vs post-shopify layout
    Use jQuery to change css on sections not relevant for Shopify orders

<apex:includeScript value="{!$Resource.jQuery331Min}"/> 

 $j = jQuery.noConflict(true);       //  return globally scoped JQuery variables to first version loaded, if any
 var orderProductDetailApp = {};
 $j(function() {                 //  jQuery shorthand for $(document).ready(function() ..  Wait until page loads 
     //  define the application

     (function(app) {            //  Define anon function
         //  --------------------------
         //  init:   do initializations
         //  --------------------------
         app.init    = function() {

         //  -----------------------------------
         //  hidePreShopifySections:  hack to hide pre-Shopify sections using css display:none
         //  -----------------------------------
         app.hidePreShopifySections = function() {
             // if parent Order recordtype.DeveloperName = 'Shopify' ....
             // then apply css:none to all PageblockSections with '(pre-Shopify)'  or '(Retired)' in title
             //     first selector: h3 w/ name attribute matching pattern
             //     second selector: parent - the pageblockSection header

             //     then repeat but with second selector .parent().next() - the pageblock section fields

             var filterPattern0 = 'pre-Shopify';
             var filterPattern1 = 'Retired';
             // Fragility note:
             // 1 Assumes that section labels contain matching strings
             var orderRecordTypeDevName =  '{!OrderItem.Order.RecordType.DeveloperName}';
             if (orderRecordTypeDevName == 'Shopify') {

                 $j("h3:contains(" + filterPattern0 + ")").add("h3:contains(" +filterPattern1+")")
                        .parent().css('display','none');   // clear pageblocksectionHeader
                 $j("h3:contains(" + filterPattern0 + ")").add("h3:contains(" +filterPattern1+")")
                        .parent().next().css('display','none'); // clear fields

                 // hide the related list for custom object Order-Event_Item__c
                 //     <div class="listRelatedObject customnotabBlock"
                 //         ... many elements nested
                 //         <input value="New Order Event Item ..."  only clue we have to which related list to hide
                 //         ...
                 //     </div>
                 $j("input[value='New Order Event Item']")
                      .closest("div .listRelatedObject").css('display','none');

         };                                         // end hidePreShopifySections

         app.init();            // Anon function invokes its own init function
     }) (orderProductDetailApp);        // Execute anon function passing in an object representing our application

<apex:outputPanel id="detail" >
    <apex:detail subject="{!OrderItem.Id}" inlineEdit="true"

So, what does this example illustrate:

  • It uses apex:detail so all the built-in features of apex:detail are available - inluding related lists, related list hover, and inline edit.
  • It hides pageblocksections that aren't relevant based on the recordtype of the parent `Order object
  • It hides a related list that also isn't relevant based on the parent Order recordtype
  • No controller extension required

BUT -- it is fragile as it relies on DOM inspection for specific patterns that can be easily broken through inadvertent changes in the OOTB Lightning UI setup actions in Edit Page Layout


  • Inspect the DOM using Firefox or Chrome developer tools,
  • Brush up on your jQuery selectors
  • Approach the problem incrementally, getting your jQuery to work in pieces
  • Comment liberally so the next admin maintaining this knows what you were doing

You can do a lot with jQuery as you have total control over DOM manipulation. You could move sections around, hide sections, hide individual fields; insert new fields (cloning DOM elements is best for this). If doing this in Classic, given that VF for classic is not likely to change, you "probably" will not be subject to SFDC changing the DOM from underneath you - YMMV.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .