Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
The following settings were deprecated in Drupal 9 for removal in Drupal 10:
- sanitize_input_whitelist
- twig_sandbox_whitelisted_classes
- twig_sandbox_whitelisted_methods
- twig_sandbox_whitelisted_prefixes
Steps to reproduce
Proposed resolution
Remove all references to them.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#2 | 3269149-2.patch | 4.09 KB | longwave |
|
Comments
Comment #2
longwaveComment #4
longwaveUnrelated fail in a JS test.
Comment #5
catchLooks great and nice to see deprecatedSettings empty after this lands.
Comment #6
alexpottGiven this is private - imo we should remove it entirely. Less code runs on every Settings::get()
Comment #7
catch@alexpott don't we need to leave it in for the next setting that gets deprecated?
Comment #8
alexpottWe can add it back if and when we do. It's all private therefore there's no harm in removing or adding back. Maintaining an empty private static seems unnecessary.
Comment #9
catchYeah I'm not sure, we added an API (albeit tiny) and test coverage for deprecated settings. How do we avoid having to do all the same work again next time someone wants to deprecate one? Could we short circuit the logic and skip the test instead?
Here's the relevant code not in the patch we'd be removing:
Comment #10
catchCross-linking #3261245: Remove deprecated views module functions where we have an extremely similar issue.
Comment #11
alexpott@catch or is an API based around a private static something we should be testing?
Comment #12
catchWell that's a good question, if we can agree we won't spend three weeks and ~50 comments re-implementing the same test coverage again, then it would be OK to remove, but I don't want to be doing that every time we add and then remove it again.
Comment #13
andypostComment #14
daffie CreditAttribution: daffie commented+1 For keeping the empty deprecation tests.
Back to RTBC.
Comment #15
alexpottLet's discuss the removal of the pointless empty static and related functionality and test in a separate issue. There's no need for that discussion to delay the deprecation removal any longer. (As much as
private static $deprecatedSettings = [];
makes me shake my head)Committed 0be587c and pushed to 10.0.x. Thanks!