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.
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
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 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?
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 ) ā¦ As long as it does not affect the āeditorialā content.
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.
) ā¦ As long as it does not affect the āeditorialā content.