WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 19 months ago

Last modified 14 months ago

#16349 closed feature request (wontfix)

return list of images actually being used in post

Reported by: mcmasterp Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0.4
Component: Media Keywords: close
Focuses: Cc:

Description

Currently you can return a list of images attached to a post. This does not help if you want a plugin for example to be able to list just the images currently being used on a post. if you use the get_posts with type = attachment and post_parent = post->ID you get back a list of every image ever attached to that post whether or not they are on the post anymore. further if you reuse the image on a second post, and then run the same query on this new post, the image will not be returned at all because it is attached to the original post it was uploaded in. I am working with a plugin that adds an image notes feature to the post editor and it tries to list all images in a post on the editor but ends up listing irrelevant images or missing images that are attached to other posts. the plugin is knspr-imgnote if that helps. If I am wrong about this PLEASE I beg you let me know as it will help me a great deal.

Change History (26)

comment:1 mcmasterp3 years ago

FYI. this is the code I am using in that plugin that is not sufficient:

$args = array('post_type' => 'attachment',

'numberposts' => -1,

'post_mime_type' => 'image',
'post_status' => null,
'post_parent' => $postId

);

$arrImages =& get_posts($args);

It is from the knspr-imgnote plugin in the file knspr-imgnote-ajax.php around line 55

comment:2 scribu3 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
  • Type changed from enhancement to feature request

If you want to retrieve <img> tags in the post content, I suggest you use PHP's DOM extension. Or look at the various plugins that extract the first image from the post content.

Either way, this is not something that should be part of WP core.

comment:3 mcmasterp3 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Thank you for reviewing my request but I feel you missed what I was asking for.

I think it would be very useful to plugin and theme developers to be able to return a list of ALL the images on a post(not just the first) and use them in their plugin in the admin section. the plugin I gave as an example shows in the post editor a list of images from the post, except if you have added then removed an image it still shows in the list, conversely if you add an image that you already added to another post it won't show up in the list. This is a deficiency with the WP core code. the problem is that the WP core only tracks an images attachment to the first post it is added to.

Last edited 3 years ago by mcmasterp (previous) (diff)

comment:4 scribu3 years ago

  • Component changed from General to Media

So, what you're asking for is to sync the attachments with the image tags.

Ok, so what about external images, not in the Media library?

comment:5 scribu3 years ago

Also, what would be the benefit of this? besides the example you gave, which isn't clear why it would be useful, by the way.

comment:6 follow-up: nacin3 years ago

Seems like a duplicate of a ticket allowing attachments to have more than one parent.

comment:7 follow-up: mikeschinkel3 years ago

Replying to mcmasterp:

I think it would be very useful to plugin and theme developers to be able to return a list of ALL the images on a post(not just the first) and use them in their plugin in the admin section. the plugin I gave as an example shows in the post editor a list of images from the post, except if you have added then removed an image it still shows in the list, conversely if you add an image that you already added to another post it won't show up in the list. This is a deficiency with the WP core code. the problem is that the WP core only tracks an images attachment to the first post it is added to.

+1

Replying to scribu:

Also, what would be the benefit of this? besides the example you gave, which isn't clear why it would be useful, by the way.

This would enable a plugin author to write image image management tools that would actually know where the images are used. It would allow a developer to write SQL scripts to remove image records that are not needed yet keep ones that are. There are at least 3 distinct places in a recent project where I could have used this functionality. It's like asking why it's important to have a post_id field in wp_postmeta; without it data integrity is a challenge. I'm really surprised the use-cases are not more obvious.

comment:8 mikeschinkel3 years ago

  • Cc mikeschinkel@… added

comment:9 in reply to: ↑ 7 mcmasterp3 years ago

Replying to mikeschinkel:

This would enable a plugin author to write image image management tools that would actually know where the images are used. It would allow a developer to write SQL scripts to remove image records that are not needed yet keep ones that are. There are at least 3 distinct places in a recent project where I could have used this functionality. It's like asking why it's important to have a post_id field in wp_postmeta; without it data integrity is a challenge. I'm really surprised the use-cases are not more obvious.

Exactly. I'm surprised at the reaction I am getting, this feature wouldn't slap your grandma ;)

every time an image is uploaded it should receive an image_id number. Then every time you publish or updated a post it should scan it for what images are used and save their corresponding image_id to the posts meta data. Or something similar to that.

reliable image management in the editor should be a basic goal not an exotic feature. External images may just be to bad, I don't see how that would work but then again you wordpress developers are geniuses to me so who knows!

comment:10 in reply to: ↑ 6 mcmasterp3 years ago

