- π¬π§United Kingdom catch
Tagging for release highlights not because we should add the details here, but we can talk about the end result in combination with other issues that should also improve aggregate hit rates in 11.2
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.
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.
- π¬π§United Kingdom catch
There's nothing really for site owners to respond to, so I don't think a release note is right here, but added a change record.
- π¬π§United Kingdom catch
Test failures on the test only job show the improvement:
Asserting ScriptBytes 249765 is greater or equal to 170000 and is smaller or equal to 171000 Failed asserting that 249765 ( is equal to 170000 or is greater than 170000 ) and ( is equal to 171000 or is less than 171000 ). /builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:623 /builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:672 /builds/project/drupal/core/profiles/demo_umami/tests/src/FunctionalJavascript/AssetAggregationAcrossPagesTest.php:54 2) Drupal\Tests\demo_umami\FunctionalJavascript\AssetAggregationAcrossPagesTest::testFrontAndRecipesPagesEditor Asserting ScriptBytes 417181 is greater or equal to 337700 and is smaller or equal to 338700 Failed asserting that 417181 ( is equal to 337700 or is greater than 337700 ) and ( is equal to 338700 or is less than 338700 ). /builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:623 /builds/project/drupal/core/tests/Drupal/Tests/PerformanceTestTrait.php:672 /builds/project/drupal/core/profiles/demo_umami/tests/src/FunctionalJavascript/AssetAggregationAcrossPagesTest.php:76 FAILURES!
https://git.drupalcode.org/project/drupal/-/jobs/4641371
So about 80kb reduction in bytes downloaded across a couple of pages and reproducible with stock Umami.
- πΊπΈUnited States smustgrave
haven't manually test but all tests appear to be failing.
- @catch opened merge request.
- Issue created by @catch
- πΊπΈUnited States smustgrave
Ah thanks. Took your advice from slack and used the revision log area to test and can confirm I can still drag the textarea up and down
- π¬π§United Kingdom catch
OK that's not affected by this, only affects textareas (the draggable corner, when it's there).
- π¬π§United Kingdom catch
@smustgrave did you resize the browser window or the textarea? The ckeditor textarea isn't resizable (at least not out of the box), however the revision information box should be vertically resizable.
- πΊπΈUnited States smustgrave
So I tested this one on a standard install of 11.x
Went to the add Article node form
Using the browser changed size left and right, up and down and everything resized just fine.Leaving the tag if there is additional testing that should be done, else LGTM
- π¬π§United Kingdom catch
This is within the threshold of asset sizes in performance tests because it's a small file, meaning tests don't fail due to the improvemnet, but it allows us to lower those threshold a little bit, so have done that.
- @catch opened merge request.
- Issue created by @catch
- π¬π§United Kingdom catch
@smustgrave it should only affect the status report so that should be sufficient testing.
Updated the performance tests - all expected reductions in the amount of CSS we serve so that's good.
- πΊπΈUnited States smustgrave
Applied the MR and went to the status report page and all seems fine, is there another thing I should be testing?
Moving to NW as the test failures I believe are legit as they are all around test performance.
- π¬π§United Kingdom catch
This needs basic manual testing. Install the standard profile, visit admin/reports/status, apply the MR, clear caches, refresh the page - make sure it's still styled correctly.
- @catch opened merge request.
- Issue created by @catch