Marketo module scope (mktomodulescope) affecting editability

[Anonymous]

I've just noticed that setting Marketo module scope (mktomodulescope) to "true" adversely affects the ability to edit string variables in my template. Here's what I'm seeing:

• Setting the mktomodulescope to "true" renders the variable fields in the email editor blank and ignores any changes to those fields.Oddly enough, the default values are retained in the email preview regardless of what I do in the editor.
• I can edit the variable values if I add a new version of the module to the draft (not ideal).
• Once I remove the mktomodulescope declaration from the variable's meta tag, the editor respects changes (but obviously I lose the benefit of confining variables to a single module).

Is this just me? The template syntax checks out, otherwise. I've seen a few discussions about the mktomodulescope declaration over the past week or so.

[Grégoire_Miche2]

Hi Joe,

If you are changing the setting on existing templates, reapprove them and edit the related email, yes this is expected, AFAIK.

There is an answer from Justin Cooperman​, and I am writing under his control, in a recent thread (I could not retrieve it), explaining that, if you change the module behaviour one way or another, it locks the content, because it cannot take the risk to temper with is a loose it.

-Greg

[Justin_Cooperm2]

Hi Joe,

Can you please provide more detailed steps for how you are seeing this? I also can't reproduce this using String variables that are set to mktoModuleScope="true".

Are you adding this within an individual email through the code editor (not the template itself)? Or did you create a new template that has this and a new email is behaving erratically? More detail will really help us investigate this.

[Anonymous]

Thank you, both – based on your feedback, I went back and removed every mktoModule scope declaration from my email template, then manually added them back in. So far, so good. I'm guessing there was something malformed in there that passed validation but failed in production.

To answer your questions – in case it's helpful to anyone reading this in the future – I am dealing with a brand new template and was creating new emails at each iteration of the template (avoiding the 'existing email' situation). And all code-level changes were made to the template, though Justin Cooperman​ you make a good point: I hadn't thought of checking the code of the emails themselves... I guess I'll have to get used to that as a possibility when troubleshooting.

Regardless, removing the declarations and adding them back in seems to have done the trick.

[Justin_Cooperm2]

Ok, we figured it out and it is indeed a bug with large email templates. We will issue a patch to increase the max size. Essentially, it's a matter of how many "local" variables you've defined. We serialize it and write it all out to JSON and the DB column doesn't have enough room to store large numbers of variable definitions.

[Dave_Roberts]

I've been developing in the 2.0 environment and run into a similar issue. Im sure it's based on the the number of variables I've got encoded into each module, but from my experience, the magic number of modules is 8 added to my canvas and then my variable values are all erased (though the content still renders "as-was") and locked from making changes. I've tested every combination of 8 modules that I created and (8x module one, 8x module two ...) to be sure that it wasn't the coding for a particular module and experienced a similar result no matter which modules I added and in which order.

Thanks for addressing this issue, looking forward to the patch - is there any scope on a timeline for that yet, it'll make a big difference in what we're able to offer up for the email template contest.

[Anonymous]

Oh, wow -- I'm not nuts!  Echoing Dave Roberts​ thanks for addressing the issue.

Any idea if it's a matter of a net number of local variables, or is it the size of those variables on disk? Meaning: is it always X variables that triggers the problem, or does the size of the variable names, IDs, and values come into play? The answer could help us determine whether or not to split a template into versions to cut down on the number of local variables, or just try to semantically revise the way vars are named and declared.

[Dave_Roberts]

Hey Joe-

After reading thru this last night, I cloned my template and created a "Kool-Aid" (watered-down) version where I removed most of the variables from my modules (downsizing from 12 controls to 4 each) and was able to add more modules to the canvas.

In line w/ what Justin offered (the JSON readout to the DB) it sounds like it's more an issue of # of variables rather than disk size - likely it's a matter of the number of "lines" that await variables in the DB that's the limiting issue here. You could try to downsize some of your module variables and see if that helps?

[Justin_Cooperm2 · Accepted solution]

It will be fixed in <1 week. Don't let this affect what you write for the template contest!

The issue was disk size of the JSON object we save out to DB. Limit was previously 64KB. We are upping it so there will be plenty of storage.

Justin

[Morag_Keirns]

Thanks for posting this we have had exactly the same issue and have had a support ticket open for this for over a week. Would you mind posting back to here when you have this resolved so that we can review our instance and see if it resolves our issue as well.