[wp-trac] [WordPress Trac] #19110: Media File Url
WordPress Trac
wp-trac at lists.automattic.com
Thu Nov 3 11:15:48 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 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()}}})
!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).
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 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).
> 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.
--
Ticket URL: <http://core.trac.wordpress.org/ticket/19110#comment:6>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software
More information about the wp-trac
mailing list