[wp-trac] [WordPress Trac] #22829: Corrupt Gallery-Output

WordPress Trac noreply at wordpress.org
Sun Dec 9 16:09:16 UTC 2012


#22829: Corrupt Gallery-Output
--------------------------+--------------------
 Reporter:  Bichareh      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.5
Component:  Gallery       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  close         |
--------------------------+--------------------

Comment (by nacin):

 Replying to [comment:3 DrewAPicture]:
 > Looking at the permalinks, it's more obvious.
 >
 > In 3.4.2, this is what my permalink would look like for a gallery image
 attachment page:
 > {{{
 > gallery-test-3-4-2/drew-picture
 > }}}
 >
 > All gallery-attached images have `gallery-test-3-4-2/` prepended, e.g.
 post context.
 >
 > In 3.5, it looks like this:
 > {{{
 > attachments/drew-picture
 > }}}

 That's only accurate for images that were not uploaded ("attached") to a
 post. In 3.4.2, they *couldn't* be added to a gallery. In 3.5, they can.

 This entire bug report is based on the new custom galleries not going
 along with adjacent_image_link(), previous_image_link(),
 next_image_link(). These functions are used in Twenty Ten, Twenty Eleven,
 *and* Twenty Twelve. It's simply something we didn't prepare for.

 Not to brush this use case off ''entirely'', but I personally find
 attachment pages a waste that shouldn't exist for 95% of users, and
 clicking through them one-by-one as a terrible experience. Carousels —
 which can support these custom galleries — are much better off.

 I think we could solve this by implementing a /gallery/ endpoint on a
 post. Then it would take either an attachment ID (which could be
 duplicated) or an index (which could change), and we would parse
 post_content to figure out what is previous/next. We can have the endpoint
 essentially serve attachment pages under the hood, but avoid the
 implications of ugly URLs trying in vain to pass state around.

 See also #22806, which I punted. This does not seem feasible to fix 3.5.0.
 We should however:
  * Add a filter to adjacent_image_link(), '''now'''.
  * Come up with a clever cookie-based solution (perhaps?) as a potential
 hotfix.

 Also note that before 3.5, the gallery shortcode allowed any arbitrary ID
 in the "include" shortcode. Not saying that was used often — or ever — but
 we're technically just exposing more UI this release, that's about it.
 But, "exclude" was fairly commonly used, and that *wouldn't* work to
 exclude images from the prev/next images loop.

 Also note that in 3.5, we're not forcing anyone to use this approach. I
 think we could handle most of this by A) defaulting to "Uploaded to this
 post" rather than all "Images" when creating a gallery, and B) attempt to
 save menu_order inside gallery sorting. We currently do menu_order saving
 inside "Uploaded to this post", so (B) might be tough to pull off without
 causing two different screens to compete with each other.

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


More information about the wp-trac mailing list