SSJS with use of %globals_asset_contents% is executing in different scope

[davidjb]

With the use of including one page's contents within another with a global keyword (eg %globals_asset_contents:1234%), the SSJS scope isn't the same.

First page:

<script runat="server">
    var counter = 1
    print("<h1>Running in parent asset</h1>")
    print("counter object is this: <code>" + typeof counter + "</code>")
</script>

%globals_asset_contents:12345%

<script runat="server">
 print("<h1>This does print.</h1>")
</script>

Second page (asset 12345):

<script runat="server">
    print("<h1>Running in nested asset</h1>")
    print("counter object is this: <code>" + typeof counter + "</code>")
    counter++
    print("<h1>This doesn't print because the line above errored</h1>")
</script>

The result of loading the first page is the following output:

Running in parent asset
counter object is this: number

Running in nested asset
counter object is this: undefined

This does print.

This is a simplified example, but anything defined (variables/objects/functions) in SSJS in the Design/Paint Layout/Page is available within the Page contents but isn't available in the asset included via the globals keyword. This has the effect of, as the final line of the Second Page asset suggests, breaking any further usage of SSJS in that included asset.

This issue could be the same as https://squizmap.squiz.net/matrix/10699 because the line with This does print, does print, indicating the SSJS execution is continuing and is separate as the included keyword asset. The key difference is that issue is Nested Design Areas and this is page contents keywords.

Tested on Matrix 5.4.0.3.

[davidjb]

Reported at https://squizmap.squiz.net/matrix/10733

[davidjb]

Wow, we have a workaround for this now. Essentially, we use an Asset Listing via %globals_asset_contents:12345^with_get...% to pass along our list of assets to be displayed. This has the affect of running SSJS in the separate process (thus triggering this bug). However, we re-include any SSJS that would have been run up to this point inside the Asset Listing's Page Contents, allowing SSJS to run correctly inside that rendering.

Now, the second problem is that we can't have the internals of that rendering modify our "outer" global state. However, to solve this problem, it turns out that requesting the same keyword %globals_asset_contents:12345^with_get...% in SSJS (in a Paint Layout) has the affect of causing any SSJS inside the asset contents to be ignored -- and just returned verbatim. Good for us, because that means we can just parse for it, and eval that stuff. Completely about face? Totally. Safe?..hmm..maybe. Crazy? Just a little bit.

[davidjb]

Apparently fixed in 5.4.2.0 and 5.5.0.0. Awaiting install in that case.