The order of handlers is not respected, if the handlers hook into different "submit" steps/functions.
Not sure how to properly explain this, but I will try. (cannot share webform config since it contains a lot of custom/proprietary work)

I have a webform with 5 handlers; listing them in order here:
1. Custom handler to create a Drupal user account
2. Custom handler to create "a payment node" and redirect to external payment provider
3. Custom handler to create invoice data on external financial API and set references to this data on the payment node
4. Custom handler to send data to external CRM API and set data on the created user
5. Default mail handler to admin
6. Default mail handler to client

I expected 1-4 to be fired before 5 and 6. But in reality 5 and 6 fire first, then 1-4.
This was very confusing to me...
It has to do with the function used in the handler to actually do the stuff it needs to do.

All my custom handlers work on the confirmForm() function.

I tried submitForm(), but this is a no-go since I'm storing and updating entities. That messes up the storing of the webform_submission.
I altered the default mail handler, removed sending of the mail in postSave() and moved it to a confirmForm() function and now all handlers fire in the expected order.

So I can work around the issue, but I still find it very strange that the order/weight of handlers are not respected in code.
Is this intended behaviour? To me it feels like a bug...
Or am I simply using the wrong function in my custom handlers?

Comments

weseze created an issue. See original summary.

jrockowitz’s picture

Status: Active » Closed (works as designed)

The EmailWebformHandler first on entity hooks

\Drupal\webform\Plugin\WebformHandler\EmailWebformHandler::postSave which is triggered before the \Drupal\webform\Plugin\WebformHandlerInterface::confirmForm

weseze’s picture

I understand the technical explanation.
However, it is extremely confusing for non-technical persons. They sort their handlers and expect them to be executed in that order...

Perhaps a feature request to group them?

jrockowitz’s picture

I don't have the capacity to refactor the code to support the grouping of handlers.