wp_posts – guid update

3 Views

Hello and please excuse if this has been answered before but we really need to make sure.

We have developed a website under a domain of ours and then moved it to the live site of the client. We have run a few sql queries in the db in order to update to the new url but when we search our domain name in the database, we get: 600+ matches inside table wp_posts (mostly revisions, but there are attachments and posts also).

Read More

We read in the codex of WP that we should NOT update that column but we are not quite sure how it would affect the site if we did. The files are still in our domain and we need to delete them, but we are thinking that since there are still instances in the database that call our domain, something might break if we did.

If someone can provide more info on the guid use and any suggestions in the above situation, we would be reaaally grateful.

thanks in advance

Post Views: 3

Related posts

Leave a Reply

1 comment

  1. The GUID should not be used to generate any URLs for the site (caveat below), so it shouldn’t hurt to leave them as they are… unless some badly designed plugin decides that GUIDs are a great shortcut to getting an URL.

    What the GUID is, is a globally unique identifier– global as in “throughout all space and time”. Feed readers use it to keep track of whether an item has been displayed or not. If you change the GUID everything looks new to a feed a reader and all your subscribers get flooded, potentially. I wish WordPress would swap to some other format for this field– a hash maybe– to avoid this “Is this an URL?” confusion. It isn’t an URL… well, except for attachment media, which is… o_0

    One exception is attachment media: Attachment media locations are
    stored as a URL in the GUID. If the default uploads folder needs to be
    changed to a different location, then the media URL will need to be
    changed in the post_content and guid columns of the posts table.

    This is all in the WordPress Codex. I don’t know if anything has changed in recent releases that the Codex has not caught up with.

    You should, as described, change your attachment media GUIDs.

    Now, if your site thus far has been on a development server and has never publicly published its feeds there should really be no issue with changing all of the GUIDs. No feed readers have seen the content and hence none of them should be tracking anything. I would argue that the Codex should specify that not changing the GUID applies to moving from one live domain to another and is not an issue when moving from a private server (localhost) to a public one.

    If this were a client site on my dev server that I was moving to a live domain, I would tend to change the GUIDs. It should help avoid puzzlement in the future if anyone started poking around in the database.