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
Hmmm, from D7 ancient tomes: from https://drupal.stackexchange.com/questions/7056/limit-which-roles-can-view-a-node-basing-on-its-content-type yet https://docs.backdropcms.org/api/...
node access
I also note on this screen: "Furthermore note that content which is not published is treated in a different way by Backdrop: it can be viewed only by its author or users with the...
node access
I am seeing via dpm debug that the nodes that are authored by someone else are not even being interrogated at the view level; they are simply avoiding the hook_node_access call. Yet the...
node access