I’ve been reading everything I could find about UUID, migrations etc, including forum posts, and I still do not fully understand what it entails when sharing content among multiple servers.
In particular I usually download content from production to local (the full folder), and sometimes I dl partial content (not the whole folder, but a few relevant pages). In very few cases I UPLOAD modified content, but this is not something I really need.
I understand that UUID are server-dependant, is that correct?
Are problems bound to happen simply by downloading the content folder? or only if I download PART of the content folder, so there are UUIDs generated in Server A mixed with UUIDs generated in Server B ?
Are possible problems only broken relations ? or something else ?
UUIDs are only generated once for any content file. So every content file that has a Uuid field will never be touched by Kirby again. This means:
No. If you download your content from the production server including the UUIDs, modify the content locally and upload it again to the server, the UUID will stay unchanged.
There will only be problems if you work with content that does not have UUIDs yet. Because in this case it could happen that server A generates a UUID while you work with the content on server B, which would generate a different UUID. At this point the same page or file will have two different UUIDs, which breaks relations.
This is the reason why we strongly recommend to run the migration on the 3.8 update. This ensures that every page and file gets a UUID. After that you can copy content between servers however you need.
Newly created pages and files are no problem either. They will get a newly generated UUID, which is compatible with all the others on either server.
When you say “run the migration” you imply aswell to force the generation of all UUID, correct?
And, if I understand you correctly, if all uuid are generated, say, in server A, then I dowload content and create new pages, upload files, etc in server B, UUID are also generated for all those elements, and I can upload them to server A again, as they will not cause any collision or any kind of problem?
This assumes that uuid are generated on page, file… creation, is this correct ?
That’s exactly right. Kirby automatically generates UUIDs for every newly created page and file. These UUIDs will then be uploaded back to server A together with your changed and added content.
Because the length and character set of the UUIDs is quite large and the source for random data is the best that PHP offers, the collision probability is so low that collisions throughout dozens of years of normal use of Kirby are not to be expected. That’s independent from whether you use one or multiple servers.
If I have a site with content, and many already established relations between pages, using pages fields, if I generate the UUIDs in one go for this site, are the already established relations affected?
I mean, if I recall correctly, these relations are stored in content file using the selected page’s full path+slug… if we switch to UUID, are these stored strings replaced with UUID?
If the answer is ‘no’, then, can there be any possible conflict between these and new relations established using the same pages fields, which I assume will start using the UUIDs ? As there will be relations using full path+slug, and relations using UUID, cohabitating in the same content.
Not automatically, only when you save that content file again.
No, both the path relations and the UUID relations can coexist. Kirby automatically detects whether a value is a UUID or a path and looks up the linked page or file depending on that.
So in summary: If you follow the 3.8 migration guide, you don’t need to think about anything else and Kirby will handle the logic automatically for you.
Yes, thanks, but according to what you say I cannot assume that a migrated site is already using UUID for all previously established relations, but only for those in pages that are saved after the migration.
As far as I can see, there is no step in the migration process that ensures these relations are re-established using UUIDs.
Is there any way to force this? Seems to me it makes more sense to try and take advantage of UUID site-wide. Partial UUID relations do not seem useful, or… well… partially useful :))
Migrating all existing references requires saving all pages and files again. It should be enough to use $page->update() (which can be done in a loop over $site->index()), but I haven’t tested it.