Fatal error: Cannot use Drupal\Component\Utility\Xss as Xss because the name is already in use in /var/lib/drupaltestbot/sites/default/files/checkout/core/modules/views/src/Plugin/views/field/Field.php on line 11
There is a Drupal\views\Plugin\views\field\Xss
, in the same namespace as this class, Drupal\views\Plugin\views\field
which collides with the core utility in Drupal\Component\Utility\Xss
when reflections of both are created durint the test.
Looks like never caught because a php version change
drupal-testing "for qa.d.o there was a pricing spike and we lost most of the php 5.4", looks like new bots where provisioned
Failing test is Drupal\views\Tests\PluginInstanceTest. The bug happens in this test now because apparently the classes are loaded in the reverse order. This also means the bug cannot be reproduced on every environment.
Comment | File | Size | Author |
---|---|---|---|
#8 | xss-field.1.patch | 1.07 KB | larowlan |
Comments
Comment #1
mpdonadioTestBot run this.
Comment #2
larowlanComment #3
larowlanComment #4
larowlanLooks like discovery running differently on latest bot and also simplytest.me
Comment #5
larowlanComment #6
larowlanif fail patch at #4 passes, we're right - discovery is now running in reverse alphabet order
Comment #8
larowlanComment #9
larowlanComment #10
xjmRTBC for #8.
Comment #11
xjm/me is tired
Comment #12
xjmComment #13
xjmComment #14
mpdonadioHiding test files.
Comment #16
webchickI do not understand at all why this patch fixes whatever problem but nevertheless committed and pushed to 8.0.x. Thanks!
Comment #17
xjmOops I guess we never said directly on the issue... There is a
Drupal\views\Plugin\views\field\Xss
, in the same namespace as this class,Drupal\views\Plugin\views\field
. So it collides with the core utility inDrupal\Component\Utility\Xss
. InPluginInstanceTest::testPluginInstances()
, a reflection of each of the plugins of the given type is checked and then an instance is created.So with HEAD locally, the plugins are tested in alphabetical order and all is well:
Applying @larowlan's
array_reverse()
:Then the fatal happens when it gets to
Field
:Line 89 is the creation of the reflection:
So when the
Xss
reflection is created first, it pukes making a reflection ofField
with a different class namedXss
aliased inside it.Apparently some testbot environment change is causing the definition order to change for:
I guess (not sure of this part) with the array manipulation around a closure in
Views::getPluginTypes()
:The use of reflection combined with some PHP weirdness combined with Views' general violation of our class naming policy is what made the "magic" happen here.
Comment #18
xjmFWIW, I think it'd be worth a followup to this hotfix -- since the fatal only happens because of the way the test uses reflection, I think, and we don't know from inside the
Field
plugin why we need to alias core'sXss
utility as the ViewsXss
plugin isn't used there. The autoloader isn't what's causing this.Discussed with @alexpott a bit who suggested:
which might imply that we should change the test instead (or additionally).
Comment #19
xjmFWIW, the reflection scope is not just limited to the function scope. I thought of fixing it like this:
but that still throws the fatal upon creating the
Field
reflection.Comment #20
alexpottSo this is not about reflection... if you rewind to commit
b8364ec
and run the following script with drushYou'll get the following backtrace
You don't even need to use the plugin manager to cause this :)
will produce the same problems... oh PHP.
Comment #21
alexpotthttps://bugs.php.net/bug.php?id=62042 seems related
Comment #22
dawehner... So how did we managed to fix a critical bug without adding a test?
Comment #23
xjm@dawehner, definition of "hotfix". It was late at night and every patch was failing, without HEAD having failed.
https://bugs.php.net/bug.php?id=62042 sounds like exactly the thing.
Comment #24
dawehnerThis is super confusing ... this particular problem exists in core since kinda begin of december afaik.
Comment #25
xjm@dawehner, yeah, thence hotfixing it... as best we can tell it's somehow a side effect of having different testbots.
I started filing a followup issue, but based on this:
This definitely seems like a PHP bug, and not something we could or should anticipate. Code can't know every class that might end up in the same namespace and plan its aliases accordingly, and there's no way of rewriting that test that would avoid the problem. We could rewrite the test itself to not do the reflection check before creating the plugins, to avoid such a failure in the future. We could change our naming and aliasing standards so we don't have such a high risk of name collisions. Or we could do nothing.
Thoughts?
Comment #26
xjmFWIW, this naming policy (which Views violates) would have prevented us from running into the PHP bug:
https://www.drupal.org/node/608152#naming
As would (I think) using things with sub-namespaces, i.e.
use Drupal\Component\Utility\Xss as Utility\Xss;
Comment #28
xjmAnother issue like this today: #2446259: [HEAD BROKEN] Rename \Drupal\Core\Render\Element\Html to avoid namespace clash with \Drupal\Component\Utility\Html in render elements.