• State Suggested Answer
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 18 subscribers
  • Views 1084 views
  • Users 0 members are here
Options
Related

Header widgets in Template changing order

Chris Rymer

We are working in widget studio to build data objects, which are to be consumed by anlaytics and various other components. It comprises of two widgets which need to go in to the header for now (eventualy the head of the template).

  1. Cachable page information (Page type, doc id etc)
  2. Non cachable user session information (Location, username, web id etc)

These widgets are placed in the template in a specific order, the cacheable item goes first and sets up the object for which the second will assign it's data. The widgets are added to the header and the padlock is checked to ensure it applies to all pages.

What seems to be happening in my local is that the object which should exist first is being inserted into the HTML after the second item, this causes big problems in the front end. It never seems to happen on the homepage and currently I have only experienced in in the discussions and it's sub pages but I do not find any Exceptions because both pieces of velocity are being rendered perfectly, they are just out of sequence.

To fix this I generally have to navigate away from the probem page (to the homepage) and then come back, this seems to clear the issue. No one else on the team is noticing this but we want to ensure we are not tripping over a known bug.


Viewing the source, this item should be first

Followed by this item

As you can see from the images the line numbers indicated the order is incorrect.

I am hoping somebody knows how it is possible for two velocity scripted widgets to ignore the order they are set with in the theme manager.

Parents
  • Former Member
    0 Former Member

    Locked widgets are only ensured to exist on inherited pages, but not necessarily in a guaranteed order.

    It would be preferable to not rely on widget rendering order at all but instead provide more explicit ordering control. A few recommendations:

    1. Combine the two widgets functionalities into one
    2. Have both widgets wait for page load via jQuery(function() { ... }) to perform their operations
    3. Utilize built-in messaging API for subscription and publication of messages to have the second widget wait for a signal from the first.
  • 0 in reply to Former Member

    Thanks for the response.

    What we are doing in the case is generating a JSON stub which will be used to send page data to a tag manager where the analytics team can hook up the tracking data etc.
    The tag manager will load various other services etc. and needs to be high up in the <head> which should probably be done in the template.

    Having these things currently in the template header is a stop gap, they must be rendered server side to have the data ready before a specific script inclusion. Roughly sepaking this is what we do.

    `--- widget (a) - cached
    var obj = {}
    obj.internal.methods = { ... add various FE methods }
    obj.property1 = {}
    obj.property2 = {}


    --- widget (b) - non cached
    obj.property1.foo = 'a value'
    obj.property2.bar = 'a value'

    // special variable name for data accessible by tag manager
    var tagData = { obj.property1, obj.property2 };

    // Insert script tag
    <script href="tagmanager.com/account"></script>`


    I am not sure pub/sub will fit our requirements as this will delay the initialisation of the tag manager which would be sub-optimal for some of the 3rd party code which needs to be run.

    Is it considred a bug that these widgets do not appear in order that is set in the template?

    Thanks

  • Former Member
    0 Former Member in reply to Chris Rymer

    Rather than creating the stub in a widget, I'm wondering if adding to Raw Header would be a better fit? (in Administration > Site > Syndication and SEO Options) This is typically the location to place tracking scripts like Google Analytics.

    There's no ordering expectation for inherited widgets, just the guarantee that the widget will be included. The ordering can be affected and adjusted in inheriting contexts.

  • 0 in reply to Former Member

    I think because we need to build the object up from various datapoints and that is done via velocity currently we would not be able to use the SEO options. I am intrugued as to the ordering not being rigid, does that mean that if we had specific content widgets padlocked, we wouldn't be able to gurantee their position?

  • Former Member
    0 Former Member in reply to Chris Rymer

    Widgets are rendered in order, however, locked widgets are only ensured to exist on inherited pages, their order on those pages is not guaranteed and can be adjusted in inheriting contexts.

    Widgets should be treated as encapsulated and order agnostic. Any strong interdependence on widget load timing should be reconsidered. If the functionality is very interdependent, consider combining the widgets into one and delaying their operations in a jQuery(function() { ... }) block so that the rest of the page can be ensured to be loaded. Another alternative would be a common javascript library that could be loaded as a raw header or platform header, with an "esure exists"-type initialization method that can be called just-in-time when needed by your other tag code.

Reply
  • Former Member
    0 Former Member in reply to Chris Rymer

    Widgets are rendered in order, however, locked widgets are only ensured to exist on inherited pages, their order on those pages is not guaranteed and can be adjusted in inheriting contexts.

    Widgets should be treated as encapsulated and order agnostic. Any strong interdependence on widget load timing should be reconsidered. If the functionality is very interdependent, consider combining the widgets into one and delaying their operations in a jQuery(function() { ... }) block so that the rest of the page can be ensured to be loaded. Another alternative would be a common javascript library that could be loaded as a raw header or platform header, with an "esure exists"-type initialization method that can be called just-in-time when needed by your other tag code.

Children
No Data

About
Privacy Policy
Terms of use
Copyright 2024 Verint, Inc.
Powered by Verint Community