[wp-trac] [WordPress Trac] #39439: Attachment update and GUID
WordPress Trac
noreply at wordpress.org
Mon Jan 2 15:36:32 UTC 2017
#39439: Attachment update and GUID
-------------------------------+------------------------------
Reporter: jlambe | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Posts, Post Types | Version: trunk
Severity: normal | Resolution:
Keywords: close | Focuses:
-------------------------------+------------------------------
Comment (by jlambe):
@MattyRob It's not a bug but can't choose another term for this issue
discussion :)
Currently our code do not update the `guid`. We use the
`wp_insert_attachment()` function to create or update the attachment post
and set the `guid` property for its `$args` on each import like so:
{{{#!php
$args = array_merge($args, [
'post_title' => $file['basename'],
'post_content' => '',
'post_status' => 'inherit',
'post_mime_type' => $image['type'],
'guid' => $image['url'],
]);
/*
* Insert/update attachment to posts table.
*/
$id = wp_insert_attachment($args, $image['file'], $organization_id);
}}}
When the core function is called, the `guid` property passed on update is
different from the one already stored. The issue is that the core function
do not update the `guid` because of this RSS feed unique identifier thing
but in our case it is non sense even if it doesn't break things (at least
for now) as it do not reflects "reality" as the `guid` value points to a
file that no longer exists.
So the discussion here is, should we update the core function to also
handle the `guid` for attachments (on update) if the original file no
longer exists? or perhaps provide an option to authorize `guid` update
whatever post type is (but this is dangerous as the developer should
provide an expected `guid` to avoid to break things) ?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/39439#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list