The following PHP error is presented every time the add field form is visited:
Deprecated function: strlen(): Passing null to parameter #1 ($string) of type string is deprecated in Drupal\field_ui\Form\FieldStorageAddForm->buildForm() (line 195 of /core/modules/field_ui/src/Form/FieldStorageAddForm.php)
Since PHP 8.1, the function strlen() doesn't allow a null parameter.
Visit the add field form for any content type, for example a Basic page: /admin/structure/types/manage/basic_page/fields/add-field
You will see the PHP error if you have enabled error debugging. Otherwise you can see it in Recent log messages page: /admin/reports/dblog
Check if the variable is null before using the strlen() function. Attached a patch.
N/A
N/A
N/A
N/A
N/A
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3344033-18.patch | 749 bytes | rm-rf |
| #16 | 3344033-16.patch | 776 bytes | bram.velthoven |
| #9 | 3344033-9.patch | 711 bytes | shrouk_mostafa |
| #4 | 3344033-4.patch | 705 bytes | dieterholvoet |
Comments
Comment #2
cilefen commentedI 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.
Comment #3
dieterholvoet commentedI just had it happen on a test project as well, the
field_ui.settingsconfig 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?Comment #4
dieterholvoet commentedMade the patch a bit simpler.
Comment #5
smustgrave commentedThink 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.
Comment #6
nofue commentedThis 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 from WSOD land, but however, it seems there's a dependency on PHP 8.x still, as with 7.4.x enabled, I get all sorts of errors.
If you need additional information, feel free to issue your request.
Comment #7
cilefen commentedI don’t see a connection between that Drupal 7 error and this issue. Am I missing something?
Comment #8
nofue commentedWell, 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.
Comment #9
shrouk_mostafa commentedafter applying the patch "3344033-4.patch" the site crashed while adding the taxonomy term field and vocabulary, so I updated the patch.
Comment #11
jascote commentedFYI 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_'
Comment #12
aasarava commentedIs 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 (on D9.5). 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.
Comment #13
dieterholvoet commentedYes, that's probably what happened in my case as well.
Comment #14
phannphong commentedAs @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).
Comment #15
patrickmichael commentedI 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.
Comment #16
bram.velthoven commentedPatch #9 stopped applying at drupal core >10.2 so i updated the patch.
Comment #17
gselderslaghs commented#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), since the field_prefix value defined in field_ui.settings should be the default value.
Comment #18
rm-rf commentedRe-rolled patch from #16 for Drupal 10.3
Comment #19
nlisgo commentedTo 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.
Comment #20
nlisgo commentedDrupal\field_ui\Form\FieldStorageAddFormis 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.
Comment #21
smustgrave commented