Remote Post Handler using "multipart/form-data"

We have a similar requirement for posting to Consultation Manager, but without the file attachment requirement. I've uploaded a patch to demonstrate that converting to multipart is relatively simply, but I'm not sure the best place to put this logic. It's borrowing directly from \Drupal\Tests\BrowserTestBase::translatePostValues to flatten the $request_data and then simply iterating over it again to convert to multipart.

Example:

[
  'a' => 'b',
  'c' => [
    'd' => 'e',
  ],
  'f' => [
    0 => [
      'g' => 'h',
    ],
    1 => [
      'i' => 'j',
    ],
  ],
];

Is converted to:

[
  0 => [
    'name' => 'a',
    'value' => 'b',
  ],
  1 => [
    'name' => 'c[d]',
    'value' => 'e',
  ],
  2 => [
    'name' => 'f[0][g]',
    'value' => 'h',
  ],
  3 => [
    'name' => 'f[1][i]',
    'value' => 'j',
  ],
];

Needs work for test coverage and guidance on where this can live.

Attaching the patch this time 🤦

Had the wrong key in that patch, new one should be good.

Not sure what the expected format is but for Consultation Manager we needed multi value fields (like checkboxes) to have the same form key without [] rather than an array of values.

Added two MRs and hid the patch. MR !449 is in the original format I attempted as per previous comments and MR !450 is in the format that actually worked for Consultation Manager. Test coverage demonstrates the converted formats.

@mstrelan Thank you for contributing both MRs with test coverage. One side note: I appreciate that you are using KernelTest, which has not been used much in the webform module's test coverage.

It is challenging that a "multipart/form-data" post could/should have two different structures for array values. We are also not addressing how files would be included in a "multipart/form-data" post.

Creating a new handler, which could extend the RemotePost handler, in a dedicated contributed module could be more straightforward to address the "multipart/form-data" post and the Freshdesk.com customer support software.

mstrelan Thank you for contributing both MRs with test coverage. One side note: I appreciate that you are using KernelTest, which has not been used much in the webform module's test coverage.

No problem, I think in hindsight there are some existing functional tests that could be extended but I have backported this from the client project I'm working on and it's primarily to demonstrate what the patch does, assuming if it eventually makes it to webform it would go through some refactoring.

It is challenging that a "multipart/form-data" post could/should have two different structures for array values. We are also not addressing how files would be included in a "multipart/form-data" post.

I'm wondering if one way is more correct than the other but really only have the one use case to go by. I think if there was a general consensus on one or the other then we could proceed, but if not then it's probably not worthwhile. I have completely overlooked files, which I think was the original intent of this issue, sorry for that.

Creating a new handler, which could extend the RemotePost handler, in a dedicated contributed module could be more straightforward to address the "multipart/form-data" post and the Freshdesk.com customer support software.

Exactly, and this is what we have ended up doing as we have other massaging to do in the handler as well. But the biggest challenge with this is that the remotePost method is 80 lines long, so without patching webform we have to duplicate the whole function. It would be easier to extend if this was broken up in to smaller chunks. Having said that there is probably a fair bit that is not applicable for our custom handler and could be removed, such as how to handle the GET method, since we'll only use POST.

Let's not make the change since on Freshdesk.com is requiring this change. Instead you can create a dedicated Freshdesk.com webform handler.