TypeError: implode(): Argument #1 ($pieces) must be of type array, string given in implode() (line 44 of modules/contrib/perimeter/src/Form/PerimeterSettingsForm.php).

I added 3 tests for the form. The third test fails without the patch.
The third test covers having null as a value for the patterns, and having the entire configuration object missing. There is another use case that we could test, which is when the pattern value is a single string. I can save that using drush vendor/bin/drush cset perimeter.settings not_found_exception_patterns "test" and it breaks the site. However, I could not replicate it in a test because of schema validation.

The error described can only happen if the user forgot to run "drush updb" after updating the module recently. As this config can not be NULL otherwise. We establish the default values of "not_found_exception_patterns" through our "perimeter.settings.yml" AND have an update hook in place for older versions, where "not_found_exception_patterns" might've been empty.

Meaning this behaviour can only happen, when tinkering with config manually.

Furthermore, I don't really like the default value fallback provided, I'd be fine with an empty string. The tests shouldn't be necessary, but could be merged. What do you think about this @Anybody? I am against merging this and would simply close this issue.

This is the schema:

perimeter.settings:
  type: config_object
  label: 'Perimeter Settings'
  mapping:
    not_found_exception_patterns:
      type: sequence
      label: 'A list of regex patterns'
      sequence:
        type: string
        label: 'A regex pattern'
    whitelisted_ips:
      type: sequence
      label: 'A list of IPs that are always allowed'
      sequence:
        type: string
        label: 'An IP address'

And it clearly defines that not_found_exception_patterns is a sequence / array. So we shouldn't try to handle schema errors on the user side, this would have no end.

I agree with @Grevil, it's the job of the module to define the expected schema, but not to handle a wrong one.
The tests should of course please be added, if they test cases that were untested before.

@Grevil for the testNonStandardConfig test I'm not sure if we should have that one, due to the reasons above, but perhaps Drupal is even so clever to return an empty array now with the schema defined, if there is no value given?

@Anybody, the "testNonStandardConfig" deletes the entire perimeter config and then accesses the page. Meaning, the error will throw 100%.

Furthermore, the first test will also throw an error, since the permissions have changed. But yea, I agree, if the first test gets modified, to test both new permissions and the third removed, I'd be fine to merge this. But not in this issue, we should create a separate issue for that.

Just ran into the same issue and can confirm it's gone after updating to the latest version and running drush updb.
So this can be seen as outdated, I think.

Update hook: perimeter 8202