Voting starts in March for the Drupal Association Board election.
What the title says, it dies because it tries to access language config files too early.
I've seen both @webflo and @penyaskito reproduce this at Drupal Dev Days Dublin. We did not get around to submit an issue for this, and did not consider it critical since core base install / testbots are not affected. It is a pretty bad situation nonetheless since you are likely working on language related things when you want to run language tests.
BTW I realize I did not share the reason of this that we discovered back then. It is that the *testing* system attempts to use language_list() via the language URL modifier mechanism to generate the URL to update.php in the upgrade test, even though the site has a Drupal 7 database loaded, and language_list() is already looking for the languages in config (which are not there, and there is not even a config directory, since the initial update.php invocation did not yet happen, so Drupal had no chance to set up the config system basics in the update).
The solution here could be to skip the language URL modifier service when generating the link to update.php, after all there is going to be no language code or special domain for update.php (or should not be at least). We looked at trying to kick out the language modifier service from the URL generators when the update URL is generated, but we could not figure out how to make that work even after getting some expert advice from @katbailey. So some fresh eyes on this would be welcome.
Tagging for upgrade path.
One line broke a huge amount of tests.
// Build a minimal, partially mocked environment for unit tests.
// Make sure it survives kernel rebuilds.
$conf['container_service_providers']['TestServiceProvider'] = 'Drupal\simpletest\TestServiceProvider';
I checked this:
... --class "Drupal\contact\Tests\ContactUpgradePathTest"
Wow, I have no idea if this helps at all with this issue or if this is the right solution :) Would be great to see others confirm/refute.
Hi tested this patch and it seems to clear the exception caused by having the language module enabled.
It now reveals other errors in the tests, but some now pass that failed before the patch.
Sorry, but we need tests that fail without this patch.
Not sure how to prove this, because the bug is if the *TESTING* system has language module enabled, the *TESTED* system fails. So not sure how to make it reproduce inside the *TESTED* system only. You cannot really enable language module that early. @webchick feel free to demote this if you have better ideas :)
I am not sure it worths the pain but you can run simpletest inside the child site... testception :D
Ok, fair enough. Spun off #2097185: Add tests to test SimpleTest with language module enabled on the parent site into a separate issue (major task), because this is definitely not the first nor last time that "leaky language" is going to break our tests.
With that done, this one looks good to go. Great catch! Can't believe the fix is so simple. :)
Committed and pushed to 8.x. Thanks!
I been looking into how to test this issue and it is doable but the main pain is in database setup.
@jpd4nt thanks for trying to test this, let's continue in #2097185: Add tests to test SimpleTest with language module enabled on the parent site and find me in IRC I'd be glad to guide you.
Automatically closed -- issue fixed for 2 weeks with no activity.
Drupal is a registered trademark of Dries Buytaert.