Numeric content inside square brackets within a node body recognised as a token with a type of int

Use a pull request instead.

The steps appear to require contrib modules. Is this reproducible in core?

@hoffismo can you provide the stack trace of the error you're seeing here?

I'm guessing you've got a hook_tokens somewhere that is using strict types and that's the issue - core isn't strict-typed yet.

We can't make the current change in the MR as it has BC implications.

The correct way to do this would be to check the type of the $type and if it's not a string, then trigger a deprecation error and cast it.

That would allow callers to be notified and updated before the next major.

However, I think the fact its getting called with an integer type might be a mistake - I think the correct fix would likely be in `\Drupal\Core\Utility\Token::doReplace` where it is iterating

foreach ($text_tokens as $type => $tokens) {
      $replacements += $this->generate($type, $tokens, $data, $options, $bubbleable_metadata);
      if (!empty($options['clear'])) {
        $replacements += array_fill_keys($tokens, '');
      }
    }

I think here $type should be checked against valid types.

E.g something like

$info = $this->getInfo();
foreach (array_intersect_key($text_tokens, $info)  as $type => $tokens) {

That should prevent it even being called with `16`

Thanks @hoffismo - I think that probably unblocks you for now too 👍️

This needs to be committed to 11.x (which is main) first and then applied to branches.

Coming here from #3479519: Incorrect type hinting in the smart_trim_tokens function. I think we should be able to use string as a type hint, but the preg_match_all in \Drupal\Core\Utility\Token::scan finds ints and floats too. Should core cast these to string?

Also reported at #3534857: scheduled_transitions_tokens expects string but can receive int, but it seems like it should be fixed in core.