-
Notifications
You must be signed in to change notification settings - Fork 4
Add Real GUIDs plugin #68
Comments
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. |
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. |
One of the things I see platform doing is making WP smarter, it’s a small
detail but I think it’s a valuable one.
…On Fri, 11 May 2018 at 19:33, Ryan McCue ***@***.***> wrote:
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.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#68 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABbeYcvdJ3RcaNGtLKJQzCW9dilwUTfks5txdlzgaJpZM4T7Jaz>
.
|
FWIW, I would completely agree. UUID's are valuable in virtually any context. |
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. |
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? |
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.) |
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. |
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?
The text was updated successfully, but these errors were encountered: