TypeError: implode(): Argument #1 ($pieces) must be of type array, string given in implode() (line 92 of core/modules/update/src/UpdateSettingsForm.php).

Thank you for the patch and for the stack trace.

This seems to be an unusual situation. I don't understand how $notification_emails could be unset at this line because just above this section it is set as:

$notification_emails = $config->get('notification.emails');

I think $notification_emails could be null here, but only if there is something wrong with the site configuration. notification.emails is set to an empty array on install and it is part of the update module schema. What does a var_dump of $notification_emails show?

I think the steps to reproduce need some refinement.

I was having the same issue. Uninstalling and then reinstalling Update Manager fixed it. The site is using Drupal 9.5.8 and PHP 8.1.13.

I am having the same issue.
$notification_emails is NULL.

The patch looks good and makes sense to include it in the core, IMO.
Calling a function that can break the page on unchecked variables is much worse than just adding a normal safety check. Perhaps the missing values come from old installs/configurations and/or migrations when it wasn't necessary. Reinstalling + importing configs will still remove the initially installed empty array when one wants to keep the original settings.

You can also just manually add the missing value in update.settings.yml and import configs to resolve the issue as well, but better safe than sorry?

notification:
  emails: {  }

The suggested patch (explained in Proposed Resolution) worked for me, too. This D9 site on php 7.4 is being run on php 8.1.22 (8.0.0 removed the legacy param order, per changelog on php.net; info thanks to this smart guy)

I found a way to reproduce this which I added to the IS.

Turns out that notification.emails can be saved as string, an array or NULL. And it doesn't validate the email address either.

I wonder if there are duplicates of this.

Is this a problem in D10.2 or D11?

#9 seems @quietone was able to reproduce in 11.x branch.

Still a problem in D10.2, attached patch with 10.2 version compatibility.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Raised MR !6804 of patch #13.

The Needs Review Queue Bot → tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Fixed core commit check issues. Changing status to Need Review.

Will need test coverage since it caused a fatal error.

vidorado → changed the visibility of the branch 3353778-typeerror-implode-argument to hidden.

vidorado → changed the visibility of the branch 11.x to hidden.

I want to clarify that this issue is different from 🐛 Cron tries to send update notification email while no email is set Needs work . This one addresses an error that occurs when update.settings.notification.emails is a string, which violates the config schema. This can happen due to legacy configurations present on some sites. The other issue, however, deals with update.settings.notification.emails being an array but containing only empty string entries.

Regarding this issue, I've replaced isset() with is_array() because it kept failing, and I've also added a regression test—my first one! 😊

Addressed the case where update.settings.notification.emails contained an email as a string, besides the case of an empty string.

Also updated the proposed resolution in the IS.

Left comments on the MR.

I've replied to your comments.

-1 for following that approach then. But will leave in review for others

For what it's worth believe the threads are still valid.

Yes, I agree. We could use another opinion about the "official" and current way of resolving this, since I could have based my code on old and now-not-desirable code.

Still looks like need feedback on the open threads.

Added another small thread.

least we can do is fix the 1 thread for the attribute. Naming methods I can be 50/50 at but the @internal on a test doesn't seem right so leaving that thread open too.,