We just migrated from Eloqua to Marketo and are having issues validating a few templates. Why would we get the error message "A mkto element is nested inside another"?
Solved! Go to Solution.
You’re certainly not making it easier by removing your HTML! The problem is exactly what the error says:
In this example, I'd recommend getting rid of the "mktoText" class on the id="FullfContent" parent container as the most straight-forward solution. This will allow the editable areas inside that container to validate.
As the warning mentions, you can't nest editable areas inside of editable areas using the Marketo syntax (email nor landing pages).
All-in-all, there's two ways to think about this situation:
1) Make the parent editable (#FullfContent) and remove the nested editable containers.
Considerations: This exposes ALL the HTML inside the parent container and makes it act a bit more like you might expect in Eloqua where you can edit everything at the code level, but only within the editable area. You might want to do this if you'd want to add or remove elements from inside the parent container. The downside is that you expose the code and things could easily get messed up in the editing process if the editor doesn't have a grasp on HTML -- but coming from Eloqua I'd imagine you're already used to this so this might be the best route forward for you.
2) Make the child elements inside the parent container (#FullfContent) editable individually.
Considerations: This makes it easier to edit just the individual pieces one at a time and does not expose the HTML for that element. The tradeoff here is that the element (button, headline, etc) will not be able to be removed, you'll just be able to remove the content of that element. This approach works best for a very standardized template where there are always certain elements included in a layout and makes it easier on folks to just add words and links inside the editable elements without the risk of messing up the HTML shell. This approach is less flexible but more safe. Most time when this method is used, it's used in combination with Boolean Variables to show/hide (display: none/block) the individual piece in the event that you wanted to exclude a headline or button or something like that.
The "right" answer for how you set this up has more to do with the end-user (HTML-less vs HTML-able) in my experience in combination with the expected utility of the template. If you're in a spot where you want to change the layout (add elements, remove elements, create/remove columns) it's best to do #1, if you're in a spot where you don't want the end user to be able to make adjustments to the layout and instead just enter text then #2 might be a better choice. I personally prefer to create larger "sectional" editable areas using the "mktoText" class for everything and that way you can put whatever you want inside of them and move content around the page from one "section" to another rather than being stuck inside a rigid framework, but again, it all depends on the business use-case to decide what's best in any given situation.
In this example, I'd recommend getting rid of the "mktoText" class on the id="FullfContent" parent container as the most straight-forward solution. This will allow the editable areas inside that container to validate.
As the warning mentions, you can't nest editable areas inside of editable areas using the Marketo syntax (email nor landing pages).
All-in-all, there's two ways to think about this situation:
1) Make the parent editable (#FullfContent) and remove the nested editable containers.
Considerations: This exposes ALL the HTML inside the parent container and makes it act a bit more like you might expect in Eloqua where you can edit everything at the code level, but only within the editable area. You might want to do this if you'd want to add or remove elements from inside the parent container. The downside is that you expose the code and things could easily get messed up in the editing process if the editor doesn't have a grasp on HTML -- but coming from Eloqua I'd imagine you're already used to this so this might be the best route forward for you.
2) Make the child elements inside the parent container (#FullfContent) editable individually.
Considerations: This makes it easier to edit just the individual pieces one at a time and does not expose the HTML for that element. The tradeoff here is that the element (button, headline, etc) will not be able to be removed, you'll just be able to remove the content of that element. This approach works best for a very standardized template where there are always certain elements included in a layout and makes it easier on folks to just add words and links inside the editable elements without the risk of messing up the HTML shell. This approach is less flexible but more safe. Most time when this method is used, it's used in combination with Boolean Variables to show/hide (display: none/block) the individual piece in the event that you wanted to exclude a headline or button or something like that.
The "right" answer for how you set this up has more to do with the end-user (HTML-less vs HTML-able) in my experience in combination with the expected utility of the template. If you're in a spot where you want to change the layout (add elements, remove elements, create/remove columns) it's best to do #1, if you're in a spot where you don't want the end user to be able to make adjustments to the layout and instead just enter text then #2 might be a better choice. I personally prefer to create larger "sectional" editable areas using the "mktoText" class for everything and that way you can put whatever you want inside of them and move content around the page from one "section" to another rather than being stuck inside a rigid framework, but again, it all depends on the business use-case to decide what's best in any given situation.
Thank you, that worked!