This is basically the equivalent of https://www.drupal.org/project/drupal/issues/3163226 (as well as a sibling issue to #5741) which was introduced in D 9.1.x (Change record: Core settings keys can be deprecated)
If the
settings.php
file for a site (or any file it includes) contains the legacy setting name, the deprecation warning will be generated. If code callsSettings::get('new_setting')
but'new_setting'
is not yet defined, the value of'old_setting'
will be returned.If any code calls
Settings::get()
with the legacy name, the deprecation warning will also be generated. If the replacement setting is already defined, the value returned bySettings::get('old_setting')
will be the value ofnew_setting
.
This would help us with issues similar to #4451 as well, and possibly allow us to deprecate things in the Backdrop 1.x release cycle instead of having to wait for 2.x.
Recent comments
Hi Sudipto, this error usually means CiviCRM isn’t initializing properly before a dependent module (like CiviMember Roles Sync) tries to call its functions. After upgrading, verify that the...
Facing an error after upgrading Civicrm version from 5.78.3 to 6.5.0
Hi Martin, it sounds like you’ve set things up correctly, but a couple of common issues might be preventing the file from showing. First, ensure the Ubercart File Downloads module is fully...
Ubercart and downloadable file product
It sounds like a small UI rendering or CSS conflict. The leftover description help block likely isn’t being hidden when the “Add block” row is set to display:none. Check if the help block has...
Add blocks filtering problem