Skip to content
This repository has been archived by the owner on Nov 24, 2023. It is now read-only.

Add Real GUIDs plugin #68

Open
roborourke opened this issue May 11, 2018 · 8 comments
Open

Add Real GUIDs plugin #68

roborourke opened this issue May 11, 2018 · 8 comments

Comments

@roborourke
Copy link
Contributor

https://github.com/rmccue/realguids

This will help avoid issues with search-replace problems down the line and I think is generally a good idea. Would suggest adding it as a lib rather than a plugin.

@tcrsavage do you think this might impact at all on the migration code?

@joehoyle
Copy link
Member

Hmm why would we need this? You don't need to do url replacements on the GUID when moving data between environments - is it just that it makes that process slower if you do include the gui column? I'm a little unsure of adding this platform wide without I think a lot of benefit.

@rmccue
Copy link
Member

rmccue commented May 11, 2018

It makes differential imports easier if the GUID is never changed. Most (read: all) search/replace tools change the GUID, which messes up diff imports a bunch if they haven't accounted for it.

@roborourke
Copy link
Contributor Author

roborourke commented May 11, 2018 via email

@nathanielks
Copy link
Contributor

FWIW, I would completely agree. UUID's are valuable in virtually any context.

@joehoyle
Copy link
Member

For me, it's down to whether the gains are worth the edgecases we're going to hit by doing this. Whether we like it or not, there's a possibility of compatibility with plugins / 3rd party code that might expect that. This is of course the same trade off for things like S3 Uploads, which theoretically should work, but does come at a cost of compatibility. This is going to be a somewhat recurring theme I'm sure, and where we do decide to change the WordPress API we of course need to document that too. I've seen my fair share of (bad) plugins using GUID for some kind of cheap URL match / permalink.

@Japh
Copy link
Contributor

Japh commented May 13, 2018

I largely agree with Joe's sentiments here. I wonder whether we could run some sort of scan of the plugin directory to check for incidents of GUID usage to see just how likely these edge cases are?

It might not even be a bad idea to have a simple tool we run over plugins we're code reviewing to check for known incompatibility with our platform?

@rmccue
Copy link
Member

rmccue commented May 13, 2018

In the previous investigation we did for this in core/the importer (which I can't find now), essentially the only places the GUID is used are in RSS (where it's intentional) or in extremely old media plugins. The latter will be unlikely to work with S3 Uploads anyway.

While I doubt that anything is going to break due to this, I also think that if something does break it's going to be a good indicator that the plugin going to break in other cases. Failing loudly can help here.

It's worth also mentioning that we were planning on changing this in core itself, although that didn't happen as the importer moved off my priorities. There were no major blockers with doing so, although for extra caution we were going to avoid touching attachments.

(The benefits for imports are pretty substantial in my testing, as without this, you don't have any stable ID, which means you need a heuristic approach. This fails in a great number of cases.)

@rmccue
Copy link
Member

rmccue commented May 13, 2018

In the previous investigation we did for this in core/the importer (which I can't find now), essentially the only places the GUID is used are in RSS (where it's intentional) or in extremely old media plugins.

Addendum: by this, I mean that we actually did a scan of the plugin directory (as @Japh suggested) for uses of the GUID. I'll try and track it down, although it may have just been a conversation with Ipstenu somewhere.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants