[wp-trac] [WordPress Trac] #10457: Parse shortcodes in text widgets by default

[WordPress Trac]

#10457: Parse shortcodes in text widgets by default
--------------------------------+-----------------------
 Reporter:  ionfish             |       Owner:  westi
     Type:  enhancement         |      Status:  reopened
 Priority:  normal              |   Milestone:  3.3
Component:  Widgets             |     Version:  2.8
 Severity:  normal              |  Resolution:
 Keywords:  westi-likes revert  |
--------------------------------+-----------------------
Changes (by nacin):

 * keywords:  has-patch tested westi-likes commit => westi-likes revert
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Unfortunately there are too many holes that can be poked in this. For
 background, read #19411 and
 [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-
 dev&day=2011-12-02&sort=asc#m341059 this IRC conversation].

 Summarizing the problems as follows:

 One, do_shortcode() would be running before our conditional wpautop() in
 the text widget. Shortcodes are used to running both after wpautop() and
 shortcode_unautop(). There are some ways around it, but it is going to be
 very hacky, and each hack sacrifices something else.

 For example, currently anything running on the widget_text filter is
 always operating before wpautop(), so adding wpautop() to priority 10 will
 break some things, especially since plugins also on priority 10 would run
 after.

 As a second example, I think do_shortcode() can only be run once against a
 block of text, otherwise it risks executing escaped shortcodes (not tested
 whether that is the case). So if a plugin is already adding do_shortcode()
 to widget_text, we could assume priority 10 and either only add with
 priority 10 (as trunk is now), or we'll need a delayed has_filter() check.
 This is why I left do_shortcode() on priority 10 and shoehorned wpautop()
 before it (for patches on #19411).

 That's just the first problem. The second problem is what is resulting in
 a revert here. Core only has three shortcodes: embed, gallery, and
 caption. None of them are relevant for something other than a post. It
 looks like the caption shortcode would work (but is pretty much useless)
 and the gallery shortcode would just rely on whatever the post global is
 currently.

 But, the embed code would fail. Hard. I haven't tested, but my impression
 would be that it would cache against the $post global. Since the specific
 post would constantly change for the contexts of a sidebar, the oembed
 response would get cached everywhere (first problem) and never be reliably
 cached, resulting in HTTP requests on every pageload (second problem).

 Only plugin shortcodes can benefit from adding do_shortcode() to
 widget_text. Generally, we've used the guideline that until something
 benefits something that core does, it's probably not worth it. Worse, in
 this case, a core shortcode would result in bugs.

 ***

 After writing all of this, upon further inspection of how the embed
 handlers register the [embed] shortcode, it can only work for posts, and
 will gracefully fail with `__return_false` for widgets.

 However, I think there are enough problems here with wpautop/shortcodes to
 revert and deal with it in 3.4, given we are in RC and it will only
 benefit plugin shortcodes.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10457#comment:33>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software