We can use
but we can also use
In the first example we get a field value. In the second example we use a built in function to get the url.
I once tried to use
url as field key but when I tried to use
$page->url() it failed because it’s used by Kirby alread.
Is it a big deal or not? I could just rename my
url field to something else? However it’s not the only field key I can not use.
Here is just a few, already blocked by Kirby…
archives audio children code content date delete depth dirname diruri documents file files find grandChildren hasArchives hasAudio hasChildren hasDocuments hasFiles hasImages hasInvisibleChildren hasNext hasNextVisible hasPrev hasPrevVisible hasTemplate hasVideos hasVisibleChildren hash hide id image images index intendedTemplate intendedTemplateFile is isActive
There are many many more. I just got to “i” before I gave up.
It can be hard to choose a field key that does not conflicting with a method in Kirby. Especially because Kirby grows for each version with more and more methods. Soon there might not be a single field key word left to use?
So what to do?
- I don’t know, but I know that it can be a problem.
- Maybe not add more methods to Kirby in the future, but that does not seems like the correct solution.
- Maybe not use fields the same way we use methods?
- Maybe use the field key in the first place if it exists and Kirby core method in second place?
My suggestion here is to think about it because I don’t have a solid answer to it.