Deprecated function: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\field_ui\Form\FieldStorageAddForm->buildForm()

I can't reproduce this. This suggests there is something wrong with the field_ui configuration on that site.

This function returned a null on the affected site:

$field_prefix = $this->config('field_ui.settings')->get('field_prefix');

But field_prefix installs as `field_` and is in the configuration schema.

Think we still need exact steps to reproduce. You mentioned field_ui.settings was missing but under what scenario? Think once that's known a test case should be written for it.

This very error occurred after enabling caching of js/css on a D7 site which ran fine since 2017. After changing the PHP used from 8.1.x to 7.4.x, the site is back. I'd consider this serious, as I didn't expect to crash a client site by enabling caching … If you need additional information, feel free to issue your request.

I don’t see a connection between that Drupal 7 error and this issue. Am I missing something?

Well, maybe the type of error and the related version(s) of PHP? Maybe deprecated functions become a problem with newer versions of PHP? I don't know, I just report.

after applying the patch "3344033-4.patch" the site crashed while adding the taxonomy term field and vocabulary, so I updated the patch.

FYI The patch in comment #9 fixes the error message, but the prefix "field_" does not actually prepend the new field name after saving.

Also, the module is getting the prefix value from config in multiple other places, so it NEEDS to be set and not null.

I think the issue to fix is that the config value isn't getting set even though the module contains a default install config value of 'field_'

Is it possible that the default install config is not getting loaded when using `conflig_split` to enable field_ui on local/dev environments?

I just ran into this problem when conflig_split auto-enabled field_ui for me. When trying to add a field to a paragraph entity type, I saw the PHP warning and the prefix was `null`.

After manually (with drush) uninstalling field_ui and re-enabling it, the PHP error was gone and the default `field_` prefix was present again when creating fields.

Yes, that's probably what happened in my case as well.

As @aasarava mentioned, this issue occurs when using config_split with the field_ui set to enable only in the local/dev environment, as configured in the Complete Split section (Complete Split: Configuration listed here will be removed from the sync directory and saved in the split directory instead. Modules will be removed from core.extension when exporting (and added back when importing with the split enabled.)) so the field_ui.settings.yml configuration file is missing, deleted, or removed.

I believe we don't need to apply any patch to fix this issue because we only need to place the field_ui.settings.yml configuration file in the local/dev folder (folder name depends on what you configure in the Config Split module) or add it to git (Remember that we shouldn't place this configuration file in the sync folder because we only want to enable the field_ui in the local/dev environment).

I experienced the same issue after upgrading from 9.5.10 to 9.5.11. I followed the suggestion mentioned by @aasarava #12. Using Drush, uninstalling field_ui and re-enabling it removed the error.

Patch #9 stopped applying at drupal core >10.2 so i updated the patch.

#16 works as expected, by adding the 'field_' prefix instead of returning an empty element the field storage is build up consistently. However, it seems this might have to do with the validation constraints to field_ui.settings ( https://www.drupal.org/project/drupal/issues/3417363 📌 Add validation constraints to field_ui.settings Needs review ), since the field_prefix value defined in field_ui.settings should be the default value.

Re-rolled patch from #16 for Drupal 10.3

I just had it happen on a test project as well, the field_ui.settings config was missing. It shouldn't happen, but it can happen. Might as well deal with it since the fix isn't that complicated anyway, right?

To respond to #3. If this is genuinely a case of "it shouldn't happen" then "might as well deal with it" is not a great approach. If the absence of field_ui.settings config is a condition we want to handle then that may affect the solution. I will try and write a test only MR so that we can agree on the target solution.

Drupal\field_ui\Form\FieldStorageAddForm is in the field_ui module. Therefore, any use of $this->config('field_ui.settings')->get('field_prefix') should be expected to be valid. The config/install and config/schema should be relied upon to set the default of field_ui and to ensure that any change to that matches the schema of string with regex of /^[_a-z]+[_a-z0-9]*$/.

I think given these conditions there is nothing to fix here. If somehow this error is triggered then we need to diagnose and fix the problem not address the symptom.

There is a case where $this->config('field_ui.settings')->get('field_prefix') can be expected to be null in core and that has been handled: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/media...

The above case is justified because field_ui module may not be installed. The same condition is not true with code in the field_ui module.

My strong recommendation is that this issue be "closed (works as designed)".

For those that are experiencing this deprecation warning it is best to create an issue and provide the specific steps to reproduce and we can offer support on ensuring that the field_ui settings are available for you when the field_ui module is installed.