WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 12 months ago

#18286 closed defect (bug) (wontfix)

Upgrade script to fix non-unique page GUIDs

Reported by: alexkingorg Owned by:
Milestone: Priority: normal
Severity: major Version: 3.2.1
Component: Upgrade/Install Keywords: has-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)

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.

Attachments (2)

cf-guid-fix.php (1.9 KB) - added by alexkingorg 5 years ago.
Proof of concept plugin to uniquify GUIDs in possts table.
patch.diff (1.3 KB) - added by alexkingorg 5 years ago.
Cleanly integrate changes into upgrade process

Download all attachments as: .zip

Change History (14)

@alexkingorg
5 years ago

Proof of concept plugin to uniquify GUIDs in possts table.

#1 @alexkingorg
5 years ago

  • Keywords has-patch added

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
5 years ago

Cleanly integrate changes into upgrade process

#2 @nacin
5 years ago

Hmm. This only affected pages, IIRC.

#3 @alexkingorg
5 years ago

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/

#4 @nacin
5 years ago

Well that sucks.

#5 @alexkingorg
5 years ago

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.

#6 @azaozz
5 years ago

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.

Last edited 5 years ago by azaozz (previous) (diff)

#7 follow-ups: @alexkingorg
5 years ago

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.

#8 in reply to: ↑ 7 @nacin
5 years ago

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.

#9 in reply to: ↑ 7 @azaozz
5 years ago

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.

#10 @alexkingorg
5 years ago

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.

Version 0, edited 5 years ago by alexkingorg (next)

#11 @SergeyBiryukov
3 years ago

  • Description modified (diff)

#12 @chriscct7
12 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.