Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

anchor summary error to field for nested matrix "blocks" #15811

Open
wants to merge 4 commits into
base: 5.x
Choose a base branch
from

Conversation

i-just
Copy link
Contributor

@i-just i-just commented Sep 30, 2024

Description

For a matrix in a matrix where the view mode is set to inline-editable blocks, we need to continue to rewrite the errors all the way up to the element that contains the first inline matrix field. However, when adding a prefix to errors in the summary, we need to ensure only the immediate owner prefix is added. That way, we’re able to reliably anchor from the error summary to the affected field.

Related issues

#15797

@brandonkelly
Copy link
Member

It’s expected that recursively-nested fields will get error attribute prefixes that reveal the full path to the element.

For example, locally I have a required Entries field that is nested in two parent Matrix entries, and when I save it without a value, the top-level entry gets an error with the following key:

navigation[fe6c1060-e895-4a44-9e15-b0341e6a58f8].elements[7872abb1-22ae-4523-9dde-95b51b239ac8].entry
  • navigation is the first Matrix field
  • fe6c1060-e895-4a44-9e15-b0341e6a58f8 is the navigation Matrix field’s entry UUID
  • elements is the nested Matrix field
  • 7872abb1-22ae-4523-9dde-95b51b239ac8 is the elements Matrix field’s entry UUID
  • entry is the required Entries field

With this PR, the error’s key is only:

elements[7872abb1-22ae-4523-9dde-95b51b239ac8].entry

Which leaves out critical information, as the top-level entry doesn’t know anything about an elements field.

@i-just
Copy link
Contributor Author

i-just commented Oct 8, 2024

Thanks for the chat on this one, @brandonkelly! I reverted the previous change and used a different approach.

Comment on lines +1069 to +1070
$layoutElement->getField() instanceof Matrix &&
$layoutElement->getField()->viewMode === Matrix::VIEW_MODE_BLOCKS
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@i-just Do you think it would be save to skip this check, so the same thing works for Neo? If it’s a Matrix field in cards/index view, then there won’t be any inputs to match for the error anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tested that, and it won’t affect Neo.

Neo still uses block indexes when prefixing model errors (switching to $block->uid makes the prefix look as expected).
They’re also not using errorKeyPrefix when rendering the blocks form, which means the error key is set to just the handle of the individual field (e.g. myPlainTextField). Passing {'errorKeyPrefix' : "#{handle}[#{block.uid}]"} as the 3rd param prefixes the errors as expected.

With those two changes in place, anchoring to erroring fields inside Neo works as expected, and the lines you mentioned don’t affect that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants