Problem/Motivation

If required config values are not set, errors will occur later on and are difficult to trace. For example, if $field_prefix is not set, then:

modules/field_ui/src/Form/FieldStorageAddForm.php
'#maxlength' => FieldStorageConfig::NAME_MAX_LENGTH - strlen($field_prefix),

will fail when NULL to strlen.

Proposed resolution

From comments #11 and #13

>>> \Drupal::config('some_module.non_existent')
=> Drupal\Core\Config\ImmutableConfig {#6251}

Should this throw an exception instead, and we need a separate explicit call to create a new config? This would warn users earlier that expected config is missing.

>>> \Drupal::config('field_ui.settings')->get('non_existent_key')
=> null

Maybe also this should throw an exception, if the config exists but the key does not, instead of falling back to NULL?

Remaining tasks

  1. Agree on an approach. Per #14, the proposed solution would require a deprecation first. But per #15 there are other things to consider.
  2. Write a patch with tests
  3. Review
  4. Commit

User interface changes

N/A

API changes

TBC

Data model changes

TBC

Release notes snippet

TBC

Original report by [username]

I had the case that $field_prefix was not set and therefore I got the issue with passing NULL to strlen.

modules/field_ui/src/Form/FieldStorageAddForm.php
'#maxlength' => FieldStorageConfig::NAME_MAX_LENGTH - strlen($field_prefix),
CommentFileSizeAuthor
#3 3321422-2.patch937 bytesPrem Suthar

Issue fork drupal-3321422

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

unkelhoebbi created an issue. See original summary.

Prem Suthar’s picture

add the patch For when $field_prefix value is empty then set Max length = 0.

Prem Suthar’s picture

Status: Active » Needs review
unkelhoebbi’s picture

@Prem Suthar I've added an issue fork to this issue so we can work with merge requests instead of patches. If you want to use a diff file for your composer you can use https://git.drupalcode.org/project/drupal/-/merge_requests/2952.diff.

cilefen’s picture

Why is $field_prefix unset?

longwave’s picture

Status: Needs review » Reviewed & tested by the community
$field_prefix = $this->config('field_ui.settings')->get('field_prefix');

I am guessing field_ui.settings could be missing entirely on some setups; there is only one config key and there is no UI for this. Defaulting to the empty string as in the MR seems safe enough; not sure this needs a test?

larowlan’s picture

We should be able to rely on the presence of a config object, IE there's no default value for $config->get like there is for e.g the state API

My concern is if we babysit broken setups for config where does it end.

My thoughts is this should be marked a support request and we help the user fix their broken site, e.g create the missing config object

cilefen’s picture

I agree, we've been pushing back on these workarounds.

alexpott’s picture

Status: Reviewed & tested by the community » Needs review

I agree with @larowlan we need to be able to rely on the existence of a module's configuration in a module's code. For me we should close as works as designed.

longwave’s picture

>>> \Drupal::config('some_module.non_existent')
=> Drupal\Core\Config\ImmutableConfig {#6251}

Should this throw an exception instead, and we need a separate explicit call to create a new config? This would warn users earlier that expected config is missing.

unkelhoebbi’s picture

I'd prefer the suggestion of longwave. I needed to debug the code to see what was actually missing. So it would have saved me some time if there was a proper exception.

longwave’s picture

>>> \Drupal::config('field_ui.settings')->get('non_existent_key')
=> null

Maybe also this should throw an exception, if the config exists but the key does not, instead of falling back to NULL?

alexpott’s picture

Status: Needs review » Needs work

@longwave I think that this is a great idea. immutable config being new makes no sense. I think we'd have to trigger a deprecation first and then an exception in the next major version.

We should re-focus the issue on doing that.

alexpott’s picture

Looking at \Drupal\Core\Config\ConfigFactory::doGet() - the one fun thing will be overrides on a non-existing config object. Not 100% sure what we should do in that instance. It's a pretty strange thing to support.

quietone’s picture

@Prem Suthar, making a duplicate patch from an MR does not advance an issue. There are contributor tasks on Drupal.org that provide the steps for making useful additions to an issue. Credit has been removed per How is credit granted for Drupal core issues.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

pameeela’s picture

Title: Passing NULL to strlen » Missing config is not handled early enough
Issue summary: View changes
Issue tags: -PHP 8.1 +Bug Smash Initiative