14

I have been experiencing very odd Site behavior the past 3 days. Whenever a Change Set is deployed with Controllers/VF Pages used in the Site or even at other "random" times, users are redirected to the "Under Construction" or 'Unauthorized" Pages. If I go to an affected Page internally via /apex/MyAffectedPage, the Page will then be available externally on the Site.

The Site's Active Home Page is never affected. If viewing a Page externally, and it redirects to Under Construction Page, visiting any other Page (except for the Site's Active Home Page) will redirect to Under Construction Page. But if I view a single Page internally, the Page will then be available externally, but every other Page (except for the Site's Active Home Page) will redirect to Unauthorized Page instead.

I went to "Preview as Admin" in the Site when I was getting redirected to the Unauthorized Page, and I think it was showing an "api is not accessible" message. I have to wait for the issue to occur again before I can confirm this.

If the issue strikes, I need to visit every Page used in the Site to have the entire Site available externally again.

This is terrible because we're finding out the issue happened when our clients complain our Site is down. I am adding custom Under Construction and Unauthorized Pages that will email us whenever it's viewed so we can cut our response time down, but I don't have the slightest clue on how to fix the issue altogether. Somehow viewing the Page internally is changing something in the Salesforce Back-end which allows the Page to be viewed externally. And what could be the trigger which resets the Page's external access?

About the "random" events causing the issue: They happen less than a few times a day, and the last event happened overnight. Maybe it was triggered when Salesforce was resetting the 24 Hour Site Usage Limit.

Additional Exceptions: The Site has been very buggy. I've ran into the "api is not accessible" Message every now and again over the past couple of days. I deployed a Change Set, visited all the Pages and verified it was externally available, and then, a couple hours later, I got a "Class needs to be Compiled" Exception with "api is not accessible" being the root cause. I clicked "Compile All Classes" under Setup --> Apex Classes, and the issue was resolved. I've hardly ever ran into that issue, and it seems very odd that now it happens with the other issue.


Update

On Friday, the Site was up and running fine all day. A minute ago, I checked the Site as an Admin, and I got the "Under Construction" Page. Since I was viewing the Site as an Admin, it displayed the error:

Entity is not api accessible

Screenshot of Under Construction Page with "Entity is not api accessible" error

I went to Setup --> Develop --> Apex Classes and clicked Compile All Classes. Then I checked the Site again, and every Page was up and running.

Everything was running fine Friday night. No Change Sets were deployed over the weekend. But Salesforce did use their Service Window Sunday morning...

Any ideas?


Another Update on 2015-08-03

Ran into this issue again this afternoon. I tried Compiling All Classes, but it didn't work this time. I had to go into each Page internally via /apex/... so the Page would be available externally.


Update for 2015-08-06

We ran into the Under Construction Error 2 out of the last 3 days. It seems to occur at most once a day unless we deploy a Change Set which always triggers the issue.


Update for 2015-08-23

The issue still occurs about once, maybe twice a day and then also every time we deploy a Change Set. We've been working with Salesforce Support for about two weeks, and the best idea so far is that the "Entity is not Api accessible" Exception occurs when the Site's Metadata are not all the same API Version. So, I updates all my classes and VF Pages to API v34.0, but the issue has still happened since then.

  • May or may not help you, but I've seen this error when the public sites user does not have access to one of the objects referenced in this page. – Ray Dehler Aug 4 '15 at 23:17
  • 1
    The Site Guest User Profile has full access to all Objects, Apex Classes, and Visualforce Pages. If we run into the error, and then we visit all Pages internally, a Site User can do everything on the Site externally. – Scott Pelak Aug 5 '15 at 2:06
  • Is there some custom button or a standard button overrided by a Visualforce page? – guest610 Aug 6 '15 at 13:25
  • Yes, every Site Page is a custom Visualforce Page which uses apex:commandButtons. When the Site is not "Under Construction", everything is in working order. – Scott Pelak Aug 6 '15 at 14:41
  • 1
    Try this: add the <site:previewAsAdmin /> component right before the closing </apex:page> tag in your custom Visualforce error pages to view detailed site error messages in administrator preview mode. – Tushar Sharma Aug 8 '15 at 5:31
5
+150

@Scott Pelak If you can try this thing. goto Setup>Sites>Click on your desired community site and goto "Site Visualforce Pages" Section, In standard exception Page you will find one line <apex:param value="{!$site.errormessages}" /> change this to <apex:param value="{!$site.errordescription}" />

So that you can see the Exact cause for error message there Instead of " Site Down For maintanance "

3

This took over a month to resolve, but we finally figured out what the issue was: the Site's Controllers were referencing a Class which referenced SObjectTypes that the User didn't have permission to. This caused a failure when trying to load the Class which resulted in an Entity is not api accessible Exception.

Every class on the Site referenced a base Class called Portals, and Portals referenced a Utility Class called Hri. In Hri, I had a Sub-Class called CloneExtension that could be used to clone a record and it's related lists by looping through it's Child Relationships. However, I had a set of Child-SObjectTypes that I wanted to exclude from the clone, so I explicitly made sure not to include any of the Restricted SObjectTypes.

On the Site, when Portals was loaded, the System also tried to load Hri. It was one (or many) of the SObjectTypes in Hri's restrictedSObjectTypeSet that the Public Site User didn't have access to which caused a failure resulting in an Entity is not api accessible Exception.

public Map<SObjectType, Schema.ChildRelationship> getChildRelationshipMap(){
    /**
     * Version 1.1:
     *      Created.  For each SObjectType in Child Relationship Set and in SObjectType's Describe's Child Relationships,
     *          puts the Child Relationship Name into childRelationshipMap.
     *      Returns childRelatioshipMap.
     */
    Set<SObjectType> restrictedSObjectTypeSet = new Set<SObjectType>{
        NoteAndAttachment.SObjectType,
        Attachment.SObjectType,
        Note.SObjectType,
        ActivityHistory.SObjectType,
        AttachedContentDocument.SObjectType,
        CollaborationGroupRecord.SObjectType,
        CombinedAttachment.SObjectType,
        ContentDocumentLink.SObjectType,
        ContentVersion.SObjectType,
        EntitySubscription.SObjectType,
        Event.SObjectType,
        FeedComment.SObjectType,
        FeedItem.SObjectType,
        OpenActivity.SObjectType,
        ProcessInstance.SObjectType,
        ProcessInstanceHistory.SObjectType,
        Task.SObjectType,
        TopicAssignment.SObjectType
    };
    Map<SObjectType, Schema.ChildRelationship> childRelationshipNameMap = new Map<SObjectType, Schema.ChildRelationship>();
    Set<SObjectType> childRelationshipSet = this.getChildRelationshipSet();
    for(Schema.ChildRelationship childRelationship : this.getSObjectType().getDescribe().getChildRelationships()){
        SObjectType sObjectType = childRelationship.getChildSObject();
        Boolean isWanted = childRelationshipSet.contains(sObjectType);
        Boolean isRestricted = restrictedSObjectTypeSet.contains(sObjectType);
        Object putResult = isWanted && !isRestricted ? childRelationshipNameMap.put(sObjectType, childRelationship) : null;
    }
    return childRelationshipNameMap;
}
  • 1
    This is where the lazy-loading pattern could be really useful in making your code less likely to break other parts of the system. Unless your Site actually needs to access these SObjectTypes. That part is not clear. – Adrian Larson Oct 5 '15 at 15:55
  • No, the Site doesn't need it at all – Scott Pelak Oct 5 '15 at 15:56
0

I just ran into this myself. The cause in my case was a reference to another Visualforce page with an underscore in its name.

  <apex:composition template="{!$Page.EIS_Template}">

Since the referenced page was the site template, the quickest fix was to designate it as the template on the site detail page (Setup > Develop > Sites > site-name) and change the reference to this:

  <apex:composition template="{!$Site.Template}">
0

I wanted to share I ran into this (well, similar) - I was getting the generic/default 'Error' Page from my Community site, consistently but only the first time when i clicked on certain hyperlinks. The fix was to change from

<a href="{!link}" target="_blank">{!name}</a>

To...

<lightning:formattedUrl value="{!link}" label="{!name}"/>

Took me a hot minute to make this determination, posting here as I hope it helps someone else.

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.