[wp-trac] [WordPress Trac] #25349: Can't retrieve calculated excerpt bound by <!--more--> on single page view

[WordPress Trac]

#25349: Can't retrieve calculated excerpt bound by <!--more--> on single page view
-------------------------------------+-----------------------------
 Reporter:  chriscoyier              |       Owner:
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Posts, Post Types        |     Version:  3.6.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  template
-------------------------------------+-----------------------------

Comment (by boonebgorges):

 I scanned through the plugin directory to see how many people were
 manipulating `$more` in this way. I found quite a few examples (around
 150). But of those, almost all of them will continue to work even after
 these changes. Most of them are manipulating `$more` while *inside* the
 loop - ie *after* `setup_postdata()` has run - so they will be immune.
 Others are forcing `$more` to 0, which I take to be a way of working
 around the bug that is fixed by this post (ie, respecting `<!--more-->`
 inside of a secondary loop). I found just a small handful that are forcing
 `$more = 1` *before the loop begins*. Here's the list, for posterity:
 siteorigin-panels, post-ajax-slider, share-juice, wp-frontpage-news,
 nrelate-related-content, d13slideshow, wordpress-mobile-pack-hunt, baap-
 mobile-version, dws-testimonials, wp-enjoy-reading, random-one-cat-widget,
 yank-widget.

 It makes sense that most plugin authors would choose to reset `$more`
 inside the loop: even before the changes in [30085], `setup_postdata()`
 would override this value in at least some situations. It just so happens
 that this didn't bother some plugin authors, because they wanted the value
 to be forced to 1 anyway. But IMO this doesn't change the fact that it's
 the wrong place to be overriding the value.

 In light of the relative rarity of the problem, and the relatively mild
 consequences of failure (it's not as if sites will crash), I'm going to
 make the call that we'll keep things the way they are in [30085], so we
 can retain the broader fix. NateWr, I'd recommend that you modify your
 plugin so that it modifies `$more` while inside of the loop. Thanks for
 playing along :)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/25349#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform