Module breaks webform rest elements endpoint

Added a basic fix for the problem.

Hey @yobottehg,

are you sure that this is the casue? I tried it with the default contact form provided by webforms and everything worked fine with webform_rest module, see:

Have you updated to the last version? We had a performance issue in the first version which has been fixed https://www.drupal.org/project/gin_everywhere/issues/3424026 🐛 Performance with getRouteCollection / XDebug Fixed

Hey @hydra,

I just uninstalled module by module until it worked and the gin_everywhere module was the cause.

I then step debugged through the code to see that this caused an infinite loop and the provided patch made the endpoint work again.

Let me try to get a minimum reproducible example.

Okay i got the minim steps to reproduce:

drupal/core: 10.2.4
drupal/webform_rest: 4.1.0
drupal/gin_everywhere: 1.1.0
drupal/gin

Use gin as admin and as frontend theme!

We have a decoupled Drupal instance without a frontend and with using gin as frontend theme the endpoint breaks without the patch.

Ok, so setting gin as a frontend theme might cause this. Will have another look into this. Thx for the research!

I added a more appropriate check which also solves the problem.

Thx! This looks much more reasonable to me than before. But I think it's a vaild use case to use gin as a frontend theme as well and also in combination with forms. I would prefer a way which would allow for that.

It seems to be an issue with using t() - don't know why this is not working properly.

I think what we could do is check if the request format is html, which should always be the case when altering forms but in this case... its json or xml I guess. Not sure whats the right way :/ It does not feel like the right solution yet.

  // Make sure we are on a html request.
  // @see See https://www.drupal.org/project/gin_everywhere/issues/3432341
  if (\Drupal::request()->getRequestFormat() != 'html') {
    return;
  }

@yobottehg I could not sleep and dived a bit deeper into the problem and found out, that the webform submission is implementing the EntityOwnerInterface interface without providing an owner key on the entity type. This results in wrong from alterations from gin_everywhere. Can you have a look at my MR to check if this helps with your issue?

@Hydra I can confirm that this also solves the problem.

Looks like we should create an issue on webform or perhaps use the interface method instead of the array key ? https://api.drupal.org/api/drupal/core%21modules%21user%21src%21EntityOw...

Yeah we are checking for the EntityOwnerInterface in gin_everywhere. I am willing to commit the additional check since it does not harm anything and helps addressing your issue. Feel free opening an issue on webforms issue queue for that :)

Hydra → closed merge request !5

Automatically closed - issue fixed for 2 weeks with no activity.