- Issue created by @larowlan
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
π Support server side massage and validation of component prop form values Active landed a while ago, this is unblocked.
- πΊπΈUnited States tedbow Ithaca, NY, USA
In π± Research: Possible backend implementations of auto-save, drafts, and publishing Active one of the reasons we discussed for an having auto-save that was independent entity revisions was to allow having saving incomplete or invalid data.
It seems this would abandon that idea or at least limit to allowing empty slots. Is that right? I think because
\Drupal\experience_builder\Controller\ApiLayoutController::buildPreviewRenderable
already calls\Drupal\experience_builder\ClientDataToEntityConverter::convert()
the "page data" information would already be validated and we can't now store incomplete or invalid Page data values in auto-save.While looking into this I found π XB allows saving invalid date range field values Active , but I think this because date range validation for this only happens in the field widget
- π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
we get an error when adding a component with an empty slot (this is reinforced by \Drupal\Tests\experience_builder\Kernel\ApiLayoutControllerPostTest::testMissingSlot
I happen to have worked on a related bug today: π Empty slot placeholder not rendering for content that has been published Active .
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
This has implications for π Page status changes from "Published" to "Changed" even when no actual changes are made Active which I'm working on at the moment.
I have all the phpunit tests passing but are failing e2e on changes we made in π Publish checks validation constraints, but not form validation ActiveDo we think we should postpone π Page status changes from "Published" to "Changed" even when no actual changes are made Active on this? Or bundle this into that one?
Or add another workaround and reference it back here like the existing code does?The specific issue in π Page status changes from "Published" to "Changed" even when no actual changes are made Active relates to form validation errors only (not layout/model/entity violation errors)
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Went with option 3 - add additional temporary code with a todo to remove it in this issue.
- π¦πΊAustralia larowlan π¦πΊπ.au GMT+10
Thinking about this some more and I really think these need to be shown inline in the form, it feels like bad UX to accept a form submission (entity form) and store it in auto-save and then at some future state prevent publishing.
We already have a form-state slice with errors, it would be a matter of returning them from the BE and putting them into the slice, keyed by the name attribute on each
<input name="">
(or select, textarea))