Replying to nacin:

Seems like a duplicate of a ticket allowing attachments to have more than one parent.

that would only solve half the problem. you would still get images that were no longer being used on a post as attached.

comment:11 ocean903 years ago

  • Keywords image attachment query removed
  • Milestone set to Awaiting Review

comment:12 mcmasterp3 years ago

anyone get a chance to review this further?

comment:13 scribu3 years ago

  • Keywords close added

It's not actually that hard to parse "<img>" tags from the post content and store their ids as custom fields. There are plenty of plugins that do that already, but limit it to the first image or whatever.

So, I guess the resolution would be "plugin territory".

comment:14 follow-up: markoheijnen19 months ago

I also think this is plugin territory. It's something not a lot of people will need and I guess getting external images make sense too in some cases. In that case you do some kind of regex that gets all the images in post_content.

comment:15 in reply to: ↑ 14 ; follow-up: MikeSchinkel19 months ago

  • Cc mike@… added

Replying to scribu:

It's not actually that hard to parse "<img>" tags from the post content and store their ids as custom fields. There are plenty of plugins that do that already, but limit it to the first image or whatever.

It's actually a lot most complex concern than "parsing <img> tags in post content". There are featured images/thumbnails, there are attached images, there are both local and external images that are just referenced in HTML. And then there are images referenced via 3rd party shortcodes where it's simply not possible to generically discover these 3rd party images.

So, I guess the resolution would be "plugin territory".

Replying to markoheijnen:

I also think this is plugin territory.

I'd argue it's not plugin territory at all but instead API territory. I see this much like how people in the 2.5-2.7 era argued that what became custom post types was API territory. In hindsight those arguments were not well founded.

This is API territory because it takes quite a lot of experience to with WordPress and a lot of time in research on Codex and in studying the WordPress source code and a lot of trial and error developing to "get this right". Even then it's likely the implementor will have overlooked something relevant.

It's something not a lot of people will need and I guess getting external images make sense too in some cases. In that case you do some kind of regex that gets all the images in post_content.

Of the plugins client we've had ironically over half of them have needed access to post images in a generic manner and what we found is that the code is far from trivial. What we've discovered is that if you are going to do anything with images that would be considered more than trivial then you will have to research and implement some form of what is being proposed.

What's needed IMO is probably a function like get_available_images($object_id, 'post') that would return an array of images categories with subarrays containing some type of references to those images such as 'featured', 'attached', 'local' and 'external' where the latter two are inline in the HTML. Then there could also be a set of hooks to allow plugins to add image categories i.e. 'slide', 'headshot', 'cover', etc.

In summary, why burden everyone who needs this to have to spend a lot of time doing it poorly, and doing in a manner that is completely incompatible with anyone else doing the same thing? Why not have WordPress itself provide leadership in the area of post images?

comment:16 follow-up: markoheijnen19 months ago

You just proof yourself even more to close this ticket. The reason is that there are a lot of possibilities how someone wants to retrieve the information. Having categorized array is pretty ugly if you want the images on a certain way. Also post types is a completely other use case then this.

Something shouldn't be in core because it is hard to build or you really need to know WordPress. Something needs to get in WordPress because a lot of people want to use it.

comment:17 in reply to: ↑ 15 scribu19 months ago

Replying to MikeSchinkel:

What's needed IMO is probably a function like get_available_images($object_id, 'post') that would return an array of images categories with subarrays containing some type of references to those images such as 'featured', 'attached', 'local' and 'external' where the latter two are inline in the HTML. Then there could also be a set of hooks to allow plugins to add image categories i.e. 'slide', 'headshot', 'cover', etc.

Ok, and how would the OP use the 'local' subarray for implementing their image notes plugin?

Version 0, edited 19 months ago by scribu (next)

comment:18 in reply to: ↑ 16 ; follow-up: MikeSchinkel19 months ago

Replying to markoheijnen:

The reason is that there are a lot of possibilities how someone wants to retrieve the information.

It seems very straightforward to me, someone (a plugin or theme developer) wants to get a list of images associated with the post. One possibility, a list of images. How those images are associated with the post is an implementation detail and should at a high level of be hidden from developer who just wants a list of posts.

Having categorized array is pretty ugly if you want the images on a certain way.

My suggestion for an array of cartegorized images was simply a strawman proposal whose goal was to illicit discussion of how an API would be eliminated. Maybe we'll be more productive if we simply discuss the abstract need for an API to return the list of available images for a post, and ideally, for any "object" in WordPress in the same content that taxonomies handle objects?

