[wp-trac] [WordPress Trac] #22085: Correctly assign post_parent to uploaded attachments in the new media modal

[WordPress Trac]

#22085: Correctly assign post_parent to uploaded attachments in the new media modal
--------------------------+--------------------
 Reporter:  koopersmith   |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  3.5
Component:  Media         |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by mdgl):

 Sorry I need to do a bit of "thinking out loud" here and I may have more
 to say on this later, but my first reaction to this is to ask "why would
 we want to assign post_parent to uploaded attachments"?

 Granted there are backwards-compatibility issues but I thought that in 3.5
 we were trying to do a thorough overall of media handling?  Scribu for
 example hints (comment:ticket:21776:22) that we are trying to "de-
 emphasize" the post_parent field for attachments.

 We also have long-standing tickets against the inflexibility of the
 current data model surrounding attachments (#10657 and related).

 So how is 3.5 moving us forwards other than just cleaning up the
 implementation of parts of the admin front-end?  What exactly is the
 content data model we are trying to create for attachments?

 I think that a clearer statement on the current and future intent here
 would be useful, to guide authors of themes/plugins and to help ensure
 that we create APIs with the right kind of abstractions.

 From my cursory inspection and knowledge, it seems that attachments only
 need to be given a post_parent to make the "gallery" work.  This is so we
 can obtain a list of all of the images attached to a post for display and
 create the appropriate next/previous image links.  Really what this is
 saying is that the "post" post type is (semi-)hierarchichal.

 Surely there is a better way to do this, even whilst retaining backwards
 compatibility?

 To me, the "gallery" looks just like a collection of posts, somewhat like
 a "nav menu" and should perhaps be a custom post type of its own.  Maybe
 we could reuse the current "nav_menu" but this might be a messy
 implementation.  In future, both could be abstracted into some kind of
 generic "post_collection" object.

 The ability to deal with collections of images might also be useful for
 handling retina displays and the [potentially - depending on
 standardisation activities] forthcoming HTML/CSS "image set" concepts.

 The current "attachment" post type is badly named as it appears to be
 really just a container for additional image/file metadata.  It could
 perhaps be renamed or at least reconsidered as "media_item" as it has a
 1:1 relationship with the uploaded image file.

 A new post type could be created to record the attachment of an image to a
 post (i.e. a real "attachment" post type). This would be the actual child
 of a post and would contain metadata about the referenced image (i.e. a
 link to the "media_item" post) and how how the image should be treated as
 part of the post to which it is attached, for example different size,
 placement, caption and so on. This would fix #10657 and is I think more
 elegant than the copying method described by aesqe for the "File Gallery"
 plugin (comment:ticket:10657:15).

 But why stop at just image attachments?  Why shouldn't I be able to attach
 any number of posts/pages or other objects to another post?  We already
 have the ability to have hierarchical posts (for "pages!) so this
 shouldn't be *that* difficult, should it?  IMHO, the combination of the
 current post hierarchy tree and generic "collection" post type would
 create a very simple and extremely powerful CMS...

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