#Needs framework manager review

Generally I'm in favour of backporting the test improvements because it helps modules support multiple branches of core with no code changes.

However that has also been hard with performance tests where the tests themselves that rely on the APIs differ between the branches - to the point where we gave up backporting some changes to 10.x

e.g. FooTest is added in 10.3 and 11.0, FooTest diverges from the 10.x version in 11.1. FooTestBase gets a new improvement in 11.2 - now the changes to the test itself in 11.1, that can be updated to the new API in 11.2, aren't backportable to 10.3. So you end up having to make a separate backport MR with either only the test API addition, or the API addition and also refactoring the 10.x version of the test.

Proposal #1 seems good to me - it's completely reasonable to require people running tests to use prefer-source.

Composer patches was brought up, but now that we're using MR diffs on d.o everywhere, it's not recommended to link to the online MR diff anyway for security reasons, instead people should commit a local copy of the patch (or use one uploaded to the issue in some cases). When preparing that patch, it's fine to delete any changes to test files. This also makes it more likely that the patch will apply longer if unrelated changes to test coverage are committed to the project too, sometimes I do it anyway for that reason, especially backporting something for a previous minor/major release.

This was originally proposed before Layout Builder even existed.
Now we will have Experience Builder as well.

I don't know that there's much remaining value in this issue as written, I would move to close it.

We were using the patch from 545. After upgrading to Drupal 10.5.1, it still applied cleanly, but caused critical errors because it duplicated the <?php tag and rest of the code.

If you're seeing `Parse error: syntax error, unexpected '<'` remove the patch.

Just a warning for others that may be using it!

Since I am having difficulty getting the issue reproduced (and the bug report in our project is a little old), submitting a branch with only the test changes to see if it is still broken.

I just submitted the most basic MR implementing this idea, because I was running into the exact scenario of the duplicate search form. I did include the test patch, but nothing in the way of deprecation code yet. I did ponder it for a bit, but it is not evident to me how to deprecate this properly. Do we include a whole new function that people should call instead? If so, should this issue cover all core use of the old function?

OK, that aligns with our general approach to only add modules we actively need rather than adding ones that may come in handy.

Some of those issues could probably be added as children of 🌱 [meta] Drupal modernization Active , there's also more recent things like using service closures, autowiring etc. to reduce boilerplate. But agreed it doesn't need a specific initiative as such.

I've also never used the country or currency fields.

For me personally I would leave the address dependency to specific recipes (and pretty much the same with any other module that's not directly supporting base recipes), because if it's not installed, it can cause composer dependency issues down the line.

Moving to the core queue, this needs to be re-evaluated in the world of experience builder and SDCs.

I personally have never used the Currency or Country field and their usage is quite low. Address is included in the event recipe, and would be for other relevant recipes. I would be open to the argument that we should ship Address by default, but is there a case for the other two?

I think this could use an evaluation of which (if any) of these fields types are in use, or planned to be in use, in Drupal CMS. If they are, and they're otherwise high usage, then we could look at including them in core, but feels unlikely otherwise. There was also a discussion recently in slack, not sure there's an issue yet, about telephone really belongs in core, because a lot of sites have to install one or two contrib modules to make it usable.

drush is a dependency of Drupal CMS so moving this to the core queue.

chrisfromredfin → credited gábor hojtsy → .

chrisfromredfin → credited leslieg → .

chrisfromredfin → credited thejimbirch → .

This wouldn't go into vanilla Drupal CMS, but would make sense for site templates with this requirement.

mrinalini9 → changed the visibility of the branch 11.x to active.

mrinalini9 → changed the visibility of the branch 11.x to hidden.

Changing to latest version when this was closed.

Changing to latest version when this was closed.