WordPress.org

Make WordPress Core

Opened 6 months ago

Last modified 6 months ago

#45708 new defect (bug)

Allow retrieving adjacent image link markup without echoing it

Reported by: flixos90 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Media Keywords: 2nd-opinion has-patch needs-unit-tests
Focuses: template Cc:

Description

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 6 months ago.

Download all attachments as: .zip

Change History (4)

@flixos90
6 months ago

#1 @flixos90
6 months 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
6 months 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
6 months 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.

Note: See TracTickets for help on using tickets.