Uuid's and deployment from local to remote server

Trying to understand the generation of uuid’s …

If I understand correctly, uuid’s generated locally break when a site is deployed to the remote server? (rather frustrating having to update files and menus and such)

I guess enabling the generation of uuid’s on the remote server is the way to go?

I’m not sure about your setup, but I think what you should absolutely not do is to update the Kirby folder remote and local without the content folder. Because it would initially generate different uuids for the pages and files in the content folder.

I would make a complete copy of the remote page, generate all uuids and deploy complete. That way all uuid are consistent and don’t differ. Future pages, files etc. will already have a uuid at deployment, so there’s no problem.

I guess enabling the generation of uuid’s on the remote server is the way to go?

You might rely on uuids in your templates etc., so you would need them locally?
If you don’t rely on them, disable them altogether.

Ok, thanks for that link ( Generate UUIDs for all pages and files)
going to try that some time, but after updating files and menus for the 3rd time I’ll wait :wink:

I like the uuids for things like custom menus, but I got some confusing situations when I duplicated complete pages including files, where files referenced to their original origin … gets very messy imo.

I like the uuids for things like custom menus, but I got some confusing situations when I duplicated complete pages including files, where files referenced to their original origin … gets very messy imo.

That has just been fixed with 3.8.2

  • Fixed duplicated UUIDs for pages and files when copying/duplicating pages #4831

Aha, that’s great!

Meh. As far as I understand it, they fixed only the problem of duplicated uuids. The more complex problem of page copies referring to the original file/page is still there.

Well, that’s not so great and a show stopper for me, hope things get sorted.

For most Kirby sites out there I personally would disable the UUID feature. IMHO it’s not ready

You’re right. Sorry, I missed that part.
I was always on the side of “please uuids”, but it seems to make it a hell of a lot more complex…

Sigh, I came to Kirby, some time ago, for it’s simplicity … so many things to consider now.

For most use cases you do not need them at the moment.
But I hope uuids get stable enough that I can update my sites because I’d like to have the possibility to have clients to change file names via panel. Not always working without breaking them (when no uuids are used) because the CMS loses the linking to them.

Well, if I remember correctly uuids have been announced as the thing we have been waiting for and I’ve had enough clients being very confused about menu’s breaking because they forget to update so ‘most use cases’: it just depends.

I imagine it’s technically complex, because of how content works in kirby: it’s handled by fields and field methods, both of which might come from external plugins. Kirby doesn’t necessarily know the inner structure of a content field, it just sees plain text. To do the duplicating logic properly™, it would need to delegate it to the fields, and even this only works if the installation uses blueprints.

But it’s also conceptually complex. Choosing which links need to be updated seems arbitrary: there are cases where you actually would want to keep a reference to the original; it completely depends on the use case and finding a generally working rule that satisfies most users is tough.

If you describe your use case we might find a way to make it work for you via a page.duplicate:after hook. Like if all you need is updating a list of files that are copied together with a page, iterating over the duplicated content and literally just replacing old uuids with new ones should be rather simple and stable (even without interpreting the above mentioned “plain text”).

I guess what I would like is disable globally and enable on certain fields. But never mind I work around what is possible without ‘jumping through all sorts of hooks’. I totally understand the complexity and think highly of the people involved to come up with workable solutions. Thanks for all the input.

I have proposed a way forward for UUIDs.

1 Like

May I ask you what you mean by this? I’m not sure i follow you when you say that page copies are referring to original file/page

After duplicating a page and including all files: When, for example, you click on a file on the copied page you will end up on the original page, so the page which was duplicated.

This could be very confusing and imo counter productive in the process of copying a page with files.

Mmmm maybe i’m not understanding the issue here but if you clone a page and you click on a file in a section, you don’t get redirected to the original cloned page. You get redirected to the correct file page inside the cloned one.

If you click on a file on a files field, what you’re describing is happening. But to me that is the intended behaviour. You are cloning a page with an UUID stored in the content and it makes sense for that reference to be preserved.

To me, if a page A contains a reference inside the content.txt to a file X, it makes sense for a cloned page B to also maintain a reference to that same file X.

I agree. Also, it would be very bad if Kirby tried to fiddle with the content. After all, this does not only affect files stored in files fields, but also for example inside a blocks or structure or object field. Replacing all these references would be making assumptions and also error prone.

For these use cases, it might be a better option to store the files in a central location or the parent of the subpages to duplicate. Then this behaviour wouldn’t matter anymore.

I don’t see how that would help with the issue at hand though. The problem here, when it comes to cloned pages, is what to do with UUIDs that are within the content itself.

If inside my main content.txt file I have a regular image that is referenced by UUID, what do you do when you clone the page?

You were very much against Kirby toucing the content when it comes to inserting a UUID reference so I’m sure you’re also against kirby scanning your content and updating UUID references.

So storing UUIDs in a different file or some other way doesn’t really solve the main issue which is, IMO, unsolvable in the contest of a file based system.

The only way to work around that is to have the media content stored separate from the rest of the content but that is not something that’s going to happen.

Actually, the only “solution” I can think of, would be to use composite UUIDs for media content. So, for example, if a page uses an UUID of some-page all the media files could use that as a prefix and you get things like some-page-your-file. And so when it comes the time to clone the page you can programmatically update all the prefixes using your new page UUID coming from the cloned page.

This would still be quite error prone and also doesn’t factor in people who create UUIDs by hand which is also a possibility.