ddev
use official images
Switch to official image
The Issue
#47
How This PR Solves The Issue
Changes the image used
Manual Testing Instructions
Automated Testing Overview
Related Issue Link(s)
Release/Deployment Notes
I did some testing on this - the latest version of the seleniarm image that works without any changes to DDEV settings is seleniarm/standalone-chromium:4.6.0-20221104. Some changes may be needed in order to get later versions working.
See https://drupal.slack.com/archives/C223PR743/p1727296167454149?thread_ts=1727266962.922249&cid=C223PR743
The problem with Drupal was that the Drupal 10.x versions used the outdated Nightwatch.js version 2.x (actually even locked to the 2.4.x version) that doesn't support the W3C protocol (which is the default for new Selenium).
And starting from the Drupal 11.1.0 release - they updated Nightwatch to 3.7 so it started to work well with the fresh Selenium: https://www.drupal.org/node/3467273
So, the outdated Selenium image doesn't work with Drupal 11.1, and we have to update it because Drupal 11.1.0 was released on 16 Dec 2024 and is well-used.
But maybe add a caveat that for the Drupal versions lower 11.1.0, we need to use the older image.
Drupal 11.1.x Nightwatch tests also work well even with the latest version of the Selenium image, if you set the DRUPAL_TEST_WEBDRIVER_W3C=true environment variable (or uncomment it in the [drupal_root]/core/.env file).
So, maybe set the latest in the PR too?
But maybe add a caveat that for the Drupal versions lower 11.1.0, we need to use the older image.
Sounds like a use case for a composer conflict statement
Looks like the tests are hanging, like they have in all previous effots. i dont know why. See https://github.com/ddev/ddev-selenium-standalone-chrome/pull/42
I am trying a bump to Drupal 11 during testing in #58. Would be nice if I could get push permission to bserem:patch-2 instead.
Just want to note that FunctionalJavascript tests also need Drupal core 11.1.x for W3C protocol support with newer selenium containers. There is an issue to back port those changes but it has stalled out for now: https://www.drupal.org/node/3421202
Legacy protocol support was dropped from Selenium in 2022 from what I could dig up: https://www.selenium.dev/blog/2022/legacy-protocol-support/
Rebased to include the latest changes. Not sure it's necessary since we have other PRs to bump chromium, but I did it anyway.
Just want to note that FunctionalJavascript tests also need Drupal core 11.1.x for W3C protocol support with newer selenium containers. There is an issue to back port those changes but it has stalled out for now: https://www.drupal.org/node/3421202
I wonder if can implement a similar BC bridge for older Drupal versions than what was added here. Seems possible on the first sight
https://git.drupalcode.org/project/gitlab_templates/-/commit/b6f6c6f96f6d625afcf24ac5ae80f3dc4331cd55#43d67bc931cefd24f13e24bc547132e1d13a7ced_1177_1183
Now finally a green build! So the only remaining question is the BC bridge...
Nice work!
I'm fine with releasing a new major version without that bridge, if you prefer. Also a mention in the README would be helpful.
I was also thinking about creating a new major for Drupal >= 11.1 and providing a (best effort? on-demand?) support for Drupal <10.x branch as long as it is supported in 1.x. What do you think?
Its a bummer that ddev add-ons dont have something like composer conflict statements. We have no way to prevent D10 sites from upgrading. Still, I think your plan is reasonable. Lets do it.
Maybe a pre-install action could prevent the update?
https://github.com/ddev/ddev-addon-template/blob/98c9daf1359fbd63587346c4b516b9a8ef592bee/install.yaml#L10
But creating a bulletproof solution consumes more time (than I currently have) so maybe I would just start with documentation and improve if necessary.
That works. In the error message, lets help the user build an add-on get command that will work.
I hope we didn't make a mistake by making this project a dependency of https://github.com/ddev/ddev-drupal-contrib/. We just added a core-version command there but it wont automatically switch the version of this add-on. I think its OK but something to consider.
Since maintainers often commit their project's add-ons to the repo, its problematic to have the add-on's version vary by Drupal core version. I think we should explore that backward compat bridge, unfortunately. That gitlab_templates link does look promising. I will try to get to this; I encourage others to also try.
I looked at at backward compat and I dont really feel like writing it. If anyone submits a PR, I'd be thankful. until then, we probably have to go with merging this and issueing a new major version.
I created a 1.x branch and then merged this PR into main. 1.x will get minimal maintenance. Also, I also released 2.0.0-rc1. That can be installed via ddev add-on get ddev/ddev-selenium-standalone-chrome --version 2.0.0-rc1. Please report any issues.
Also note that I used the new release with my keycdn contrib project and my WebDriverTestBase test is passing along with Drupal 10.5. Is the backward compat issue limited to Nightwatch?
It looks like ddev add-on get is fetching 2.0.0-rc1 by default even though its marked as pre-release. Not my intention, but its OK.