- ๐บ๐ธUnited States smustgrave
Removing the needs tests tag as they appear to have been added.
Still could use the IS update and change record so leaving the tags for those. Moving to NW for them.
Not super clear the issue
In Drupal 10 I added some terms to the tags vocabulary.
I'm able to have different orders per language. - ๐จ๐ฆCanada joseph.olstad
uploading a tests_only patch to prove that the patch 37 is needed.
- ๐จ๐ฆCanada joseph.olstad
sorry this one is better
stright up reroll for 10.1.x
- ๐จ๐ฆCanada joseph.olstad
Is this issue summary clear enough?
We need now a change record? or can this be skipped because it's 'optional'?
- Status changed to Needs review
12 months ago 8:31am 29 January 2024 - ๐ฎ๐ณIndia shalini_jha
I have able to Reproduce the issues in 11.x .
1) I have added dutch language (nl)
2) added same taxonomy terms as mentioned in IS.in english
3) added translation for two taxonomy term.
4) Changed weight in English and save . it is changing for both language.applied this patch #37 , its fixed the issues and weight is changing according to language selected.
please review and let me know if you need MR for this. - Status changed to Needs work
12 months ago 1:52pm 29 January 2024 The Needs Review Queue Bot โ tested this issue.
While you are making the above changes, we recommend that you convert this patch to a merge request โ . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)
- Merge request !6371Issue #2931680 by joseph.olstad, mohit_aghera, kriboogh, ita08, lorenzs:... โ (Open) created by joseph.olstad
- Status changed to Needs review
12 months ago 4:02pm 29 January 2024 - ๐จ๐ฆCanada joseph.olstad
The patch and the automated tests have been reviewed however the core maintainers will likely have their say.
Please create a change record.
Other than the change record, I believe this is ready.
- Status changed to Needs work
12 months ago 4:10pm 29 January 2024 - ๐บ๐ธUnited States smustgrave
Added some nitpicky stuff, but the update hook version should be updated.
Appears to have a phpcs issue.
Issue summary was missing standard template, got it started but left TBD for sections I can't answer not being familiar with issue.
Agree on the need for a CR
Also agree this appears close though!
- Status changed to Needs review
12 months ago 4:14pm 29 January 2024 - Status changed to Needs work
12 months ago 4:32pm 29 January 2024 The Needs Review Queue Bot โ tested this issue. It fails the Drupal core commit checks. 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.
- Status changed to Needs review
12 months ago 5:24pm 29 January 2024 - Status changed to RTBC
12 months ago 5:59pm 29 January 2024 - Status changed to Needs work
11 months ago 10:18pm 4 February 2024 - ๐ฆ๐บAustralia larowlan ๐ฆ๐บ๐.au GMT+10
Left some questions/comments on the MR
- ๐จ๐ฆCanada joseph.olstad
Head of 11.x/10.2.x is broken right now so we'll have to re-trigger tests once that's fixed. I imagine that'll be fixed soon.
https://www.drupal.org/node/3060/qa โ - ๐จ๐ฆCanada joseph.olstad
Looks like performance profiling tests show degraded performance when testing against Postgres 14.1 . Funny that the other DB systems tested do not have any performance regression.
There were 3 failures: 1) Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testAnonymous Failed asserting that 67 is identical to 66. /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121 /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/IsIdentical.php:79 /builds/issue/drupal-2931680/core/profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php:58 /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/TestResult.php:728 2) Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testLogin Failed asserting that 41 is identical to 38. /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121 /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/IsIdentical.php:79 /builds/issue/drupal-2931680/core/profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php:108 /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/TestResult.php:728 3) Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testLoginBlock Failed asserting that 50 is identical to 47. /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121 /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/IsIdentical.php:79 /builds/issue/drupal-2931680/core/profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php:138 /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/TestResult.php:728 FAILURES! Tests: 3, Assertions: 13, Failures: 3.
- ๐ง๐ชBelgium kriboogh
Applies to 10.3 and added patch of MR for composer use.
- ๐ณ๐ดNorway steinmb
Moving back to 11.x as we are addressing this in HEAD. As we are looking into this on sprint in Barcelona
- ๐ณ๐ดNorway steinmb
After digging into this, I do not think we can fix it during the sprint, however there is a few things that worry me here:
It the assumed performance regression test fail we are seeing coming from
taxonomy_term_data table and is now in the taxonomy_term_field_data table
?
If I am reading this right, we dictate that->setTranslatable(TRUE)
. Do we want to do that? Should this not be an option, most people might not want/need this behaviour? - ๐ฌ๐ทGreece vensires
You are correct @steinmb! These kind of things are not reversible - from what I know at least. Since this is a property in that entity's table and not a field, you can't optionally update its schema and set it as translatable or not according to the administrator's choices - at least it doesn't seem correct to do that in any other place than a hook_update_N() or hook_post_update_NAME() implementation.
I wonder whether something like views_term_hierarchy_weight_field โ 's approach is closer to what we need.