[wp-hackers] GSoC 2011

[Otto]

On Wed, Mar 30, 2011 at 8:53 PM, Thomas Van Eyck
<thomas.vaneyck at gmail.com> wrote:
> 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.

You're underestimating it. Reading through your first post, there's
very little that you're proposing which isn't actually rather, well,
slightly-above-trivial to do. Okay, so much of it isn't there by
default, but extending the media system is pretty easy, actually.

Have you looked at Matt's Gallery page? The naming system? The people
tagging? The sometimes rather excessive EXIF data it's showing? See
http://ma.tt/gallery and http://ma.tt/person/veronica-belmont/ and
http://ma.tt/2010/12/paris-walk-and-dinner/mcm_6127/#image-meta for
examples.

All that is done with the core functionality, some template stuff, and
a plugin for the custom people taxonomy.

Adding extra metadata to attachments that you need for database query
functions (like let's say you want to sort on, ohh, Aperture size from
the EXIF data), is rather trivial. Off the top of my head, I'd hook a
function to "wp_update_attachment_metadata" which got the data I
wanted out of the metadata array (in this case, the aperture info) and
then did an update_post_meta to add a custom metadata of my own
choosing (_wp_image_aperture) to the postmeta for the given attachment
post. Querying on it then becomes a simple matter of query_posts with
meta_key set to my field, and order set to meta_value or
meta_value_num. Total would be about 10 lines of code, more if I
wanted to make it entirely generic (which would be rather a lot of
postmeta data, considering... better to only store separately that
which you wanted to sort on or use separately in some fashion).

The media system and its method of storing files is actually quite
robust. Could it be simpler and smaller with a separate table?
Probably. Would it be as capable or robust? Not really. There's
virtually no gain there and you end up adding a ton of extra code for
no benefits.

You mention "moving files around without breaking things", and while
that is a laudable goal, it's one that really is not beneficial to
most users and actively harmful to others. WordPress is really
designed with speed in mind, and most webservers are lightning fast at
serving static content, like images. Adding more table lookups and
such just to get the current location of the image isn't particularly
useful. The specific case of "moving things around" on the server is
not one of those things that 80% of users do. That's power-user
functionality. Most users upload their images and are satisfied that
it appears on the webpage. You rarely need any more than that. Heck, a
surprising number of users upload multiple copies of the same images
several times instead of using the gallery to choose the same image
again.

It's true that there's significant room for improvement on the admin
side of things, however this is entirely a User Interface issue, not a
design issue. The media handling system is extremely capable and
highly flexible already. It's really just the view of it that needs
some work.

-Otto