[wp-trac] [WordPress Trac] #19110: Media File Url
WordPress Trac
wp-trac at lists.automattic.com
Mon Nov 7 10:41:44 UTC 2011
#19110: Media File Url
-------------------------+------------------------------
Reporter: braydonf | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Media | Version:
Severity: normal | Resolution:
Keywords: |
-------------------------+------------------------------
Comment (by braydonf):
Replying to [comment:6 dd32]:
> The Guid field simply stores the publically accessible URL to the
resource at present, this can either be the file url (for attachments) or
the Post/Page Permalink. If you Clear/md5 the Guid column, !WordPress
should operate as normal (or at least the default theme should, plugins
and other themes may be {{{_doing_it_wrong()}}})
>
That's great, some point would be worth it. If at all to avoid the
confusion of having the URL for the media stored in two places.
>
> !WordPress does '''not''' use the Guid field for anything other than RSS
feeds (It used to use it for the URL to media.. And still does for
backwards compatibility, but only if, and only if, all the other WordPress
attachment metadata is missing (or was never added since the image was
uploaded pre 2.3-ish)). The URL to the media is dynamically generated from
the site url(well, Content url) and the Attachment metadata (stored as
postmeta for the media posts).
>
md5/sha1 for each post would seem useful for more than just in RSS, such
as version control. Though the id for posts would be only part of the
issue.
>
> There is a metadata generation hook where you can insert/extract
metadata from uploaded files and store it as meta, WordPress extracts
image Exif data for example (but unfortunately, stores it as a serialized
field - which limits it's query-ability).
>
> The problem with adding another table (aside from the obvious; adding a
new table) is primarily the migration to a new table, and the fact that
for most things, it's not needed. Post Meta and Taxonomies can group
and/or store meta for a specific upload, not only that, but the specific
metadata one might want to store will change over time, requiring new
columns and generally scaling out of control.
>
'''The properties of video, audio, and images don't change.''' There will
be different codecs, but there will be codecs.
>
> The only downside to the current media situation (IMO) is the One-to-One
relationship of !attachment:post_parent -> post:id, A Attachment can only
have "1" parent post at present, which limits being able to include media
into multiple posts using the current [gallery] shortcodes (Neither of the
above suggestions address this limitation I should add, and in reality,
tie it into the current structure harder).
>
There should be a one-to-one relationship because the post should '''be'''
the media. The post_parent is a different issue, and it shouldn't be
favored to put media into a post for it to be published. Thus it's not
encouraged that it even have a post_parent property. Including the media
into different posts, such if needed, wouldn't set the post_parent
property, but could use another one that could use multiple ids.
>
> > The GUID field could also be used to store a random UUID version 4.
>
> This seems to infer you're thinking of WordPress 2, 3, and 4. WordPress
uses the Decimal versioning system, Version 3.2 -> 3.3 is more of a
Version 32 to Version 33 jump if you subscribe to the notion that the
first number represents a milestone in a product. When we reach 3.9, we'll
then go to 4.0, which will be as major as 2.2 to 2.3 was.
>
WordPress is unique in that way that major and minor version numbers don't
carry different weight, since the change from 2.2 to 2.3 was larger than
2.9 to 3.0. Version 4 UUID is the random generated UUID. There are several
types of UUIDs; Version 1 (Mac Address), Version 2 (DCE Security), Version
3 (MD5 hash), Version 4 (random), Version 5 (SHA-1 hash).
--
Ticket URL: <http://core.trac.wordpress.org/ticket/19110#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list