When a test failed while running on a site with $conf variables in settings.php, I discovered that refreshVariables() loses the $conf variables from settings.php when it resets the $conf array.

Comments

dries’s picture

Status: Needs review » Needs work

Mmm. That looks a bit like a hack. At a minimum needs code comments.

darren oh’s picture

Status: Needs work » Needs review
StatusFileSize
new1017 bytes

Comments included. It's a hack, but rewriting settings.php would be beyond the scope of this issue.

Status: Needs review » Needs work

The last submitted patch failed testing.

fago’s picture

Status: Needs work » Needs review
StatusFileSize
new765 bytes

What about this approach? (see patch)

I think it's much cleaner and seems to work fine. It fixed the somehow related issue #339210: Support HTTP authentication for me.

Status: Needs review » Needs work

The last submitted patch failed testing.

fago’s picture

ok, obviously fixing this isn't so simple, but basically this approach should work.

boombatower’s picture

Status: Needs work » Postponed (maintainer needs more info)

Should we be detecting $conf settings anyway...since test environment should be separate of host? Or am I missing something.

darren oh’s picture

Status: Postponed (maintainer needs more info) » Needs work

Those variables are necessary for accessing the database.

boombatower’s picture

Status: Needs work » Postponed (maintainer needs more info)

This still an issue?

boombatower’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

Please re-open if still and issue and we have new light on this.

mikeryan’s picture

Version: 7.x-dev » 8.x-dev
Status: Closed (won't fix) » Needs work
StatusFileSize
new880 bytes

I've run into this problem myself - attaching a reroll of Darren Oh's patch (fago's patch does not seem to make $conf variables set in settings.php available to test functions). I haven't done a full test run, but the test that failed on Darren's previous submission passes for me now.

My context is testing an Oracle source driver for the Migrate module. Naturally, the test would need to connect to an Oracle database, and the module looks for connection info in $conf['oracle_db'] (I will have it degrade gracefully to a pass() message describing the configuration requirements if $conf['oracle_db'] is not present).

The patch here only partially fixes my problem - it makes $conf['oracle_db'] available to the test itself, but not to my module's install hook (where the test data is loaded into Oracle). I have a strong suspicion that simply including settings.php somewhere before module_enable() is going to break stuff all over the place, and don't really have to time right now to play any further with this. I can work around it by lazy-loading the source data the first time the migration class using it is constructed, which I had considered doing anyway before implementing it in hook_install().

mikeryan’s picture

Status: Needs work » Needs review
sun’s picture

Issue tags: +Testing system
sun’s picture

StatusFileSize
new2.6 KB

Attached patch attempts to add a test (only) for the expected refreshVariables() functionality, which should be committed regardless of the outcome of this issue.

But:

Apparently, setUp() does not include settings.php either.

Status: Needs review » Needs work
Issue tags: -Testing system

The last submitted patch, drupal8.test-refreshvariables.14.patch, failed testing.

wodenx’s picture

Issue summary: View changes

This is definitely still an issue. For me, the problem was running tests on an environment with memcache enabled using different prefixes for different sites. $conf['memcache_key_prefix'], set in settings.php, is lost after the first call to drupalGet(), which resulted in some very difficult to trace cache issues.

Personally, I think Fago's approach is cleaner, and that is what we have adopted (in our own subclass of DrupalWebTestCase).

wodenx’s picture

In case anyone else encounters this - here's what we have in our base test class (class MyBaseTestCase extends DrupalWebTestCase)

protected function refreshVariables() {
    global $conf;
    if (isset($conf)) {
      $old_conf = $conf;
    }
    parent::refreshVariables();
    if (isset($old_conf)) {
      $conf += $old_conf;
    }
  }
pieterdc’s picture

Boombatower, it is still an issue.
Wodenx, that's indeed a workaround but we prefer a fix.
We applied Mikeryan's simpletest_refresh_vars-362373-11.patch to our Drupal 7 distribution.

Sun, thanks for the initial - albeit unfinished - test.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

darren oh’s picture

Issue tags: +fldc19
volkswagenchick’s picture

Issue tags: +midcamp2019
darren oh’s picture

Issue tags: +DrupalWTF

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

Component: simpletest.module » phpunit

Triaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.

This looks like it a Phpunit issue, changing component.

catch’s picture

Status: Needs work » Closed (outdated)
Issue tags: +Bug Smash Initiative

This is no longer an issue - we don't have the same issue of $conf vs. database variables with the new config/state/settings split, and the $conf global is completely gone.