Also post types is a completely other use case then this.

Sorry, I don't understand that point.

Something shouldn't be in core because it is hard to build or you really need to know WordPress.

I'm struggling to follow the logic. In part I would argue that that is exactly the reason something should be in core, especially if it's something that many plugin and theme developers need.

However, in this case I didn't say it was "hard" to build, I said it takes lots of time researching the implementation decisions made by the WordPress team and a lot of experience with images so that you can be sure to know all the different use-cases. For me, that's exactly the type of thing that makes sense to be in core.

What's needed is an API to simplify access and to ensure that more plugins and themes treat image associations to posts in a compatibly way. Plugins don't make for good APIs when the benefit of the API is to provide infrastructure for plugin and theme developers.

Let me give you two examples from core that are both very similar. They both have the same attributes you claimed meant they shouldn't be in core:

  • oEmbed - There are lots of possibilities for how someone wants to retrieve the information via oEmbed.
  • WP_Http - The are numerous possibilities for how a server might be able to process an HTTP call, and implementing this class is hard.

If the criteria you gave disqualifies adding an API that returns a list of available images for a post why wouldn't the same criteria have been used to relegate oEmbed and WP_Http to plugin territory?

Or maybe I misunderstand. Please help me understand why this wouldn't be a significant improvement for the WordPress ecosystem.

Replying to scribu:

Ok, and how would the OP use the 'local' or 'external' subarrays for implementing their image notes plugin?

Fair point, my first implementation proposal wasn't meant to be the best it was meant to spur discussion. Those attributes could be properties on an array of objects, or elements in an array of arrays.

What I'm advocating is not an specific implementation but instead a core API to return the list of associated images with metadata that explains how they are associated so the many themers and plugin developers that need this don't have to duplicate the effort, most of whom will do it sub-optimally when they do.

So doesn't an API to retrieve a list of associated images not make sense?

comment:19 F J Kaiser19 months ago

  • Cc 24-7@… added

+1 for that. My opinion on this ticket in general (will jump in depending on how acceptance makes progress): Image management is already (sorry to say that) kind of a mess from plugin perspective. There's no definitive "Do it this or that way" and every author is cooking his own soup. Getting a new UI is nice, but having a standardized, strong, reliable (and easy to use) API has my upvote.

comment:20 markoheijnen19 months ago

oEmbed and WP_Http are used everywhere in core. So don't use my criteria in a wrong way.
The list of all images belonging to a post is most likely being used by less then 1% of all users. The use case is poor and in most cases the user has no control on it.

I'm not even going in discussion about it even more. This is plugin material in my opinion not in yours. We can discuss what ever we want but that is not going to change. The ticket can also be open for years but that doesn't say this will going to be implemented.

comment:21 in reply to: ↑ 18 ; follow-up: scribu19 months ago

Replying to MikeSchinkel:

Let me give you two examples from core that are both very similar. They both have the same attributes you claimed meant they shouldn't be in core:

  • oEmbed - There are lots of possibilities for how someone wants to retrieve the information via oEmbed.

No, there aren't; you do a GET request to the endpoint. The oEmbed provider is the one responsible for returning something useful.

  • WP_Http - The are numerous possibilities for how a server might be able to process an HTTP call, and implementing this class is hard.

When you use WP_Http, you want to make a HTTP request; regardless of the transport the server employs, the effect of the request is the same: you get back a response object.

In contrast, with the proposed get_attached_images() function, how the images are associated to the post does affect what you can do with them. For example, you won't be able to manipulate an 'external' image the same way you could an 'attached' one.

Therefore, it's a leaky abstraction.

comment:22 in reply to: ↑ 21 MikeSchinkel19 months ago

Replying to markoheijnen:

oEmbed and WP_Http are used everywhere in core. So don't use my criteria in a wrong way.

And such an API would soon be used in several places in core, if it existed. Without it existing it can't be used elsewhere in core.

The list of all images belonging to a post is most likely being used by less then 1% of all users. The use case is poor and in most cases the user has no control on it.

Who are you defining as user? End user blogger, or plugin/theme developer? If the former I agree but does that make sense when we are discussing the need for an API? If the latter, I believe you are off by a factor of 50 or more. Based on our experience building plugins I firmly believe that more than 1/2 of themers and plugin developers would use this functionality directly or indirectly if provided by WordPress core.

I'm not even going in discussion about it even more. This is plugin material in my opinion not in yours. We can discuss what ever we want but that is not going to change. The ticket can also be open for years but that doesn't say this will going to be implemented.

