Error when extending blocks and layout fields

[Daandelange]

Describe the bug
Extending a blocks or layout field doesn't work as documented.

To Reproduce
Steps to reproduce the behavior:

1. Take a 3.6 Starterkit
2. Extend a blocks and/or layout field like the docs :

   // site/plugins/myfields.php
   Kirby::plugin('daandelange/myfields', [
       'fields' => [
           'mylayout' => [
               'extends' => 'layout',
           'myblocks' => [
               'extends' => 'blocks',
           ],
       ],
   ]);

   // site/plugins/myfields.js
   panel.plugin('daandelange/myfields', {
     fields: {
       myblocks: {'template': `<div>HELLO!</div>`},
       mylayout: {'template': `<div>HELLO!</div>`},
     }
   });

3. Edit site/blueprints/pages/about.yml :
   1. Change type: layout to type: mylayout.
   2. Add a myblocks field in the same fields section : myblocks: true.
4. Visit /panel/pages/about and observe errors.

Expected behavior
I expect the mylayout field to extend the layout field without errors.

5. Change site/plugins/myfields.php to match : 'myblocks' => ['extends' => 'text' ], Observe the myblocks field working.

Screenshots

Kirby Version
3.6.0

[distantnative]

This is because layout and block fields got defined as classes internally, not in our usual nested array definition - for various reasons. There won't be a quick fix, I am afraid. This rather would be part of a larger refactoring of our backend code for forms and fields. Until then I am afraid extending these fields won't work, sorry.

[Daandelange]

Ok, thanks for your answer, I feared such an answer but I understand the reason. Maybe, until refactored, there could be a note in the docs that this is not possible (yet) ?

Btw, I've crossed several mentions like "wait until form refactoring" in kirby's source comments; but I couldn't find more information elsewhere... Is there any more information available on the plans for refactoring fields/forms ? Just curiosity.

[Daandelange]

Meanwhile, I got this to work as expected, defining a class name instead of a blueprint like Kirby does. 🚀

// site/plugins/myfields.php
use \Kirby\Form\Field\LayoutField;
class MyLayoutField extends LayoutField {
    public function __construct(array $params = []){
        parent::__construct($params);
    }
    public function extends(){
        return 'layout';
    }
}
Kirby::plugin('daandelange/myfields', [
    'fields' => [
        'mylayout' => 'MyLayoutField',
    ],
]);

// site/plugins/myfields.js
panel.plugin('daandelange/myfields', {
    fields: {
        mylayout : {
            extends: 'k-layout-field', // <-- use the native panel component ! ^_^
        }
    }
});

[distantnative]

Very smart!

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. This is for us to prioritize issues that are still relevant to our community. It will be closed if no further activity occurs within the next 14 days. If this issue is still relevant to you, please leave a comment.

[Daandelange]

So to sum up, the layout and blocks fields being Classes is a temporary solution/implementation on the Kirby side, they should become FieldClass (blueprints) over time like any other field, and Kirby doesn't officially support extending them.
Meanwhile, me and some other plugin authors started relying on extending these 2 fields using the method above and it works like charm. What about clarifying this situation by listing/documenting the unsupported fields here ?