Kirby 2.2.x Incompatible with Legacy Field Names

The CMS Questions
1

Introduction

Apparently Kirby 2.2.x (silently?) introduced reserved words for field names, resulting in Panel error messages like…

The field name: url must not be used for pages.

Detail

Panel logic https://github.com/getkirby/panel/blob/master/app/src/panel/models/page.php#L176 shows that all Kirby Page method names but title and date have become reserved words for field names.

Legacy Field Issue

Unfortunately the logic mentioned above renders many Kirby instances that use a method of Page as a name of a field incompatible with Panel 2.2.x.

1 Like
2

That problem existed before, if maybe not with every field name, see this post

Making the page methods reserved word, is only a logical consequence, which makes it easier to identify those problems.

3

I git your point before, but anyhow: we should probably at least list all reserved word (aka Page method names) on that Panel error page. Should I try to come up with a pull request that adds this?

4

P.S. The issue above is not the same; even if you can use that PHP code to at least access data stored in fields using a reserved word as name, you still can’t edit such a page as a whole in Panel at all.

5

I know, the problem I quoted only existed when you tried to access the field in your templates, and not already in the panel. However, catching the error right in the panel before it can even make it to the templates, seems to make sense, don’t you think?

Edit: Of course, this problem will make updating a site more troublesome.

6

Okay. I’ll contact @bastianallgeier with a pull request to render that Panel error message even more EXPLICIT.

7

I think the current way things work in the panel is alright. Adding a complete list of reserved words might make sense.

Would it make sense to trigger a notice every time a field with a reserved name gets accessed in a template, reminding the developer to change the name to avoid future problems?

8

A list of reserved words in the error message can get quite long, I would prefer a link to the list of page methods in the cheat sheet.

9

@texnixe: That would not help either; even the cheat sheets does not list all Page method names. I rather have a automatically generated list of reserved words in Panel itself then relying on (mostly outdated) documentation.

10

I don’t see how this is a problem as you have literally the entire screen to display them.

11

It’s not a problem, it’s just a question of preference. And I would prefer a separate list I can refer to in the docs rather than a screenful of words in an error message.

12 
c::set('panel.show.forbiddenFieldList', true|false);

:slight_smile: Okay, let’s get serious again…

Maybe your idea is just way better. I haven’t checked out how panel translations work and whether there are fallbacks for missing languages like in the core? If there are not, maintaining the same list for each of the 10+ languages is a unnecessary complication (and hard-coding the list in the template file seems weird as well).

In that case I would agree with a link to the cheatsheet, if only for practical reasons.

13

@FabianSperrle: Can you please elaborate how this issue is connected to languages and/or translations?

14

@texnixe: As far as I read the change log carefully enough this new restrictions was not even mentioned there, which definitely should have happened, as it might break hundreds of Kirby instances out there.

They will break again, as soon as someone comes up with a new page method and forgets to update the documentation.

Documentation is a nice add-on, but IMHO not good practice for a list of reserved words that might change easily over time.

15

@FabianSperrle:

I think, I got your concerns now. They are irrelevant because these reserved words are due to naming of methods in Kirby core, reads, all English only. (At least as no one decides to come up with German Page method names in PHP.)

Last but not least: I proposed to automatically generate that list at run time from all Page methods available, i.e. to not hard code them in the documentation as proposed by @texnixe.

16

In the meantime, why not generate your own little list :wink:

<?php
$pageMethods = get_class_methods($page);
$allowed = array('title', 'date');
foreach ($pageMethods as $methodName) {
  if(!in_array($methodName, $allowed)) {
    echo "$methodName";
  }
}
?>

BTW: I did not say “hard-code it in the docs”, you can generate the list in the docs automatically as well using that little snippet above.

17

I guess it will be impossible for the panel to conclude the list of reserved words just from the PHP code. So there would still have to be a list of reserved words. I don’t know how the panel produces its messages, but I guess that they are all stored in translation files. In that case you would have to maintain the same list of reserved words in each translation file in order to display helpful messages.

18

Learn something new everyday :smile:

I’ll take everything I said about compiling that list by hand back then.

19

I already posted an issue on the getkirby.com repo about this. :smile:

I think the simplest way is to document the reserved words and maybe improve the error messages.

20

True. But what about Page Models extending standard Page object?