[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:16 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
 ''[http://en.wikipedia.org/wiki/Straw_man_proposal 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 [comment:17 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?

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