Create an endpoint to publish all auto-saved entities

@tedbow just discovered most delicious can of worms 🤣

What if one content entity was modified by Ted, another by Wim, and they have different permissions granted? What if Ted is unable to edit what Wim was able to edit and vice versa? Who is then actually authorized to publish those accumulated changes in tempstore?

How does the workspaces module handle this?

Whatever XB does here MUST match however Workspaces handles it.

Let's not derail this issue with that problem and create a follow-up issue to investigate how Workspaces handles it, to determine if keeping things simple here creates more work for when XB adopts Workspaces entirely.

This now blocks #3488368 per #3488368-14: [PP-1] Also convert metadata (page data) fields → .

I've expanded the tests here and also improved the error response to include meta about the entity type and ID that the issue exists in, which I think (based on the designs) the FE will need.

I will see if we can easily include the component ID in the meta too, although I suspect that will need something that extends ConstraintViolation to add the additional data - so that's likely into follow-up territory

I will see if we can easily include the component ID in the meta too, although I suspect that will need something that extends ConstraintViolation to add the additional data - so that's likely into follow-up territory

🤦 this is already in the source.pointer output 😎

The CI fail is coming from \Drupal\Core\Template\ComponentsTwigExtension::doValidateProps which indicates we have an issue with XBPreviewRenderer when there's an invalid entry in the auto-save storage

We will want these items to render without validation I suspect, or rather without taking out the whole page.

Added an extension to ComponentValidator with a method to opt-out of validation during preview

I'm surprised by the changes in ApiPreviewController: based on the issue title + summary I didn't expect those in this MR.

@larowlan articulated why this is necessary in #8 + #9: because CI was failing without those changes. Okay! 👍

But … I'm concerned about disabling SDC's validator, because AFAICT it can result in SDCs failing to render, triggering PHP errors. That would make 📌 Improve server-side error handling Active critical based on @lauriii's statements in that issue.

Assigning back to @wim leers , re #10 I think this is unrelated issue and pushed up a change that removes a need for the changes to `XBPreviewRenderer`

I think the rest of @wim leers comments on the MR are about changes to the files that are no longer needed

Got a +1 from @larowlan on Slack that this is ready to merge.

@larowlan and @lauriii thanks for finishing this off!

One thing, I noticed is that we have todo to remove ApiContentUpdateForDemoController which also means in that issue we will probably also remove ApiContentUpdateForDemoControllerTest.

The problem is that ApiContentUpdateForDemoControllerTest covers a lot of the logic that is now in ClientDataToEntityConverter. We have the new ApiPublishAllControllerTest but that doesn't cover all the cases we cover in <code>ApiContentUpdateForDemoControllerTest

for instance the logic around creating 'pointer' => "layout.children[1]", but I am pretty sure there is more.

so we can't just remove ApiContentUpdateForDemoControllerTest when we remove ApiContentUpdateForDemoController or we lose our indirect test coverage for ClientDataToEntityConverter.

So we should probably make a follow-up to create ClientDataToEntityConverterTest and move most of the error test cases from ApiContentUpdateForDemoControllerTest into that leaving ApiContentUpdateForDemoControllerTest to be just a small test to cover the logic in the controller that can be removed when we remove the controller.

@traviscarden also made a follow-up 🐛 Add missing response to `/xb/api/publish-all` in `openapi.yml` Active

That follow up could perhaps be https://www.drupal.org/project/experience_builder/issues/3489772 📌 Add a param converter and DTO for XB data model Active

@larowlan

🧐 We can be explicit here (PNX coding standard has banned the use of empty and isset for some time so this is jarring for me, but feel free to ignore).

Feel free to open an issue to enforce this on this project too, using PHPStan presumably? 🤓

@tedbow: Superb simplification of this issue, along with a thorough explanation — well done! 👏🤩

Per

After 0.2.0, we'll work on Workspaces integration. The requirements and approach for that are being discussed in 🌱 Research: Possible backend implementations of auto-save, drafts, and publishing Active

— point 1 in 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active .

Workspaces support is for post-0.2, and the issue for it is #3475672.

So, untagging.