You know for certain that you will never to change your mind on this subject no matter what new evidence you may discover? Really?

Replying to scribu:

No, there aren't; you do a GET request to the endpoint. The oEmbed provider is the one responsible for returning something useful.

You are artificially limiting the discussion. Ideally I would be able to get a list of URLs for the available images which is what a post images API could provide, and then I could use those URLs to create thumbnails, to display in a gallery, etc.. How is that not equivalent in concept to oEmbed?

When you use WP_Http, you want to make a HTTP request; regardless of the transport the server employs, the effect of the request is the same: you get back a response object.

When we want an image we don't care about the "transport" (i.e. where it's stored) we just want the image. We want a "reponse object" (i.e. image object.) I'm struggling to see the contrast with WP_Http here?

In contrast, with the proposed get_attached_images() function, how the images are associated to the post does affect what you can do with them.

So if you have a URL for each of the images you must treat them differently?

Yes, there are additional things you can do with some associated images that you can't do with others but why would that limit the primary benefit of getting a list of URLs? If there are some images that have capabilities others do not have and there are other use-cases that would handle them different we can give developers the metadata they need to handle them differently. Or not if the core team finds it offensive to do so.

But why not the list of the URLs for the associated images?

And why does the need to handle an abstraction differently in different cases invalidate it for use in core? We handle Post Formats differently, we handle Custom Post Types differently, we handle Comment types differently (Comments, trackbacks), why not images? For me core seems the perfect place to abstract commonly used things that need to be handled differently.

For example, you won't be able to manipulate an 'external' image the same way you could an 'attached' one.
Therefore, it's a leaky abstraction.

Every image can have a URL. Providing a list of URLs for available images is not leaky. As a strawman, what about this one?

get_available_image_urls($object_id)

Side note: I'm getting frustrated by this exchange and don't want that to color my replies, maybe you can help me understand why I should not be frustrated? I can't help but feel that tagging something "plugin territory" is currently very arbitrary and specific to the taggers own personal opinions and use-cases they have experienced, and that feeling is very frustrating for me. Is it unreasonable of me to want to see these decisions made objectively? Has anyone written an objective guide to deciding what is plugin terrority yet or not?

comment:23 nacin19 months ago

A decision is never going to be "objective". It is always going to be subjective, based on a person's own previous experiences, their knowledge of WordPress, their level of experience with WordPress and core development, and a multitude of other factors.

Maybe this will come up again in the future, but I also don't see this as core material for the time being.

comment:24 follow-up: scribu19 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

Here's another argument pro plugin territory:

If it were in Core, users would expect it to be reliable, i.e. work with any HTML you throw at it.

Other than using PHP's DOM library (which isn't always available, btw), the only other alternative is regular expressions. And we all know how reliable, readable and straightforward the code in wpautop() and kses is.

So, it would take a darn good use-case to convince people that it's worth the effort. So far, I've only seen hand-wavy statements that amount to "build it and they will come".

comment:25 in reply to: ↑ 24 MikeSchinkel19 months ago

Replying to nacin:

Maybe this will come up again in the future, but I also don't see this as core material for the time being.

Acknowledged.

A decision is never going to be "objective". It is always going to be subjective, based on a person's own previous experiences, their knowledge of WordPress, their level of experience with WordPress and core development, and a multitude of other factors.

I understand that. But I wasn't asking about decisions being objective, I was asking about an objective written criteria that we as a community can use to discuss what is plugin territory.

WordPress already has a philosophy page which helps greatly when discussing things that are affected by the "Decisions, not Options" approach.

Similarly companies have a mission statement so that when employees have ideas they can ask "Would implementing my idea support or distract from the mission?" Without a mission statement or a written statement of philosophy people are never really required to reconcile their logic with objective facts so criteria is rarely as valid when compared to community-developed criteria that might be created.

So I'm simply proposing that the WordPress team and community collaborate on a "What is plugin territory" document that can be used as a reference and guideline for future discussions. Whether there is the bandwidth for that right now or not, isn't that a reasonable thing to propose?

If you do agree it's work the effort, maybe an open discussion about the topic on one of WordPress' P2s?

Replying to scribu:

If it were in Core, users would expect it to be reliable, i.e. work with any HTML you throw at it.

Other than using PHP's DOM library (which isn't always available, btw), the only other alternative is regular expressions. And we all know how reliable, readable and straightforward the code in wpautop() and kses is.

Thank you. That's exactly the kind of objective criteria I was looking for. Accepted.

Last edited 19 months ago by MikeSchinkel (previous) (diff)
Note: See TracTickets for help on using tickets.