Problem/Motivation
DrupalWebTestCase::prepareEnvironment()
overrides only $GLOBALS['language']
. Other languages ($GLOBALS['language_content']
and $GLOBALS['language_url']
) remain from the current Drupal installation which is not good because they may be used (see example in #4).
Proposed resolution
Override all language types.
Original report:
Project: title 7.x-1.x
Title: Random test fails because of "en/" path prefix
Test from the latest dev (d6f2000) fail randomly on my local installation (Drupal 7.39 + stable versions of required modules). This happens because the "en/" path prefix is sometimes (randomly) added to the path in drupalGet()/drupalPost() calls.
I'm going to fix this, but first I need to know if this happens with drupal.org testbot too.
Comment | File | Size | Author |
---|---|---|---|
#6 | 2579083-6.patch | 2.8 KB | Leksat |
Comments
Comment #2
Leksat CreditAttribution: Leksat at Amazee Labs commentedComment #3
Leksat CreditAttribution: Leksat at Amazee Labs commentedHmm... Test pass here.
Comment #4
Leksat CreditAttribution: Leksat at Amazee Labs commentedI've dug this a bit more. It's not random.
Some tests fail when running them in the Drupal installation which
- have more than one language
- default language uses path prefix
In general, on non-default installation.
Tests fail because
drupalGet()
anddrupalPost()
usesurl()
to process the request path. Theurl()
is executed and, for some reason, the$GLOBALS['language_url']
is the language from the current Drupal installation. And it is used as the default language for the URL rewrite.Callstack:
The piece of code from the
locale_language_url_rewrite_url()
that takes wrong language:http://cgit.drupalcode.org/drupal/tree/includes/locale.inc?h=7.39#n423
So, it's a simpletest issue.
Comment #5
Leksat CreditAttribution: Leksat at Amazee Labs commentedComment #6
Leksat CreditAttribution: Leksat at Amazee Labs commentedComment #7
Leksat CreditAttribution: Leksat at Amazee Labs commentedUpdated issue summary.
Comment #8
Leksat CreditAttribution: Leksat at Amazee Labs commentedComment #9
vasi1186 CreditAttribution: vasi1186 at Amazee Labs commentedThis is totally correct PHP code, but not sure if we should use variable names like '$_', even though they are not used for anything. I also haven't seen this in the core elsewhere. In this case, I would suggest to just rename the variable to '$configurable' or something like this.
Same as before
Same as before.