11.06.2020 05:43:57 (8 weeks ago)

Fix for broken remote greenstone server, which wouldn't load collections in any site. Turns out this was because the opotiki interface based on the customization tutorials materials did not have a div with id=gs_content where the /page content would go. As a result, ServletRealmCheck?, which sends off a authentication-ping request with an excerptid=gs_content got nothing back as there used to be no element with id gs_content in this interface. So no user groups were returned for a user by ServletRealmCheck?. This means no collections created by a remote user were found and loaded for that user into client-GLI. One line fix, but caused one huge headache to locate the cause. Is it compulsory for the div containing the actual page content to have id=gs_content, or is another solution better? For now going this route as it's a single change, moreover in an xsl file so no recompiling required and finally there's a lot more code that works with the expected presence of a div with id gs_content, so main.xsl appears to for now be required to use id=gs_content on the div containing the actual page content.

1 modified


  • main/trunk/model-interfaces-dev/opotiki/transform/layouts/main.xsl

    r34145 r34148  
    7272        </div> 
    7373        <div class="wrapper"> 
    74             <div class="container"> 
    75                 <xsl:apply-templates select="/page"/> 
    76                 <br class="clear" /> 
     74            <div class="container" id="gs_content"> 
     75                <xsl:apply-templates select="/page"/>                
    7776            </div> 
     77            <br class="clear" /> 
    7878        </div> 
    7979        <xsl:call-template name="gs_footer"/>