This errors are logged when running a D7 to D8 migration:

Source ID mail_system: No static mapping found for 'NULL' and no default value provided for destination 'interface/default'.
Source ID minimum_word_size: No static mapping found for 'array( NULL, )' and no default value provided for destination 'default_page'.
Source ID allow_insecure_uploads: No static mapping found for 'NULL' and no default value provided for destination 'allow_insecure_uploads'.

Comments

hass created an issue. See original summary.

hass’s picture

hass commented
Title: No static mapping found for 'NULL' and no default value provided for destination 'interface/default' » No static mapping found for 'NULL' and no default value provided for destination
Issue summary: View changes
hass’s picture

hass commented
Issue summary: View changes
bart atlas’s picture

bart atlas commented

I think all 3 can be safely ignored.

You can query the D8 database to confirm whether a valid value has been set for each of these, for example:
SELECT name, CONVERT(data USING utf8) as d FROM config where data like '%insecure%';

The middle error (default_page) is caused by the core search module being enabled but search settings not having been saved in D7. On a test of vanilla D7 migration to D8 I found that navigating in the D7 UI to the search settings and saving will result in writing default_page and other search variables, and prevent this error from being thrown.

quietone’s picture

quietone commented
Status: Active » Closed (works as designed)

Having a NULL as input to the static_map is not necessarily an error.

In fact, as bart atlas, points out one is due to search settings not being saved in the source site.

And I tracked the other two messages to :
The interface/default is from d7_system_mail migration. The 'mail_system' variable is not set in the source db.
The allow_insecure_upload from d7_system_file. The 'allow_insecure_uploads' variable is not set in the source db.

So, it is the source database that does not have a setting and the migration makes no assumption about what the value should be, The migration will not overwrite any Drupal 8/9 default for those values, which I think is the safest option.