Uuid's and deployment from local to remote server

That’s why I wrote that it’s conceptually complex, it really depends on your use case wether you want to update the links or not.
I guess the confusion comes from the fact that Kirby autonomously changed behavior between 3.7 and 3.8. In 3.7 files fields linked to a relative path (the local filename), while the UUIDs are always absolute. IMHO the UUIDs should have been an opt-in feature at least for file fields.

On the other hand, the UUIDs are really unique strings (by definition), it should really be doable to update the links yourself in a page hook with a simple Str::replace:

  • get files from the original, map them to their UUIDs
  • get files from clone, do the same
  • apply Str::replace to all fields with the two arrays

This way “page local” file references are updated, references to files in other pages are not

I agree with you that for most use cases it’s probably ideal to not use UUIDs because media pretty much always points to the page they’re stored in.

The best default setup would be to have UUIDs for pages and paths for files.

1 Like

I’m sure you are completely right, I’m just getting my head around the intended behaviour and the consequences. I’m a bit slow on the uptake and I had a surprising and confusing moment I had to get over. But seeing this turns out to be a quite active thread I might not be the only one :smirk:

To me it doesn’t: when I decide to make a copy I want to use that stuff as a new starting point to work with I don’t want any reference … just makes sense to me, so you see different angle …

The confusion comes, IMO, from the mixed behaviour when interacting with files fields and sections because they can look very much the same.

This is an example from the starterkit and it’s from a cloned page.

The cover is a field and as a result the data is stored inside the main content.txt file as

Cover: - file://tWNX7ZrzJUvS9Vad

When you clone the page, this reference doesn’t get updated by Kirby because as mentioned before, we really don’t want kirby to mess with your content.

As a result, if I click on it, i get redirected to the file inside the original source page.

The files section at the bottom instead, those are files from a files section and if clicked they point to the actual cloned files but that’s because they don’t reference UUIDs at all.

This can clearly be confusing in the context of UUIDs and the simplest solution, as mentioned before, would be to use paths insted of UUIDs when working with files.

I am not sure if there is a straightworward way to tell kirby to use paths everywhere when dealing with media files. Maybe it’s something worth having as an option somewhere?

@texnixe since you know more than me, is this already an option somewhere? I know there are options related to UUIDs (even though I can’t find them in the docs) but is there a way to turn them off only for media rather than sitewide?

What about subpages? Conceptually it’s the same ambiguity.

Oh absolutely. I’d argue that’s a more rare use case because i think not everyone clones pages and also not everyone clones pages with subpages.

But you are absolutely right in saying that it’s the same issue. But pages are more complicated in general because you often link pages that don’t belong to the same tree branch and so it’s even more messy.

But that’s a problem you’re facing even outside file based systems.

Absolutely. The point I’m making is that it will always be messy, and that the only solution I can think of is to give developers enough means and power to either configure the sections or make it simple to update the links yourself, the way you need.


This is a misinterpretation of my proposal, which is, in simplified terms, to separate “editorial” content from “technical” content. So, as long as the UUID information is stored in a separate “technical” content file, thus “reserved” to Kirby, Kirby is free to manage it as it sees fit: scan it, update it, complete it … ( it sounds like a daftpunk song :grinning:) … As long as it does not affect the “editorial” content.

Absolutely agree.

Even if you store it separately, at some point you have to reference content inside your editorial content. As I said, take a basic example as an image inside text:

You have some example text (image: ???) what do we insert there? Is the file name? Or is the name of some extra files you have created to store the UUID? So something like filename.meta.txt?

I think you misunderstood the problem in this thread. The problem is given by the links to files and pages that are editorial content by definition, those are embedded in the content. Extracting those isn’t feasible, nor would it really serve a purpose since the problem is conceptual, not technical: wether Kirby should or not update the links.

Please, I thank you for considering that I fully understand the problem with this thread.
:grinning: :grinning: