Upgrade script to fix non-unique page GUIDs

[alexkingorg]

There were versions of WordPress prior to 3.1 that created non-unique GUIDs in the posts table.

#15041

This bug is fixed, but the bad data persists in many WP installs. Attached is a proof-of-concept plugin that could be included in the WordPress upgrade process to clean up these GUIDs.

In the interim, I'll probably release this as a plugin as we've got some folks using tools we built that need this fix ASAP.

[alexkingorg]

Proof of concept plugin to uniquify GUIDs in possts table.

[alexkingorg]

Here is a patch that integrates the previous attached code cleanly into the WP upgrade process. This also incorporates the changes suggested in ticket #18315

Note that the non-unique GUID issue affects pages and custom post types, this means that any feeds that use custom post types are likely to be invalid due to duplicate GUIDs.

[alexkingorg]

Cleanly integrate changes into upgrade process

[nacin]

Hmm. This only affected pages, IIRC.

[alexkingorg]

I'm pretty sure it also affected hierarchical custom post types as well. We just cleaned up a few dozen FAQs on our site that all had a GUID of: ​http://crowdfavorite.com/support/faq/

[nacin]

Well that sucks.

[alexkingorg]

For reference purposes, we had 120 pages and custom post types that all had non-unique GUIDs. I was using our DB as a test to write the SQL queries against.

[azaozz]

Think there is at least one older ticket proposing to change the GUID to using a truly random string. Perhaps it's time to implement that as we require MySQL 5 now. Don't think it will slow us down much if we go to the db and pull an UUID before saving a post for the first time.

Related: #6492.

[alexkingorg]

Changing existing GUID values would break anything that relies on those values. Adding a new UUID field seems fine to me, but please don't change valid GUIDs in the process.

[nacin]

Replying to alexkingorg:

Changing existing GUID values would break anything that relies on those values. Adding a new UUID field seems fine to me, but please don't change valid GUIDs in the process.

Same goes for an upgrade script, actually. Granted, the only thing that would break might be a feed reader, but still.

[azaozz]

Replying to alexkingorg:

Changing existing GUID values would break anything that relies on those values.

Didn't mean to suggest changing existing GUIDs only switching it to use an UUID instead of the permalink for new posts. If we go that way we probably can use UUIDs to replace any duplicate GUIDs too.

Adding a new UUID field seems fine to me, but please don't change valid GUIDs in the process.

Don't think another field is needed.

[alexkingorg]

Same goes for an upgrade script, actually. Granted, the only thing that would break might be a feed reader, but still.

Technically true, but the only thing changing would be rows whose GUIDs were already "broken" and not usable.

Didn't mean to suggest changing existing GUIDs only switching it to use an UUID instead of the permalink for new posts. If we go that way we probably can use UUIDs to replace any duplicate GUIDs too.

Ah, that makes sense. Certainly, I don't care what the format of the value is.

[chriscct7]

At this point, I doubt there's much value in making a routine anymore for this. 13 major WordPress versions and 4 years have elapsed since the bug would have caused issues and required a routine. By now, anyone running into this bug would have probably found a workaround in the form of a plugin, or hasn't updated.

Closing as wontfix.