$page->field_key() in collision with $page->method_name()

Kirby 2 Suggestions đź’ˇ
1

We can use

echo $page->field_key();

but we can also use

echo $page->url();

In the first example we get a field value. In the second example we use a built in function to get the url.

In collision

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.

http://getkirby.com/docs/cheatsheet#page

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.

2 
$page->content()->get('url');
3

Update

Yes that work, even with field methods…

$page->content()->get('url')->my_field_method();

Thanks @walkerbox

4

Huh. I’ll take a look at that when I get home. On my mobile at the moment. From the sourcecode content::get() returns a field object, which should have custom methods available since they’re just keys in its public static methods array. Not sure why that’s failing…

UPDATE: No worries. Glad to be helpful :slight_smile:

5

I’ll still leave this thread open for now. Maybe someone of you has an awesome idea on how to tackle this issue (because TBH I don’t :smiley:).

6

I think the solution I posted is reasonable. If the conflicts can be made irrelevant using existing methods then why change stuff?

1 Like
7

Yes, your solution is good.

Future

If Kirby grows with more and more methods, it narrows down the fields we can use with the shorter version. In the future we might always use the longer version to prevent collisions with built in methods.

8

Found this topic because the exact thing happened to me for file metadata: Used a text field named date which on updating from Kirby 2.2.x to 2.4.x broke my page, because a function of the same name had just been introduced, producing an error on the $file->date()->html() output.

Referring to the content collection by replacing the line with $file->meta()->date()->html() fixed this problem.
$field->content() actually refers to the (binary) file data.

I also assume that this is not a big deal but definitely something, that more rooted components, like plugins and themes should consider in their coding style.

1 Like