[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            |
-----------------------------+------------------------------
Changes (by MikeSchinkel):

 * cc: mike@… (added)


Comment:

 Replying to [comment:13 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 [comment:14 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?

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