Panel field-error reporting became less precise

[mrflix]

When digging into #7597 I realized that the error message was more precise before Kirby 5.

This is what I get in Kirby 4.8.0:

The error message is at the field.

This is what I get now in Kirby 5:

The error message blocks the whole form from rendering, making it hard to find out which field broke it.

I would love to get the Kirby 4.8.0 error at field behavior back to save time on debugging.

[distantnative]

@bastianallgeier
I think this is caused by the Form/Fields/Field class refactoring now not catching the error anymore inside it classes and turning it into an error field - but bubbling up and only be caught in Panel\View::response().

The error bubbles up from https://github.com/getkirby/kirby/blob/main/src/Form/Field.php#L78 - so it might be a bit hard to catch in this place. But you are more familiar with these classes to maybe have an idea how/where to catch it again.

Do you know what $this->validate refers to here: https://github.com/getkirby/kirby/blob/main/src/Form/Mixin/Validation.php#L62. I could not spot the property anywhere.

[bastianallgeier]

The previous solution was pretty nasty to be honest. But I get that the errors are now less easy to debug. Maybe we need to go back to individual error trap fields again.

The validate prop can be set in the blueprint to add custom validation rules. It's pretty old and I just tried to find it in the docs but it seems like we don't even document that feature. 😬

[distantnative]

I think there are two parts two it:

• Having the line/file info can be helpful but often also not too much, so that's maybe not super crucial
• Having the error just make one field fail and thereby also indicating which field has the problem is very important I would think. Right now with the whole section or even view failing, the error message is often useless for finding the issue.

Regarding validate, but shouldn't it then be a property of the Validation trait? Right now, it looks like we are calling it but actually it doesn't exists and might only work via magic callers.

[bastianallgeier]

@distantnative the main problem with catching individual field errors is that we need to do that in the Fields::_set() method. This is where we create the individual Field instances. We only want that when we actually create props for the Panel. Otherwise, it's super annoying to swallow exceptions like that. This means that we would need some sort of Panel mode for the Form class, which activates that behavior only in certain scenarios.

The validate prop really is just a magic prop right now. As soon as we add it as existing prop to the Validation array, we will break the Field class again. It's another annoying part of the old legacy code.

[distantnative]

@bastianallgeier Do we really need to treat this as two separate things? I think even for usage outside of the Panel, it could be nice not to have the whole form explode without any good hint from where the error originated. I could see it even beneficial for those cases instead to replace the problematic field with an info field containing the error message.

I think we don't need to overcomplicate our lives here. The Form class has a lot of shortcomings anyways to use it for a frontend form so far, so maybe focusing ourselves more on our own usage for the Panel is alright.

[bastianallgeier]

In my point of view, we almost always want to get an exception as early as possible when we are not creating the panel view. I.e. when a form is submitted, it's a lot more helpful to stop early when a field is not correctly configured or the field class has an issue than to still process the other parts of the form and only fail for a value or two. That's why I would really try to only keep this behavior for the props.

[Daandelange]

I also just realised the globally thrown individual field errors in K5 and stumbled upon this issue.

I'm wondering if we can "simply throw" (or return) a Blueprint::fieldError when something goes wrong in my field plugin (in the props or computed stage for example). Either manually or automatically via catch+throw.
I agree the global error message is a pain, particularly when porting k3 to k5 where many fields throw simultaneously : impossible to know where to error comes from.

The "nice" field error message still exists in K5, but can only be triggered by the native blueprint field parsing stage. An easy one to trigger: "Invalid field type qwerty".

What about a final "whole-field post-computed-callback" where the field can replace itself with something else before it's sent to Fiber (ex: a Blueprint::fieldError if it has errors). That way each field can make error handling as complex as they want.