[wp-trac] [WordPress Trac] #25820: [embed] shortcode can't be escaped like others
WordPress Trac
noreply at wordpress.org
Sat Nov 8 04:12:16 UTC 2014
#25820: [embed] shortcode can't be escaped like others
-----------------------------------+-----------------------------
Reporter: MadtownLems | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Future Release
Component: Shortcodes | Version:
Severity: minor | Resolution:
Keywords: has-patch 2nd-opinion | Focuses:
-----------------------------------+-----------------------------
Changes (by aaroncampbell):
* keywords: needs-patch => has-patch 2nd-opinion
Comment:
The problem is that the embed shortcode needs to run earlier than the
other shortcodes, so it does something hacky. It hooks into the_content at
priority 8 (before `wpautop()` runs), removes all shortcodes, adds the
embed shortcode, runs it, then puts all the other shortcodes back,
registering `__return_false()` as the handler for the embed shortcode.
So here's what's actually happening:
1) `do_shortcode()` is running on the_content, unescaping
`[[embed]someurl[/embed]]` to `[embed]someurl[/embed]`
2) Shortcodes are processed and the embed shortcode has been unescaped so
it's now a valid shortcode. However, the handler for it is
`__return_false()` so it's simply removed.
You can see this pretty clearly by using three square brackets instead of
two to escape the embed shortcode (`[[[embed]someurl[/embed]]]`). One set
is removed during step one above and then step two processes it as an
escaped shortcode, removing another one.
I looked at several potential solutions. Several of them had me making
tweaks to the regex or `do_shortcode()` that were ridiculous. Taking a
look at it again, I'm thinking it might be easier to just add another
simple hack to work around our existing hack (I know, I know, stick with
me for a minute). If we add a filter in `do_shortcode_tag()` that filters
the returned text of an escaped tag, we could hook into that filter before
we process the embed shortcode early, have it add the removed brackets
back, then remove the hook after we're done.
That's what I did in [attachment:25820.diff]. It's definitely a bit of a
hack, but it's simple, straightforward, and it seems to give the expected
behavior. If anyone has a better idea, let me know!
--
Ticket URL: <https://core.trac.wordpress.org/ticket/25820#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list