AKA: Status page warning not relevant when secure cookie set in another file included into settings.php

We're running an Aegir setup (Barracuda) and under that system the settings file cannot contain the required code due to the way the hosting platform operates. However, a file is included in the foot of settings.php, and in the included file is the exact code I'm being warned I need in the settings file.

So the session443_requirements() function assumes 'normal' Drupal settings file, and the regexp fails since it's looking in the wrong place given the architecture of the platform.

What would be great is checkbox that we can set in the admin screen so we don't have to see that warning, would a patch along those lines be of interest?

Comments

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented

I don't think I'd accept an exposed config option. But I would accept a patch that just used something like:

function session443_requirements($phase) { 
  if (!variable_get('session443_show_requirement_errors', TRUE)) {
     return;
   }
  // ...
jim kirkpatrick’s picture

jim kirkpatrick commented

I reckon a variable is a waste of database bandwidth -- how about a $conf entry? 'session443_hide_requirement_errors'? E.g. 

function session443_requirements($phase) { 
  if (isset($conf['session443_hide_requirement_errors']) && $conf['session443_hide_requirement_errors'] == TRUE)) {
     return;
   }

That way we don't muck around with the DB, and people having the same settings.php issue as us can include the $conf override in their
appropriate included file.

If this suits I can make a patch along these lines if you want...?

jim kirkpatrick’s picture

jim kirkpatrick commented

bumppedy

dalin’s picture

dalin
he/him
Primary language English
Location 🇨🇦, 🇲🇽, 🌍
commented

Take a deeper look into Drupal's variable system. $conf and variables are the same thing (though you'd need a global $conf; to make your code work). Though if you just use $conf you wouldn't be able to alternatively set it in the DB.

If you can write a patch that uses variable_get() we can commit it.