Make WordPress Core

Opened 11 years ago

Closed 11 years ago

#24404 closed enhancement (invalid)

Allow get_the_post_format_image to return image without link

Reported by: tollmanz's profile tollmanz Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Post Formats Keywords: dev-feedback needs-patch
Focuses: Cc:

Description

When a user adds a link to an image post in the new post format UI, the_post_format_image() and get_the_post_format_image() functions will always return the image HTML wrapped in the link.

There are a number of cases in which a theme or plugin author may want to get the image without the link. For example, the author might want to wrap both the image and the title in a link. Having a link wrapped around the image complicates this.

I think we should either add a new parameter that allows the image to be returned without the link, or create two functions: one that returns the image with the link and one without the link. I personally find it a little misleading to use a function called the_post_format_image() and get an image wrapped in a link.

Separating functions that allow for returning just the image and the image with the link is important for flexibility. I think that wrapping the image in a link is making a decision that the developer should make and is limiting the developer without good reason. This will lead to some weird workarounds that will decrease the stability of community code. Having two functions instead of one does not increase complexity, yet it improves the flexibility of the API.

I'm happy to work on this if people think it's worth adding.

Attachments (1)

post-format-image-no-link.patch (2.4 KB) - added by jakemgold 11 years ago.
conceptually returns post format image without link…

Download all attachments as: .zip

Change History (9)

#1 @toscho
11 years ago

  • Cc info@… added

#2 @SergeyBiryukov
11 years ago

  • Milestone changed from Awaiting Review to 3.6

#3 @DrewAPicture
11 years ago

  • Keywords dev-feedback needs-patch added

+1

#4 follow-ups: @jakemgold
11 years ago

  • Cc jake@… added

So... I agree with the spirit of this strongly - we should be able to pull the data out of post formats independent of the formatted output. I even made a fairly basic patch (which I'll still attach for consideration). The patch adds a third parameter to the "get" function instead of introducing a new function.

However, I now think this might need much more refactoring and rethinking to get us "there".

As in your use case, we'd probably still want the link somewhere in *addition* to the image tag... so proposing just 1 new function for the image tag probably isn't enough. Furthermore, I can think of more use cases where we'd want the raw image source (e.g. using it in a background style) than just the HTML tag.

None of these would seem like big issues, except for the fact that the code for deriving the link and the image itself is fairly complex (arguably, convoluted). For instance, the code appears to tolerate a link typed in manually in the HTML mode. (In fact, it seems pretty tolerant of most HTML in there, which further breaks a "take control" use case.) That said, it does (attempt to) rip out the image from the free form HTML (before it substitutes it back into the HTML...).

In short, confidently deriving the same link that this function (as is) would generate is quite involved, and would mandate another round of (potentially) heavy-ish - and repetitive - crunching.

This makes me think we should have an independent handler for deriving both the image source and the link tag, storing them separately in the format_content cache, and returning them in an array or object (possibly with other data, like the actual width and height), independent of the functions that actually build the entire HTML output. In fact, I think that's probably essential. Actually, that processing should probably happen upon saving the post in hidden meta, instead of crunching through it on the display side.

Of course, 90% of this pain would go away if we'd get rid of this - IMO - out of place notion of allowing free form HTML for the image. In my opinion the choice should be URL for an image or upload an image. The link should also always be the link in the "click through" field, IMO. Seems more in keeping with WordPress's simplicity, and easier to control.

I can only vaguely imagine some edge cases where free form HTML might be useful, which seems like something better suited to a plug-in or extension.

I mean, I can literally put "<strong>hello world!</strong>" in the free form image HTML field and it will show up, with no image. How does this make sense?

Perhaps another ticket is needed...

@jakemgold
11 years ago

conceptually returns post format image without link...

#5 in reply to: ↑ 4 @SergeyBiryukov
11 years ago

Replying to jakemgold:

I mean, I can literally put "<strong>hello world!</strong>" in the free form image HTML field and it will show up, with no image. How does this make sense?

Related: #24301

#6 in reply to: ↑ 4 @tollmanz
11 years ago

Replying to jakemgold:

However, I now think this might need much more refactoring and rethinking to get us "there".

I'm glad you came out and said this. I was thinking the same thing, but was approaching this more gently to begin.

As in your use case, we'd probably still want the link somewhere in *addition* to the image tag... so proposing just 1 new function for the image tag probably isn't enough. Furthermore, I can think of more use cases where we'd want the raw image source (e.g. using it in a background style) than just the HTML tag.

I agree. I would want a function that gets me the raw image (or even attachment ID if available) and another to get the link.

This makes me think we should have an independent handler for deriving both the image source and the link tag, storing them separately in the format_content cache, and returning them in an array or object (possibly with other data, like the actual width and height), independent of the functions that actually build the entire HTML output. In fact, I think that's probably essential. Actually, that processing should probably happen upon saving the post in hidden meta, instead of crunching through it on the display side.

This is a great idea! I like the idea of standardizing the metadata that you get for an image. It would be nice to have access to the same data that you get with wp_get_attachment_image_src(). Having familiar data would be nice for consistency across functions.

Of course, 90% of this pain would go away if we'd get rid of this - IMO - out of place notion of allowing free form HTML for the image. In my opinion the choice should be URL for an image or upload an image. The link should also always be the link in the "click through" field, IMO. Seems more in keeping with WordPress's simplicity, and easier to control.

My take on this is that we might as well have the functions to grab images from the HTML since it is needed for back compat. This helps drive the post_formats_compat() function. I do think it makes sense to get rid of the arbitrary HTML input for the image though. I am not sure why this is needed and what problem it solves.

If we take the minimally "invasive" approach, I would think that we should parse out the image function from the link function and we could even have another function that pieces those two together. What are you thoughts?

I like your patch so far, but am wondering if now is the time to actually make some bigger changes to get this right before we have to forever support this original code.

#7 @Ralac
11 years ago

Thats a very important future. Just think about all the photo blogs how want to use only 1 image at a time with a special navigation and so on.

The src is important, just like the height, weight, EXIF and so on.

So we would be able to create a great working photo blog, not just a photo blog based on the data stored inside the post_content or like some other, not so great, solutions.

#8 @wonderboymusic
11 years ago

  • Milestone 3.6 deleted
  • Resolution set to invalid
  • Status changed from new to closed

these functions should be moved to the plugin - see #24610

Note: See TracTickets for help on using tickets.