I have found a post concerning this, but the last time it was touched was in june 2010.  It also has no real solution.

given this :

{embed=“part/subpage_layout_full”
    subhead=”{sp_bot_c1_subhead}” summary=”{sp_bot_c1_summary}” additional=”{sp_bot_c1_additional}”}

If any of the three embeded fields contain a double quote (”) the rendering will break.  I assume this is because the tags are being expanded and then the embed is being processed.

This is unacceptable.

There are a few fixes I’ve considered. I could use single quotes instead of double quotes in the tag.  Of course this means that everything will then break if I use single quotes in any of the fields.  Since this site is being shipped to a client it’s also unacceptable, and also simply not a fix.

The only other thing I could conceivably do is to preprocess all the variables in php first then pass them through the template and then potentially process them in the embedded template as well.  This seems like a giant hack. 

Is there some reason why EL doesn’t solve for this already? It makes embeds with user generated variables non-bulletproof in a way that makes me want to discontinue using embeds.  While not DRY it’s the only way I can be sure that my client doesn’t break their own site by doing something simple like putting a quote in a custom field!

Hi Brett,

In general, embed parameters are meant to contain opaque IDs that point to content, rather than actually containing the content itself. The complexity that would be added by allowing arbitrary values to be sent through an embed’s parameters would require a fundamental rewrite of the template parser class, which would then require a rewrite of all of the hundreds of third party modules and plugins. So I would not hold my breath for that to happen as there is very little return for a large undertaking.

However, all is not lost. This is very easy to fix using the free Stash plugin to save the values before doing your embed.

Then in the part/subpage_layout_full template, you would get the values using:

Alternatively, you could send the entry ID to the layout embed and have it run it’s own {exp:channel:entries} loop to get the individual piece of content - however this could be a serious performance penalty if this embed is used in a loop, in which cause I do not recommend it.

Thanks! This solved my problem. 

However can we add this to the feature list and fix the issue in the core without resorting to add-ons to patch what is clearly broken.

Your secondary solution of passing an ID and then running another query is certainly something I considered but decided against simply on the grounds of performance.

Hi BrettWagner,

As airways mentions above this is the way that the embed tag works at the moment and to change it to allow for what you need would indeed be a large undertaking for something which is possible to do in other ways. One very good one which was shown above.

We don’t consider this functionality to be broken but if you would like to make a Feature Request asking for this to be changed then you are quite welcome to do so.

Does that help at all?

Thanks,

Mark

Mark, with all due respect, I’m not sure how you can’t consider this at least a bug.  You simply aren’t cleansing your inputs and leaving your system open to breakage with very simple user error.

The fact that the documentation on embedding doesn’t even mention this possible problem is just a final kick to the groin.  I spent a good 30 minutes in denial on this because I figured there was no way that a CMS system would fail in such a simple way.

Hi, Brett.

I mentioned this thread to Robin, and she mentioned this should be added as a bug. Since you have a real life example to use, do you mind posting the bug report?

Filed: https://support.ellislab.com/bugs/detail/16856

Hi BrettWagner,

Thanks for taking the time to file the bug, your input is valuable and can only serve to make ExpressionEngine better! With the confirmation of this bug, is there anything else we can assist you with?

Thanks!