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 
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.
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.