Re: Javascript - Using Custom Namespace in Landing Page Editor

Thorsten · ‎02-16-2023

Hi everyone,

I am using a custom namespace in my (guided) landing page template. Is it somehow possible to leverage some of it in the landing page editor as well?

It seems like it's not even possible to do a

var td = {};

Is the editor filtering this out?

My goal would be to auto-fill a string template variable with the landing page URL and adding some UTM tags, which will then be used as the OG URL when sharing the page, so it's rendered with the page already.

Kind regards,

Thorsten

SanfordWhiteman · ‎02-17-2023

Oh wait, you mean setting the value of an input in the parent window (the LP Editor) using JS on the page itself. Certainly possible — or used to be when I wrote something similar to hook up a color picker in the editor.

View solution in original post

SanfordWhiteman · ‎02-16-2023

Are you asking if you can include a local <script> element in an editable content area using the HTML source editor? Not sure what this has to do with namespaces — do you mean namespaced HTML elements? Please provide more info here.

Thorsten · ‎02-17-2023

Ok, maybe I shouldn't have gotten hung up on the word "namespace".

To clarify what I am trying to do:

I have a guided template, with a string-type variable (like that)
I have some JS code that will be part of the template that aims to set the value of this string variable when the user is in the landing page editor
I fail to even create a variable on the window object, like in my example above - as my intention was to put my function into that object, so just to have my custom code neat and tidy under window.td.fillThatVariable()
It looks like it doesn't let me create the JS variable at window.td and initialise with an empty object to start with
I currently try to set this variable within a <script> block in the <HEAD>, but some other test variable in <BODY> didn't work either for that matter, they just don't exist when I create a new LP in the editor and go to the browser console

SanfordWhiteman · ‎02-17-2023

Oh wait, you mean setting the value of an input in the parent window (the LP Editor) using JS on the page itself. Certainly possible — or used to be when I wrote something similar to hook up a color picker in the editor.

Thorsten · ‎02-20-2023

Exactly! Thanks for wording it properly, Sanford 😀

Well, I got as far as solving my initial problem with a simple

if (/.marketodesigner.com$/.test(document.location.hostname)) {
parent.td = td;
}

only to then get into a CORS issue... I'll drop the plan here, it's becoming way to much effort for a little nifty nice-to-have convenience.

@SanfordWhiteman & all, if anyone of you like a challenge - give it a try! 😁 The goal would be the set the template variable ("the value of an input in the parent window") with the URL of the landing page and populate the OG meta tag for the URL like:

<!-- MARKETO VARIABLES -->
...
<meta class="mktoString" mktoName="[OG] Url" id="og_url" default="https://example.com/" />
...
<!-- OG Meta Tags -->
...
<meta property="og:url" content="${og_url}" />
...

So one could also set some default UTMs on that OG URL like

?utm_source=marketo&utm_medium=pageshare&utm_id=the+program+name

in one go and save some manual work for the marketing staff.

As always, thanks for your help - even if this goes nowhere, I have learned a lot trying 😂

SanfordWhiteman · ‎02-20-2023

Isn’t there a more immediate problem that the URL of the approved LP isn’t readable from the child IFRAME nor from the parent? Have you found that value?

Thorsten · ‎02-20-2023

Well, this code on StackOverflow I used to search the Window object says it is somewhere deep deep down in

Ext4.ClassManager.classes["Ext.ComponentMgr"].all.map["tbtext-1030"].ownerCt.ownerCt.items.map["lpEditor-1034"].items.map["lpEditorPredefinedLayout-1035"].items.map["lpPredefinedLayoutCanvas"].landingPage.raw.properties.destinationUrl

But i don't know how reliable or solid that is. So far, on different templates I tested in different instances (sandbox/production), it seems rock solid.

Before that I used the input with name=lpurl, which only exists when a form is present. But I was going to address that issue later...

Dave_Roberts · ‎02-21-2023

Years ago I saw something like this put into a client instance and it was a real headache to work with the page in the editor. It did something a little differently and re-arranged the order of the Variables panel but used a similar approach. I hated working with the pages that were setup this way and we ended up remaking a new template that didn't have all the "jazz" in there. All-in-all it made for a bit of an improvement to the User Experience but it came at a significant tradeoff with intermittent load lag and weird "in-between" states that really made the UX worse than unorganized (and stable) fields in the Variables panel.

I'd say something like this is pretty cool, and maybe a fun rabbit hole to run along but probably not worth it in the long run (yet). I think it'd be inviting stability issues until Marketo opens something like that up natively and might end up being more maintenance than you bargained for compared to just manually setting a color or URL variable value. If you're looking for job security tho, it might be a good way to ensure that you're busy in the future 😉

Dave_Roberts · ‎02-21-2023

Another approach that maybe more stable might be to provide the user with a dialog box to copy/paste the value into the variable rather than trying to set it automatically.

You could add a script to the template that only fired in the Editor Experience and surfaced the values you're looking for a user to add into the variable.

It might go something like:
// IF: this page is NOT inside the Marketo Editor experience (check the path for some part of the URL that doesn't exist in the approved LP) == do nothing

// ELSE: surface the values you're looking for inside of one iFrame and pass them to a dialog box that pops up to the end user for a copy/paste into the Variable panel. Maybe include some instructions in the dialog to make it easy-bake.

You might also include this as a button to optimize the UI a bit. The button might trigger a modal in the Editor iFrame (left side of the editor experience) so that a user could click the button to trigger the pop up when/if they need that info.

Thorsten · ‎02-22-2023

Thanks Dave for sharing your experiences and providing so much food for thought! Much appreciated.

I need to breed over this for a while. At the moment I am hesitant to make any change in either direction, thinking that the user experience with a modal or stability issues down the road will be severely impacted. I'm leaning towards leaving it with a more fancy default value for now and otherwise waiting to see if more users flag this as an inconvenience worth fixing.

Anyway - thank you all again for the inputs!

SanfordWhiteman · ‎02-23-2023

DM’d you the code in any case (not suitable for general use!).

Thorsten · ‎02-17-2023

It's starting to dawn on me that I need to dig a level deeper into the window of the iFrame.

SanfordWhiteman · ‎02-17-2023

What IFRAME? It sounds like there’s a lot you’re not mentioning here!