Clarity

 View Only
  • 1.  Yammer feed in HTML portlet, does not load right away

    Posted Feb 14, 2017 07:47 AM

    This was already asked here: Yammer Feed in HTML Portlet, but as that question was marked as 'Assumed answered' and does not completely answer my question, I'm raising this separately:

     

    We are able to get the Yammer feed visible in a HTML portlet, but users will see it first after clicking on the CA PPM Refresh icon or when navigating to the page.
    The HTML-portlet is in the landing page and our intention was that users would see PPM-related communication directly they log in.
    Have tried with IE11, Edge, Chrome and PPM 13.3 and 15.1. Same issue in all of them.

     

    Thus, how to get the Yammer feed to load without users needing to reload the page?

    This is the code we are trying:

    <div id="embedded-feed" style="height:600px;width:800px;"></div>
    <script type="text/javascript" src="https://s0.assets-yammer.com/assets/platform_embed.js"></script>
    <script type="text/javascript">
    yam.connect.embedFeed({
    "network": "wartsila.com",
    "feedType": "group",
    "feedId": 7262563,
    "config": {
    "use_sso": true,
    "header": false,
    "footer": false,
    "showOpenGraphPreview": false,
    "defaultToCanonical": false,
    "hideNetworkName": false,
    "promptText": "What do you want to share related to CA PPM?"
    },
    "container": "#embedded-feed"
    });
    </script>



  • 2.  Re: Yammer feed in HTML portlet, does not load right away
    Best Answer

    Posted Feb 18, 2017 09:32 PM

    Did you try the method of seeing the iframe that gets created, and then replacing the contents of your html portlet with the iframe instead?

     

    A problem you are running into is one of dependencies and execution order.  PPM is snatching and executing any script tags in the document when it loads up, and if their eval() result doesn't turn into something that PPM can put back into a <div> in place of your <script>, then it doesn't get displayed.

     

    At the time your script that references the yam/yammer api is eval'd(), the javascript file from the previous element isn't available.  That then results in the javascript eval failing that yam == undefined.

     

    When you refresh the inner contents of the page once the outer page has already been loaded, then the contents of api/sdk script are available and it loads.

     

    So by cutting that out and just including the iframe directly could save you from all of that.



  • 3.  Re: Yammer feed in HTML portlet, does not load right away

    Posted Feb 19, 2017 05:01 AM

    Nick, thanks a lot, this indeed solved the issue!



  • 4.  RE: Re: Yammer feed in HTML portlet, does not load right away

    Posted Jul 15, 2019 01:18 PM
    Hi Nick,  I'm working on implementing the Yammer feed into our Clarity home page.  I am about 98% complete​, but I am also facing the issue of having to refresh the page.  Your post seems to work, but I'm confused on the first paragraph: 

    "Did you try the method of seeing the iframe that gets created, and then replacing the contents of your html portlet with the iframe instead?"

    How are you seeing the iframe that is created?   I'm looking at the source and don't see any iframe tags.   Our portlet is on the OOTB Overview page under the General tab as a  portlet.  

    I'm so very close, just needing that last piece of information.

    Thanks,
    Terry


  • 5.  RE: Re: Yammer feed in HTML portlet, does not load right away

    Posted Jul 16, 2019 01:16 AM
    It's possible yammer's apis have changed, but that paragraph was in reference to the thread linked in Thomas' initial post, based on a suggestion in there by Haseeb that Gene then went and demonstrated.

    I believe they tried to load the example yammer api in a separate non-Clarity web page or site to see how it appears there.  Then they were able to 'view source' and see the generated iframe contents when that api wasn't being suppressed from doing so.

    Then the html portlet was constructed using just that output instead to avoid the issue.

    I'm sorry to say that I didn't personally put any of that into practice myself though - I just put the information together from my reading of those threads plus knowing how Clarity would be suppressing running it the traditional / proposed way.