I'm 👎 on storing escaped data in attributes. It seems like a technical hack around conceptual contradiction — shortcodes are macros to produce HTML markup.

I think escaping the data in some way is unavoidable. Its a common use case for shortcode attributes to hold names, strings for display, or other data which can't reasonably be expected to be free of all special characters. There's no other way, short of a core change, to get shortcode_parse_atts to handle quotes or some other special characters in attribute text.

The idea of the filter on "shortcode_atts_{$shortcode}" seems like a good way to handle this transparently for those attributes that desire it, while still preserving existing default behavior. Yes, this isn't what urlencoding is really for, but it works, and has the advantage of being available in a similar form in PHP and javascript.

But, if we're looking for alternative approaches, replacing the attribute parser regex in core with something like an XML attribute reader would be a good start. My initial confusion at this issue came because intuitively I expected shortcode attributes to behave like HTML attributes and was surprised that attr="value with \"quotes\"" didn't work. We already have tools to deal with escaping attribute values; if shortcode attributes worked like XML/HTML attributes, then the problem here would be simpler and we could use a more appropriate escaping method.

I think the main problem I was getting around was that it breaks the view if an attribute has html in, when you have a textarea field that gets stored in an attribute this can happen with no clear way to recover easily.

URL escaping was the only common way to handle this between JS and PHP besides atob() / btoa() which aren't supported before IE10, guess that depends on the browser support offered by wp admin which afaik is still IE8.

I agree it's totally hacky but can't see how else would #236 be feasible?

A slightly less hacky approach may be to embed the data inside inner_content somehow. Eg. <div style="display:none" data-shortcode-attr="attribute-name">some <strong>HTML</strong> content</div> then read the values out from there

@mattheu any thoughts on this?

It would be nice to have an official core opinion on this.

We chatted about this some today. It seems like encoding behind the scenes is the only way we can go for now.

Could we make registration happen on the field-level, and automatically unencode so no modification to an existing shortcode is necessary?

@sanchothefat One nit before this lands — could we call the argument encode instead of escape? Technically we're doing the former.

Actually, now that #179 has landed, let's bump this out of v0.4.0 and come back to it if we need.

Closing in favor of #496