[wp-hackers] GSoC 2011

[Thomas Van Eyck]

scribu <mail <at> scribu.net> writes:

> 
> >
> > For starters, there is a lot more to say about a media file than just what
> > the
> > table says now, and no point in filtering/sorting metadata that isn't there
> > to
> > begin with. Even with the wp_postmeta table, it looks even more forced in.
> >
> 
> There already is a wealth of metadata stored in wp_postmeta (including EXIF
> information), but it's crammed under a single key: wp_attachment_metadata.
> 
> Besides that, there's nothing inherently limiting about the current schema.

Performance and maintainability being the most important. As this is extended, 
its much more likely to break. Besides, designs like this are never inherently 
limiting. Its one giant string. 

Also, lets agree that NextGen gallery is a good example of some of the 
functionality user want. I don't understand than why they don't use this 
limitless schema ;) From a users point of view that btw adds up to the 
confusion. As a new WP user you add some media, make a gallery. You reach the 
limits of the built in system, so you add a plugin, only to discover that all of 
you previous work adding metadata was in fact pointless. No shared backend 
between these plugins, not even for the very basics.

> 
> I assume the entire media support was added this way to benefit from the
> > comments
> > support throughout the rest of the code. Furthermore, the other mentioned
> > features are missing or incomplete. The DB part is one thing, the API to
> > manage
> > it is another.
> >
> 
> No, it was done this way precisely to benefit from the API you think is
> missing: get_posts(), add_post_meta(), register_taxonomy() etc. etc.
> 

Post != media. It explains why it always feels like sthg is missing when working 
with media in wordpress. I never said just missing, I said missing or 
incomplete. And yes I have not studied this entire api back and forth, but I 
have checked a few things on my list and there is no real way to do this from 
the core.