Ssjs and asset_data keyword - linebreaks


(Gavin Boyd) #1

Using this keyword within ssjs:

const data = %frontend_asset_data_metadata^empty:{}%

The JSON that is returned contains line breaks which are breaking the SSJS.

What is the best way to escape this? Have tried these with no luck:

%frontend_asset_data_metadata^nl2br^empty:{}%


#2

Hi,
I had similar issues, and used REGEX to resolve.

Create a REGEX asset to resolve the line breaks, then update your var include the following:

^preg_replace:123456

Where 123456 is your REGEX asset.

Your regex asset should look something like this: (\r\n|\n|\r)

Hope this helps


(John gill) #3

My understanding is that %frontend_asset_data_metadata^empty:{}% should not contain newlines even if the asset has metadata fields which contain newlines.

From an example I just did:

%frontend_asset_data_metadata^empty:{}%
{"description":{"value":"This\r\nis\r\na\r\ndescription","fieldid":"161","type":"metadata_field_text","is_contextable":true,"default_value":false,"use_default":true}}

I can’t think off the top of my head how a newline would be coming from that keyword. Are you able to share more detail?


(Martin McErlain) #4

Have you tried ^json_encode


(John gill) #5

I think there’s a false premise or missing info here somewhere. Tests on 5.5.6 and 6.18 indicate that asset_data_metadata is safe to use directly in SSJS[1] even if it contains metadata fields that contain new lines. This fits with the documentation of the keyword which says it returns “A JSON object of the asset’s metadata fields and values.”

In the absence of enough detail to replicate the issue, any speculation on resolutions risks becoming misinformation for people searching the forum in the future.

@gboyd are you able to share more detail on exactly what you’re seeing from that keyword, and where the spaces are coming from?

1: (you don’t even need ^empty:{}, because a page with no MD fields will return an empty array that will then be turned into [] by the implicit as_json)


(Bart Banda) #6

%asset_metadata_x% keywords always return a string, never an object by default, so I’d expect using ^json_encode will make it work. Because at the end of the day, metadata values are just stored as text strings in the DB, and that’s what gets loaded by default.