What the title says, it dies because it tries to access language config files too early.
Comment | File | Size | Author |
---|---|---|---|
#6 | upgrade_path-failed_tests-2032033-6.patch | 721 bytes | victor-shelepen |
What the title says, it dies because it tries to access language config files too early.
Comment | File | Size | Author |
---|---|---|---|
#6 | upgrade_path-failed_tests-2032033-6.patch | 721 bytes | victor-shelepen |
Comments
Comment #1
penyaskitoTags.
Comment #2
Gábor HojtsyI'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.
Comment #3
Gábor HojtsyBTW 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.
Comment #4
Gábor HojtsyTagging for upgrade path.
Comment #5
victor-shelepen CreditAttribution: victor-shelepen commentedOne line broke a huge amount of tests.
Comment #6
victor-shelepen CreditAttribution: victor-shelepen commentedI checked this:
It works.
Comment #7
Gábor HojtsyWow, 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.
Comment #8
chx CreditAttribution: chx commentedComment #9
jpd4nt CreditAttribution: jpd4nt commentedHi 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.
Comment #10
webchickSorry, but we need tests that fail without this patch.
Comment #11
Gábor HojtsyNot 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 :)
Comment #12
chx CreditAttribution: chx commentedI am not sure it worths the pain but you can run simpletest inside the child site... testception :D
Comment #13
webchickOk, 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!
Comment #14
jpd4nt CreditAttribution: jpd4nt commentedHi.
I been looking into how to test this issue and it is doable but the main pain is in database setup.
Comment #15
chx CreditAttribution: chx commented@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.
Comment #16
Gábor HojtsyThanks all!