Switch from deprecation notice to warning for non-standard placeholders in FormattableMarkup::placeholderFormat()

Created on 28 September 2016, almost 8 years ago
Updated 12 March 2023, over 1 year ago

Problem/Motivation

See #2807705: FormattableMarkup::placeholderFormat() can result in unsafe replacements β†’ . We've supported placeholders that don't start with @, !, % or : forever (! was removed in Drupal 8). We no longer support them.

In Drupal 8 we trigger 2 different errors.

  • If the placeholder starts with a non alphanumeric error then we trigger a E_USER_ERROR.
  • If the placeholder start with an alphanumeric character AND is in contained in the string then we trigger a E_USER_DEPRECATED.

Proposed resolution

  • Trigger a silenced E_USER_DEPRECATION if the placeholder is not in the string and starts with an alphanumeric character. This situation was not accounted for in Drupal 8 so we need to follow our deprecation policy.
  • For all other occurrences of non standard placeholders trigger a E_USER_WARNING on all non standard placeholders passed to \Drupal\Component\Render\FormattableMarkup::placeholderFormat(). E_USER_WARNING is chosen because we do not do the replacement and therefore there are no risks in continuing on. This is slightly less strict than the current behaviour of issuing an E_USER_ERROR but this is a better experience for real sites. The error will be logged but the site will continue to work. This is unlikely to be a critical error.

Remaining tasks

User interface changes

None

API changes

None - non standard placeholders have not been supported since 8.2.0 - #2807705: FormattableMarkup::placeholderFormat() can result in unsafe replacements β†’

Data model changes

None

πŸ“Œ Task
Status

Fixed

Version

9.1

Component
BaseΒ  β†’

Last updated about 8 hours ago

Created by

πŸ‡¬πŸ‡§United Kingdom alexpott πŸ‡ͺπŸ‡ΊπŸŒ

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.69.0 2024