Before UUIDs Kirby didn’t impose any fields on my content: I was free to do what I wanted. Now it’s gone.
It’s still there. You’ll be able to turn off everything with the upcoming 3.8.1 as previously mentioned.
As for the rest, this to me feels more like an ideological battle more than anything else. You don’t like this specific implementation of this specific feature apparently and that’s ok.
Perfect! And does this mean that all of Kirby’s features and plugins will work with this option disabled in the future? Can you guarantee this now?
Of course not!
I just don’t like this technical choice because it breaks a very important rule, that’s all. Nothing ideological behind it, just technical.
That’s it, I’ve stated my views on the matter and my misgivings about so.
I feel grateful for such passionate discussions because it seems like you really care for Kirby and its future.
We have plenty of such discussions in the team with every feature we build and sometimes they are quite difficult to be honest. It’s always a fine balance between multiple questions.
How useful is the feature for our users and how many users will benefit from it?
Does a new feature help to bring Kirby forward and drive adoption?
How complex is it to build the feature?
What are path dependencies and roadblocks that we have to overcome first?
What are performance implications?
How complex will it be to maintain a feature?
What will be possible side effects for Kirby’s ecosystem?
etc.
The UUIDs were the most requested feature for a very long time on our feedback platform with 378 votes before we completed it. Lots of people have been quite annoyed by the lack of it and even called it a roadblock for various Kirby projects. There have been a lot of passionate discussions around it as well. As soon as you start working with any kind of relationship (users, files, pages) the lack of UUIDs meant potentially nasty broken content states. It just felt like a massive bug when you connect a file with a page and then the filename changes and the relationship is suddenly broken. It’s impossible to explain to any editor that this is design choice in Kirby. It was basically a pretty obvious weakness of our system.
It took us so long to overcome this weakness for two reasons:
there was @bnomei’s plugin, which mostly fixed it and bought us time
because we discussed the questions above over and over again and worked on possible concepts that would hopefully make the majority of our users happy and be as future-proof as possible.
To keep our content files as human readable and writable as possible has been one of our core principles since day one. We always want to make sure that you can keep on using Kirby without the Panel. But as mentioned above, we sometimes simply don’t find a better way than to break this principle. The blocks field now stores its content in JSON because of too many YAML issues, the sorting of images is stored in the content files, because we don’t want to force sorting numbers into file names, the UUIDs are now stored in the content files for all the mentioned reasons above.
I truly believe that all we build has to serve as many people as possible. A technical solution that is pure and elegant and conceptually clean, but still stands in the way of our users isn’t a good solution.
But with UUIDs, I actually don’t even think that we break our principle of human readable/writable text files at all. It truly is a user-focused feature and not just a technical necessity. It means that you can give your content a unique identifier that will be persistent. It means that you gain a lot more freedom to move your folders and files around without breaking links or relationships. It actually enhances your editing experience and the quality of your content in my opinion. The way we implemented it allows you to choose your own UUIDs. UUIDs are only generated lazily as soon as they are needed for the first time and they can all be human-readable. It is still 100% your content, but with the added benefit of being able to properly link content in a reliable way.
And yet we listened to the feedback that there should be an option to disable it if you really don’t like it. We added this because we understand this wish to keep your content files as clean as possible. Can we guarantee that no feature or plugin will ever rely on UUIDs? Of course not. But as soon as we add an option, we know that we have to carry this option around. It means that we now have to find ways to work with disabled UUIDs in the future. That’s quite a lot of commitment on our end to be honest.
We try hard to make everyone happy and of course this is not always possible. But I hope you understand that there’s a lot of thought going into every decision.
Thank you for the precise and complete explanations. I did not participate in the design of this functionality and therefore do not know the details and the reasons for the technical choices made.
With my remarks, I bring my user’s opinion, my skills and experiences acquired throughout my life as a computer scientist and finally, also a part of intuition. And I maintain after all I have read on the subject that the technical implementation of this functionality is not correct and must evolve. The deactivation of this functionality is, in my opinion, only an emergency measure, not at all permanent as you indicate.
In conclusion, I would like to stress that my criticism is focused on the technical implementation and not on the functionality itself. And to be honest, this really casts a shadow over my perception of Kirby because I feel that something important has been broken and that in the medium term this will impact on my use of it.
Not that anyone was asking, but I personally see UUIDs as editorial content, just like the slugs.
I think of them like permalinks.
I mean, is this that bad?
poem.txt
Uuid: carroll-jabberwocky
----
Title: Jabberwocky
----
Text:
'Twas brillig, and the slithy toves
Did gyre and gimble in the wabe:
All mimsy were the borogoves,
And the mome raths outgrabe.
...
The poem is then forever accessible under /@/page/carroll-jabberwocky (a link you are again gonna use in editorial content) - no matter where the poem is gonna be moved or if the parent page poems gets its URL changed to poems-and-songs.
Opinions, I guess.
But, would you, as a notepad content editor, honestly want to write / edit / check that field in something like a separate file?
The question does not arise in these terms since, in my opinion, this field does not have to be managed by the user. So it is present in a separate file that the user should not touch.
Because there is a mix-up in the use of this UUID field, which is originally a reference, i.e. an identifier that uniquely and unequivocally designates an object. And which also becomes something else, a permalink in your example.
And, if there is a need to customise it then the presence of this field in the content file would override the existing one predetermined by the system. And in this case it is edited in the same file as the content.
Honestly, if it wasn’t for the fact that I use the panel I’d do exactly this. And also UUID in this context are no different than the Slug field when dealing with multiple languages. It’s just a simple piece of information I attach to the rest of the content.
If I don’t use the panel I already have to keep an eye on folders’ names, file names and all that. Adding literally a single extra line of text doesn’t look too terrible to me.
And if I use the panel then kirby does all this for me and so I don’t see the problem with the line being there in the first place.
idk.
In my humble opinion the ID should be atomically bound to the content block it represents, and by definition in a file based system, this can only be guaranteed if it is the same file. Doing otherwise imo opens the door to mistakes and unhandled errors.
If there’s another solution, the only one I’d see would be to encode it in the filename, like “poem[uuidhere].txt” or something. But that would mean having separate systems between pages and files, since users wouldn’t want the uuid in asset filenames. Not ideal either.
I think it’s clear that there is no perfect solution (and the measure of perfect here is simplified to “satisfies both my and your requirements”); I see the unique identifier as part of the content and want it, as such, in my content, you see it as meta information that is more special than other meta information (like for example: date of publishing, author of content, slug translations, meta keywords / description / title, open graph stuff, etc). that needs to be stored separately.
The two requirements are just not compatible, so the only “solution” here would be to somehow extract the UUID generation / lookup / caching and storage as core components that a developer could override: a feature with, I think, a considerable cost to implement and maintain, but I guess one could suggest this on https://feedback.getkirby.com.
I guess one could add a uuid field to the page creation dialog with a plugin, with a hook that checks for uniqueness, this way panel users could specify a custom one, too.
Imho the uuid should also be more present in the panel ui; one can easily add it with an info field though.
Yes, I agree with the first part. Ideally, this information should be placed in the meta part of the file managed by the filesystem itself.
But this cannot be done. So the temptation is to move it into the file itself, i.e. the content, and that’s precisely the problem.
Or place the UUID in a file with the name “poem.meta” for example.
In doing so, the first control rule is straightforward: each content file must have an associated meta file.
Or place the UUID in a file with the name “poem.meta” for example.
In doing so, the first control rule is straightforward: each content file must have an associated meta file.
That would solve your issue related to the poem.txt file. So Kirby now have to open a directory, read the poem.txt file and then look for a poem.meta and read its content.
How about files though? If you have a picture.jpg you also have a picture.jpg.txt that contains editorial content. What’s the solution here? Another .meta file? So you get a picture.jpg.meta?
So for each file we would now get two extra files to store on the server. And kirby would have to read twice as many files every time which is probably a significant performance hit for no real benefit overall.
I’d honestly love this. At first I assumed UUIDs were random strings and so I didn’t even bother thinking about it but learning that they can ben anything user generated then it would make absolute sense to have it present in the admin.
Maybe even have an option to let kirby automatically generate them if people don’t want to bother inserting something manually.
The meta extension was only to illustrate the point. Might as well use the existing formalism for media files.
No, not 2 files but only 1.
Yes, one additional file per content.
Is an extra file of a few bytes for each content a problem with the current minimum hosting capacities?
Answer: NO
And no, Kirby would not have to read 2 files each time. A caching mechanism would smooth all this out. Once these two files are aggregated, this is no longer a problem.
So does it impact strongly on the performance?
Answer: NO
Even so, this is the cost of getting such a feature right.
In conclusion there is no performance problem that prevents such a solution.
In the current implementation the cost is an unreasonable mixing of data, which is error-prone: since the content can be changed by the user then the UUID can be changed too. And if the UUID is changed by the user this will lead to reference losses.
This is why it is necessary to prevent the user from modifying a reference as much as possible, which is impossible in a flat file system. The separation of the contents by placing the UUID in an additional file if it does not prevent this has at least the advantage of protecting it a little more from errors.
Well, no it’s two extra files. We already have an extra one. I upload a .jpg and I get a .jpg.txt that we can’t use to store UUIDs because it contains content and the entire point of this thought exercise is to avoid mixing editorial content with CMS generated one. So for each media file you have 3 files in total to deal with.
And no, Kirby would not have to read 2 files each time. A caching mechanism would smooth all this out. Once these two files are aggregated, this is no longer a problem.
So does it impact strongly on the performance?
Well now you’re implying that we also need to have a caching mechanism to deal with all this which is another extra and non trivial step.
This is why it is necessary to prevent the user from modifying a reference as much as possible, which is impossible in a flat file system.
I mean, if that’s your concern the easiest way to deal with this is to use the panel. This way the UUID doesn’t get in the way of editing. If the point is to not use the panel, to trust user to edit files directly (live on the server?) but to also not trust them to edit the UUID then I don’t think there’s a reasonable solution.
Because moving the UUID on a separate file doesn’t prevent other types of issues as you mentioned.
We have a feedback platform for such suggestions: https://feedback.getkirby.com If it turns out that this bothers a lot of people in the same way and your idea gets a lot of votes, we are happy to reconsider other options. But for now this is the most stable, performant and effective way to solve it.