I’m creating Content Container Templates (CCT) and nesting Asset Listings within a Content Container. The aim is to use conditional statements to customise the rendering of the Asset Listing (eg its Page Contents) and its results (eg Type Formats) based upon the metadata configuration of the Content Container and the Content Container's other attributes.
However, I’m finding an issue with inconsistencies in the use of %globals_asset*% keywords – the asset which to which it refers depends on where you reference it. Within the CCT’s Paint Layout (eg the Paint Layout Bodycopy), the %globals_asset_*% refers the Content Container. Likewise, in the configuration of the Asset Listing (like what’s shown in the template example documentation]), referring to %globals_asset_metadata_source% in the dynamic root setting gets the Content Container's metadata.
However, within any part of the Asset Listing itself (eg its Bodycopy areas - either Page Contents or results Type Formats), the %globals_asset_*% now refer to the asset which Content Container is within; in my case, that’s the Standard Page asset the user is viewing on the frontend. Likewise, the %asset_*% keywords refer to the Asset Listing's components. So it doesn’t appear as if there’s a way of directly accessing the Content Container in these areas – without a workaround.
I did find that you could work around this problem by passing a GET parameter from the Paint Layout Bodycopy when nesting the Asset Listing – eg a variable content_container with a value of %globals_asset_assetid%, which evaluates correctly in that context. This allows the use of %nested_get_content_container% anywhere in the Asset Listing. The same approach as using ^with_get: could be used for passing the Content Container's asset ID around to other asset types/content container types.
So, it’s possible to workaround this issue, but ideally, with CCT, having a reliable, clean way of accessing the Content Container would make most sense.
In addition, I’d like to know if the %globals_asset*% behaviour can be made consistent, or, if that’s not possible, documented so you know what its value will be and when (eg in which context) without having to resort to trial-and-error. I’d logged https://squizmap.squiz.net/matrix/9726 as being the inconsistent use of “globals” between different areas of Matrix and whilst the introduction of the %frontend_asset% keyword goes always to being a solution for the original bug, it doesn’t help this issue with use of CCT.
Matrix Version: 5.3.3.0, potentially similar to this post
PS For anyone perusing this later, if you want the Content Container from within the Simple Edit Layout use %asset_assetid%; using %globals_asset_assetid% will give you the Edit+ JavaScript API (or possibly something else if you’re using Simple Edit).
Likewise, if you try and use the suggested %edit_asset_assetid% to access the “current asset being edit” you’ll end up getting the frontend asset (eg parent Page of the CC) even if you’re directly editing just that specific Content Container in the admin interface. That feels like either a bug or documentation in need of correction. Thankfully, %asset_*% keywords work fine in a Simple Edit Layout so use those instead for now.
