[wp-trac] [WordPress Trac] #16349: return list of images actually being used in post

[WordPress Trac]

#16349: return list of images actually being used in post
-----------------------------+------------------------------
 Reporter:  mcmasterp        |       Owner:
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Media            |     Version:  3.0.4
 Severity:  normal           |  Resolution:
 Keywords:  close            |
-----------------------------+------------------------------

Comment (by MikeSchinkel):

 Replying to [comment:20 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 [comment:21 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?

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