#nightwatch

#8 I notice that core.entity_view_display.node.article.default.yml version in Nightwatch profile contains core.entity_view_display.node.article.default.yml
But it is not contained in the same file in standard profile. Havent looked at the umami version of the file yet.

#8 Yes I was confused. I thought it was a configuration profile for Nightwatch itself. But I suppose umami could be useful at some point. The article edit url seems fine especially since there is an existing url for the 'Page' node type that uses the same query param.

Wondering if trying without the query param (I read something about the query param being required to POST the form?) which i think would just load the form? To try to isolate the cause: is it the query param in the url? I think the issue is currently isolated to the article edit url being added to the test. If we can isolate it to the query param that would be slight progress?

It is just the standard installation profile, so it sets the site up as everyone else sets it up. Wasn't aware that other tests don't use that, but I suspect that without doing that we won't check the accessibility of many tools included by default.
If I can get this running, it may be worth setting up umami_demo as well.
Basically it should just run the installer using the profile at:
/profiles/standard

@the_g_bomb Grepping the core codebase I notice there are not apparently any existing usages of the 'standard' Nightwatch profile showing up. What is the 'standard' profile? Is that a configuration that has been standardised for Drupal? Or is it the default configuration profile that Nighwatch itself provides whether Nighwatch is being used on Drupal, Wordpress etc?

The failing test looks to the related to image resizing and maybe related to:
https://www.drupal.org/project/drupal/issues/3484845 🐛 [random test failure] ImageUrlProviderTest::testResize Active

Oops now I see why it was done that way. Reverted

Made a small tweak to keep things uniform in the file. Seems good though.

Suggest first step is to use 'standard' install profile rather than the limited 'nightwatch_a11y_testing', even if we have to skip tests until the issues are fixed.

@smustgrave, it is curious as the test failure is now somewhere else, that seems unrelated to the changes. I am wondering if the fact that the test is now testing the correct bit, the issue is that there are problems with the article.

Looks like responsive images, if I am reading the failures correctly. I wonder if the limited profile that is enabled for the a11y tests doesn't have enough tools to do the job of setting up the article node as required.

There will also need to be follow up tickets to fix all the failures that led to the need for the disabled tests and the limited profile, so we can get to a place where everything passes and the full standard installation is tested.

Appears to have pipeline issues.

Used updated 11.x branch to create a new MR

the_g_bomb → changed the visibility of the branch 3501457-incorrect-path-used to hidden.

the_g_bomb → closed merge request !10977

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.