Make WordPress Core

Opened 2 years ago

Last modified 3 weeks ago

#45708 new defect (bug)

Allow retrieving adjacent image link markup without echoing it

Reported by: flixos90 Owned by:
Milestone: 5.8 Priority: normal
Severity: normal Version:
Component: Media Keywords: has-patch needs-unit-tests
Focuses: template Cc:


Currently, themes can only echo image links (via next_image_link(), previous_image_link() and indirectly adjacent_image_link()), but not retrieve the markup before printing it. This is a problem, since you often want to manually print extra markup, however only if there are actual image links to display. You can currently of course accomplish that by using an output buffer, but that is far from preferred.

Most other templating functions have two versions, one for retrieving the markup, the other for echoing it (for example previous_post_link() and get_previous_post_link()). We should add the necessary counterparts for these ones too.

As another indicator that this has been needed for a long time, you might want to look at this article from 2009: https://katz.co/911/

Attachments (1)

45708.diff (4.7 KB) - added by flixos90 2 years ago.

Download all attachments as: .zip

Change History (6)

2 years ago

#1 @flixos90
2 years ago

  • Keywords has-patch added; needs-patch removed

45708.diff introduces the following functions:

  • get_adjacent_image_link()
  • get_next_image_link()
  • get_previous_image_link()

Their whole code is what was previously part of the respective function without the get_ prefix, with the only exception that the result is returned instead of echoed. The existing functions are now simply wrappers echoing the output of the new get_*() functions.

This is in line with how other templating functions act.

#2 @DrewAPicture
2 years ago

  • Keywords needs-unit-tests added

Seems sensible to have a getter, though I'm a little torn on whether we need to introduce three new functions just so there's getter parity for both of them.

#3 @mor10
2 years ago

@DrewAPicture I think getter parity is the entire point here. I remember working with the existing functions here and having to do a lot of extra work just because the get_ functions were missing. There should be parity across different similar functions which is what @flixos90 is proposing.

This ticket was mentioned in Slack in #core-media by antpb. View the logs.

3 weeks ago

#5 @antpb
3 weeks ago

  • Keywords 2nd-opinion removed
  • Milestone changed from Awaiting Review to 5.8

This issue was discussed in a recent Media bug scrub. It's agreed that parity is the goal here and valid. Moving this to 5.8 to keep track of it as it seems to have been buried over the last two years. The only thing currently blocking this is unit tests for the three new functions.

Note: See TracTickets for help on using tickets.