backdrop-issues
backdrop-issues copied to clipboard
backdrop
Undefined constant "LOG_LOCAL0" in system_update_1017()
Description of the bug
On Windows, when doing a Drupal to Backdrop upgrade, I get this error. The line mentioned is $config->set('log_facility', update_variable_get('syslog_facility', LOG_LOCAL0));
LOG_LOCAL0 is not defined in Windows. In D7, in the place the syslog_facility variable is accessed, there is a check for if its defined. We missed this in Backdrop.
Steps To Reproduce
Uncertain; I get the error on WampServer on Windows 11. I dont think I have always had this error, so not sure if something about my current setup may be to blame.
In either case, we should fix this.
@docwilmot unfortunately I'm not much of a help here - have no Windows install available. :shrug: (Not sorry :wink:)
But I'd like to suggest to simply set log_facility to an empty string. In "normal" Backdrop installs it's an empty string, in the D7 installs I checked, syslog_facility isn't set at all (variable doesn't exist).
I belief, it's a bug that this gets set to LOG_LOCAL0 in system_update_1017 (as fallback), and also shouldn't get set to LOG_USER. Or am I missing something?
@indigoxela I think an empty string is the correct thing, in fact. Thanks, will change.
I checked the default value for log_facility in the system.core.json file. Effectively, it is an empty string.
It makes sense to use an empty string as default value also when migrating from a Drupal 7 site.
Thanks @docwilmot, @indigoxela, and @kiamlaluno! This is a good fix. Avoiding constants when in update hooks is a good idea anyway, since often .module files are not loaded that may be needed for defining the constant. And like @kiamlaluno pointed out, it needs to be an actual value (even if it's an empty string) when it's written to config anyway.
I merged https://github.com/backdrop/backdrop/pull/4681 into 1.x and 1.27.x. Thanks folks!
I'm not 100% onboard with this change here. It is OK as a temporary quick workaround (to stop errors during D7 to Backdrop updates), but not ideal. I have filed #6477 as a follow up to clean things up and fix this in a more appropriate manner.
