Closed (fixed)
Project:
Drupal core
Version:
9.4.x-dev
Component:
user.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
4 Nov 2021 at 14:49 UTC
Updated:
22 Mar 2022 at 13:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
danflanagan8Here's a patch that updates 6 of the 7 test classes in user.module that directly refer to classy.
The seventh reference to classy, however, is in a class (
UserTranslationUITest) that extendsDrupal\Tests\content_translation\Functional\ContentTranslationUITestBase. Simply changing the default theme in the user test results in failures since the base class is still expecting classy's markup.Comment #3
danflanagan8unassigning...
Comment #4
danflanagan8I just found something I missed in this patch. InUserAccountLinksTestthere's a NEGATIVE assertion relying on classy:There are also some negative assertions in UserAdminTest that I need to fix. for example:$this->assertSession()->elementNotExists('xpath', static::getLinkSelectorForUser($user_a));because the that staic function returns this:
return '//td[contains(@class, "views-field-name")]/a[text()="' . $user->getAccountName() . '"]';That xpath needs classy.Apparently, I had checked out the wrong git branch. I fixed the first thing above already in the first patch. And this static function is fine. There are positive assertions that use it too.
I searched the user tests for negative assertions and didn't actually find anything that I missed that would be affected by moving from classy to stark. I searched for:
assertEmptyassertCount(0NotExistsAnd didn't see anything that looked like a negative assertion that would break when moving to stark.
I also search for
xpathandcssand I don't see anything left that looks like it needs classy. So I'm feeling good about this patch again. Setting back to NR.Comment #5
danflanagan8I made a new issue for translation UI tests here: #3247901: ContentTranslationUITestBase should not rely on Classy
I think it makes sense to handle
UserTranslationUITestthere.Comment #7
mglamanI have just one concern about the usage of RDF data in the CSS selectors. It might not be a big deal, but it does put a dependency on RDF module manipulations versus what's provided "out of the box" by the module.
This requires the RDF module, correct? I know the
standardinstall includes RDF, so it's usable. My concern is just depending on RDF output in the User module.Comment #8
danflanagan8Good call, @mglaman. Definitely don't want to depend on rdf.
There's serious talk about removing rdf from core: #2152459: [Policy] Deprecate RDF module and move it to contrib
I'm going to set back to NW to find a better way to select.
Comment #9
danflanagan8Here's a new patch with better selectors that don't depend on rdf.
Comment #11
danflanagan8I'm setting this back to NR. Patch in #9 is green.
Comment #12
mglamanChange to drop RDF selectors looks great, thanks @danflanagan8. Going to mark it ready.
Comment #15
lauriiiCommitted d471b0c and pushed to 10.0.x. Also cherry-picked to 9.4.x. Thanks!