(There is no standard.profile component, so I don't know what component to put this in.)

Problem/Motivation

  1. As of #2797169: Mark BigPipe as stable/non-experimental, BigPipe is marked stable. This means Drupal 8.3 will ship with BigPipe being a stable module.
  2. BigPipe improves performance without downsides. It's entirely transparent.
  3. Dynamic Page Cache is the most comparable module in the Standard install profile: improves performance transparently (i.e. layered on top), without downsides.

Why does this make sense?

  1. All Drupal 8.3 sites that start from the Standard install profile, which is arguably mostly non-experts, would get the benefits of BigPipe. Which means evaluations of Drupal would benefit from this.
  2. Existing Drupal sites are not affected.
  3. Drupal shops/agencies/… usually have their own install profile, or even a per-client install profile. Which means that us changing the Standard install profile does not affect them in any way.

The only reason to not yet do this is to await the experience of Drupal 8.3 sites with BigPipe, since that's the first version of Drupal core in which BigPipe is marked stable. Which means pushing it to 8.5, i.e. Q2 2018.

Proposed resolution

Install the BigPipe module by default in Drupal 8.5 Standard install profile installations.

Remaining tasks

  1. Discuss
  2. TBD

User interface changes

None.

API changes

None.

Data model changes

None.

CommentFileSizeAuthor
#73 enable_bigpipe_by-2840392-73.patch5.18 KBWim Leers
#73 interdiff.txt724 bytesWim Leers
#71 enable_bigpipe_by-2840392-71.patch5.17 KBWim Leers
#71 interdiff.txt2.24 KBWim Leers
#59 enable_bigpipe_by-2840392-59.patch3.03 KBWim Leers
#59 interdiff.txt1.86 KBWim Leers
#55 enable_bigpipe_by-2840392-55.patch4.42 KBWim Leers
#50 enable_bigpipe_by-2840392-50.patch4.37 KBWim Leers
#50 interdiff.txt849 bytesWim Leers
#33 interdiff-2840392-29-33.txt1.1 KBJacobSanford
#33 enable_bigpipe_by-2840392-33.patch4.15 KBJacobSanford
#29 enable_bigpipe_by-2840392-29.patch4.11 KBYogesh Pawar
#25 interdiff.txt1.05 KBWim Leers
#25 big_pipe_standard_default-2840392-25.patch4.51 KBWim Leers
#22 big_pipe_standard_default-2840392-18.patch3.5 KBWim Leers
#18 big_pipe_standard_default-2840392-18.patch3.5 KBWim Leers
#18 interdiff.txt1.6 KBWim Leers
#17 big_pipe_standard_default-2840392-17.patch1.94 KBWim Leers
#17 interdiff.txt819 bytesWim Leers
#16 big_pipe_standard_default-2840392-5.patch1.81 KBWim Leers
#5 interdiff.txt1.39 KBWim Leers
#5 big_pipe_standard_default-2840392-5.patch1.81 KBWim Leers
#2 big_pipe_standard_default-2840392-2.patch435 bytesWim Leers
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

Wim Leers created an issue. See original summary.

Wim Leers’s picture

Status: Active » Needs review
FileSize
435 bytes

And patch :)

Wim Leers’s picture

Title: Enable BigPIpe by default in the Standard install profile » Enable BigPipe by default in the Standard install profile

Status: Needs review » Needs work

The last submitted patch, 2: big_pipe_standard_default-2840392-2.patch, failed testing.

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
1.81 KB
1.39 KB

This fixes most failures: updates the cache context assertions in two tests.

cilefen’s picture

Issue tags: +8.3.0 release notes

If it does happen...

Status: Needs review » Needs work

The last submitted patch, 5: big_pipe_standard_default-2840392-5.patch, failed testing.

effulgentsia’s picture

The only reason to not yet do this is to await the experience of Drupal 8.3 sites with BigPipe

For me, that's the key question: do we want to first see what issues are reported when a broader set of sites enable BigPipe (thanks to it being stable in 8.3) prior to adding it Standard? Or is such caution unnecessary? Seems like a release management question to me, so tagging for that review.

xjm’s picture

Status: Needs work » Postponed
Issue tags: -8.3.0 release notes, -Needs release manager review

@Wim Leers, @effulgentsia, and I discussed this issue this morning and I'd like to postpone this issue to 8.4.x, so that we have the stable module in a shipped core release for testing etc. before we change standard.

Wim Leers’s picture

Works for me!

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Wim Leers’s picture

Issue tags: +8.4.0 release notes

8.4 is open for development now. But I think it's still too early in the cycle. Already tagging though, this should help prevent us to forget to assess this.

xjm’s picture

Status: Postponed » Active
Issue tags: -8.4.0 release notes

Well no, we should only put the tag on issues that are already committed or close thereto. It's already hard enough for release managers to sort through those that do land.

Also, I think it would actually be best for this issue to be active now. In some ways, once we agree on the change, it's best to commit it early. That gives us the longest time possible to catch regressions on new Standard installations that might result from edgecases etc. that were not tested on real sites yet.

So, unless there is a specific issue that this should be postponed on, let's mark it active and start discussing whether we want to do this. :)

Thanks @Wim Leers.

xjm’s picture

Status: Active » Needs work

Or well, there is also already a patch.

Wim Leers’s picture

Thanks, and sorry!

Wim Leers’s picture

Status: Needs work » Needs review
FileSize
1.81 KB

Reuploading #5, because some of the failures were random update path test failures that have since been resolved.

Wim Leers’s picture

And this updates the expected cache contexts for NodeTranslationUITest.

Wim Leers’s picture

And this then finally updates StandardTest, to execute Javascript, wait for BigPipe to finish sending content before asserting a raw string, and updates the expected raw string from <br /> to <br>.

Now tests pass.

The last submitted patch, 16: big_pipe_standard_default-2840392-5.patch, failed testing.

The last submitted patch, 17: big_pipe_standard_default-2840392-17.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 18: big_pipe_standard_default-2840392-18.patch, failed testing.

Wim Leers’s picture

FileSize
3.5 KB

#18 failed due to a malfunctioning testbot:

00:33:21.038 Drupal\system\Tests\Module\InstallUninstallTest              3202 passes                                      
00:33:42.775 Drupal\views_ui\Tests\PreviewTest                            237 passes                                      
00:33:46.108 Drupal\views_ui\Tests\HandlerTest                            516 passes                                      
00:34:00.017 Drupal\views\Tests\Plugin\ExposedFormTest                    131 passes                                      
00:34:32.145 Drupal\views_ui\Tests\DisplayTest                            361 passes                                      
01:50:00.019 Build timed out (after 110 minutes). Marking the build as aborted.
01:50:00.024 Build was aborted
01:50:00.024 [CHECKSTYLE] Skipping publisher since build result is ABORTED
01:50:00.024 Archiving artifacts
01:50:00.034 Checking console output
01:50:00.038 Recording test results
01:50:00.056 ERROR: Step ‘Publish JUnit test result report’ failed: No test report files were found. Configuration error?
01:50:00.062 Finished: ABORTED

Reuploading #18.

Wim Leers’s picture

Status: Needs work » Needs review
Wim Leers’s picture

Assigned: Unassigned » Wim Leers
Status: Needs review » Needs work

Ah, damn, I thought #18 fixed the last problem, but there's one more: StandardInstallerTest also fails. Will work on fixing that.

Wim Leers’s picture

Well that's annoying.

The StandardInstallerTest failure is legitimate. It uncovered a new edge case, one that we had hitherto assumed could not possibly happen: a message displayed on the very first request to Drupal.

After installing Drupal, \install_finished() does this:

  $success_message = t('Congratulations, you installed @drupal!', array(
    '@drupal' => drupal_install_profile_distribution_name(),
  ));
  drupal_set_message($success_message);

It doesn't show this message on the last page of the installer… but on the first page thereafter.

That first page thereafter is the first page that is rendered by Drupal itself; everything before that is rendered by the installer, which is a special snowflake: it's a limited environment, where advanced features are not available, including BigPipe.

Because it's the first pageload, and because StandardInstallerTest uses WebTestBase which does not support executing JS, we follow the no-JS redirect. Which means that this is what happened:

  1. Step 1: request the frontpage. Rendered by BigPipe, using JS BigPipe placeholders. Includes rendered messages. But includes the no-JS redirect.
  2. Step 2: since this browser does not support JS, we follow the redirect.
  3. Step 3: request the frontpage. Rendered by BigPipe, using no-JS BigPipe placeholders. There are no messages to render, because they were already rendered in step 1!

This assertion was added in #2458925: Screen is black and completely unreadable in Configure page after install on standard profile:

    $this->assertRaw(t('Congratulations, you installed @drupal!', array(
      '@drupal' => drupal_install_profile_distribution_name(),
    )));

… but this was picked rather arbitrarily. We could just as well verify some other text on the default installer page. So, changing that to:

$this->assertRaw('No front page content has been created yet.');

Finally: if you're wondering but shouldn't we fix this in BigPipe?, then the answer is: it's something that only ever happen in the installer, because that's the only way you can have your first page load already have a session (because we're coming from the installer, which doesn't use regular rendering system) and a status message. Without a session, no status message. Without a session, no BigPipe.

Status: Needs review » Needs work

The last submitted patch, 25: big_pipe_standard_default-2840392-25.patch, failed testing.

Wim Leers’s picture

Status: Needs work » Needs review

Let's re-test. Because core has changed since Feb 20, but also because the patch in #25 failed, but d.o is not linking to the testbot results for some reason…

Status: Needs review » Needs work

The last submitted patch, 25: big_pipe_standard_default-2840392-25.patch, failed testing.

Yogesh Pawar’s picture

Status: Needs work » Needs review
FileSize
4.11 KB

Re-roll of the #25 patch because it's failed to apply on 8.4.x branch.

Wim Leers’s picture

Looks good, thank you, @Yogesh Pawar!

Status: Needs review » Needs work

The last submitted patch, 29: enable_bigpipe_by-2840392-29.patch, failed testing.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

JacobSanford’s picture

Status: Needs work » Needs review
FileSize
4.15 KB
1.1 KB

Popping it up again! @YogeshPawar's patch in #29 no longer applied to 8.5.x. A reroll with no further modifications is attached.

Status: Needs review » Needs work

The last submitted patch, 33: enable_bigpipe_by-2840392-33.patch, failed testing. View results

cilefen’s picture

Issue tags: +rc target
Wim Leers’s picture

Assigned: Wim Leers » Unassigned
Status: Needs work » Reviewed & tested by the community

Exciting, a green patch!

Per #8 and #9, the only thing really preventing an RTBC 8 months ago was the fact that BigPipe should first be shipped with an entire minor cycle: Drupal 8.3. Since then, no significant bugs have been reported. In fact, since creating this issue, only 4 issues were created:

  1. #2863607: Convert WebTestBaseTests of BigPipe to BrowserTestBase, which is about modernizing our test infrastructure
  2. #2886657: BigPipe changes CSS evaluation order, which was a support request
  3. #2903614: [PP-1] Race condition results in same CSS+JS being loaded twice: race between BigPipe's server-side dynamic asset loading and Quick Edit's client-side dynamic asset loading, which is at worst a normal bug, but it's not yet certain that it's actually a bug
  4. #2903623: BigPipe test hardening: check that CKEDITOR exists to prevent script throws error immediately , which is about hardening a test

So I think that given that, BigPipe has proved its stability.

Therefore: RTBC'ing since this is green + a release manager decision.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 33: enable_bigpipe_by-2840392-33.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Needs review
01:50:00.487 Build timed out (after 110 minutes). Marking the build as aborted.

So apparently there is still a problem here.

Yet the previous testrun was timely and successful: https://dispatcher.drupalci.org/job/drupal_patches/27621/console … so it seems like this is just test infrastructure problems? Retesting…

Wim Leers’s picture

Issue tags: -rc target

Re-testing.

Let's get this in Drupal 8.5!

JacobSanford’s picture

Now that test shows green, re-escalating to RTBC as per @wim-leers's previous escalation.

Wim Leers’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs product manager review

The test took 45 minutes (on Oct 13, 18:41 CEST). The closest D8 HEAD test run occurred on Oct 13, 20:36 CEST and took 48 minutes. Strangely, with different concurrency levels. AFAICT on 2 different bots. In any case, enabling BigPipe for the Standard install profile doesn't seem to make a material difference to test runs.

I don't think there's anything blocking this from becoming RTBC now. BigPipe will have been a stable module in Drupal 8 core for two release cycles (8.3 + 8.4). If material problems arise, we can still revert this. I've gotten the question Why isn't BigPipe enabled by default? many times now.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 33: enable_bigpipe_by-2840392-33.patch, failed testing. View results

Wim Leers’s picture

Status: Needs work » Reviewed & tested by the community

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 33: enable_bigpipe_by-2840392-33.patch, failed testing. View results

JacobSanford’s picture

Status: Needs work » Reviewed & tested by the community
xjm’s picture

Status: Reviewed & tested by the community » Needs review
Issue tags: +Needs release manager review

> 50% of the test runs on this issue have failed (due to timeouts apparently?), not just a few days ago but also back in August when the patch was last tested. It'd be a surprising coincidence for this patch to have been tested in two windows months apart where testbot happened to be unstable in this way. And, indeed, looking at the branch test history https://www.drupal.org/pift-ci-job/789866 indicates that there was no corresponding testbot problem a few days back for HEAD.

So I'm pretty sure having BigPipe in Standard is making the test suite less stable, in a serious way. Without having an explanation for what exactly is going on, I'd not want to commit this to HEAD, because if I'm right we'd be introducing a 50% random fail into everyone else's patches.

When an issue repeatedly gets marked NW with testbot failures, listen to the bot. :) Sometimes there are random failures or spates of bot issues, but don't just assume it's that -- look into it.The branch tests run every day and several times a day when there's commits so you can go to https://www.drupal.org/node/3060/qa, click on the environment that failed. If you still think it's not your patch's fault, you can add a patch that changes a .php file but does not include your change as a test-only patch for the baseline. My default is:

diff --git a/core/lib/Drupal.php b/core/lib/Drupal.php
index 18f880e82d..b284ee9b28 100644
--- a/core/lib/Drupal.php
+++ b/core/lib/Drupal.php
@@ -2,7 +2,7 @@
 
 /**
  * @file
- * Contains \Drupal.
+ * Contains \Drupal!
  */
 

Thanks everyone! Setting NR to look more deeply into the testing issue. I'd suggest investigating reasons that BigPipe in Standard might actually make stuff time out, and comparing logs of the problematic runs to logs of HEAD and the regular test runs on the same day. Before we'd commit this I'd also want to see hard evidence that the issue is resolved and an explanation of what was causing this.

Leaving the product manager review tag on because we'd need that signoff still even once the test issue is fixed. And also tagging for release manager review on account of the test concerns and release management implications.

Thanks!

Wim Leers’s picture

Fully agreed, of course.

But getting to the bottom of this is going to be very, very difficult, because the successful test runs are not at all slower than HEAD’s test runs. That’s what I explained and researched in #41. How one test run of the patch can be indistinguishable from a HEAD test run and another shortly thereafter can time out after taking more than twice as long is a complete mystery to me 😥

I’ll work with the testbot maintainers to get to the bottom of this.

Wim Leers’s picture

Pinged mixologic.

Mixologic’s picture

This is a single test that is failing to complete, the rest of the test run is running fine.

I compared the test output from the console of the most recent successful test: https://dispatcher.drupalci.org/job/drupal_patches/33853/ with the next consecutive failure, and pared it down to just the test names.

This is what I found:

1185,1187d1184
< Drupal\Tests\hal\Functional\EntityResource\EntityFormMode\En
< Drupal\Tests\hal\Functional\EntityResource\EntityFormMode\En
< Drupal\Tests\hal\Functional\EntityResource\EntityFormMode\En
1715,1717d1711
< Drupal\Tests\rest\Functional\EntityResource\EntityFormMode\E
< Drupal\Tests\rest\Functional\EntityResource\EntityFormMode\E
< Drupal\Tests\rest\Functional\EntityResource\EntityFormMode\E
1886a1881
> Drupal\Tests\standard\Functional\StandardTest

The EntityFormMode tests were new tests introduced in between the 13th, and the 16th, so its no surprise they are showing up. We can ignore those.

The test that never completes is the StandardTest.

I have a pretty strong hunch that this is because you're changing the testbase from BrowserTestBase to JavascriptTestBase, but you are not moving the test into a FunctionalJavascript namespace.

The testbot, and phantomjs, would sometimes hang, and never finish when running javascript tests in parallel, so we separated out the FunctionalJavascript tests and run those separately and serially. Except in this case it is still trying to run the StandardTest along with all the other tests.

Interesting that even just *one* Javascript test can hang if there's any parallelization going on.

So, my suggestion is to update the patch to move the namespace to Drupal\Tests\standard\FunctionalJavascript\StandardTest so that it is tested in the safety of non being parallelized.

dawehner’s picture

This is yet another of the instances where the phpunit test runner differs from what we do in run-tests.sh, sadly.

Is there a reason we could not at least keep some of the existing test coverage in the non javascript bit? I fear we would loose a bit of test coverage when we require JS for these tests.

Wim Leers’s picture

What test coverage do we lose?

Wim Leers’s picture

I just queued a re-test of #50, and also queued tests in every available combination of environments.

That's a lot of tests, but should help us confirm that the random timeouts are a thing of the past.

(We can then of course still look into @dawehner's concern! Just trying to confirm that Mixologic's analysis was as flawless as I think it is 😀)

Status: Needs review » Needs work

The last submitted patch, 50: enable_bigpipe_by-2840392-50.patch, failed testing. View results

dawehner’s picture

What test coverage do we lose?

Well, we do all kind of stuff here, submitting forms, hitting URLs etc. It would be nice to ensure that those continue to work without JS involved.

Wim Leers’s picture

Assigned: Unassigned » Wim Leers
Status: Needs review » Needs work

Oh, of course! Sorry for not realizing that. Will work on reroll that keeps all other tests except one in Functional rather than FunctionalJavascript.

dawehner’s picture

No worries, that's why we have review :)

Wim Leers’s picture

On Feb 20, 2017, in #17, StandardTest failed. It failed to find certain elements. It looks like since then, our test dependencies/infrastructure changed, because I can now get StandardTest to pass (at least locally) without changing anything about it. That'd of course be the ideal solution to @dawehner's remark: simply being able to remove the change altogether :)

(Ironically, then @Mixologic's research in #49 also would not have been necessary.)

Let's see if this is also the case on testbot.

dawehner’s picture

I'm wondering: Do we still need some form of JS test to prove big pipe is actually running in some form or another?

Wim Leers’s picture

+++ b/core/modules/node/tests/src/Functional/NodeTranslationUITest.php
@@ -21,13 +21,15 @@ class NodeTranslationUITest extends ContentTranslationUITestBase {
+    'cookies:big_pipe_nojs',

+++ b/core/modules/page_cache/tests/src/Functional/PageCacheTagsIntegrationTest.php
@@ -76,6 +76,9 @@ public function testPageCacheTags() {
+      'cookies:big_pipe_nojs',

Any test that uses the standard install profile that also tests cache contexts will have something like this.

We already have extensive, detailed test coverage for BigPipe itself.

I think that's sufficient? Of course, the whole point about BigPipe is that it is a transparent change: if we'd have to change lots of tests, that'd prove that it wasn't transparent!

One thing I can think of that'd be a useful smoke test: we can add explicit test test coverage to verify that e.g. the comment form for an article is served via BigPipe in the Standard install profile.

dawehner’s picture

One thing I can think of that'd be a useful smoke test: we can add explicit test test coverage to verify that e.g. the comment form for an article is served via BigPipe in the Standard install profile.

Given that this actually increases the performance of the site, this sounds like a really nice idea!

Wim Leers’s picture

Status: Needs review » Needs work

Alright :) 👍

webchick credited Bojhan.

webchick credited yoroy.

webchick’s picture

Reviewed this issue on today's product management meeting.

Making users' sites faster out of the box sounds like a good thing to do. :) So no objections from the product management team. Makes total sense.

We played around a bit with this patch + the Google Chrome network slower-downer thingy to try and evaluate the user experience. It would be awesome to pick up where we left off at #2632750: Interface previews (not a pre-requisite for this patch at all, just would make for a noticeably nicer out of the box experience).

Wim Leers’s picture

Thanks, @Bojhan, @Gábor Hojtsy, @yoroy and @webchick! Much appreciated! ❤️

I agree that having #2632750: Interface previews would make things even nicer. I'll try to push that one along again too.

Right now, the only blocker here is me working on the expanded/improved test coverage that @dawehner and I discussed in #60–#63. This issue is already assigned to me for that.

rmcdiarmid@adaptiveinsights.com’s picture

I'm worried that dynamic page components - like for example an integrated Hubspot Form - would be invisible to SEO using this method.

Also Big Pipe only applies to logged in traffic - so if your site never uses logged in users but for site content changes - Big Pipe doesn't do anything for you. all but .000001% of my site is unauth nonlogged in users of my site.

Wim Leers’s picture

I'm worried that dynamic page components - like for example an integrated Hubspot Form - would be invisible to SEO using this method.

With 100% certainty this is not the case. To convince yourself: install BigPipe, see how it uses JS if your browser supports JS, then disable JS, and see how it still streams the content, but doesn't use JS.

This very concern was already addressed before BigPipe was added to core. If it broke such use cases, it A) never would've been added to core, B) would have caused lots of bug reports in the >1.5 years it's been in core.

Also Big Pipe only applies to logged in traffic - so if your site never uses logged in users but for site content changes - Big Pipe doesn't do anything for you.

Correct. So let's make things faster for site builders :)

Wim Leers’s picture

Assigned: Wim Leers » Unassigned
Status: Needs work » Needs review
FileSize
2.24 KB
5.17 KB

Implemented @dawehner's suggested additional test coverage.

Status: Needs review » Needs work

The last submitted patch, 71: enable_bigpipe_by-2840392-71.patch, failed testing. View results

Wim Leers’s picture

Failed due to:

00:54:03.460 Fatal error: Cannot declare class Drupal\Tests\standard\Functional\StandardJavascriptTest, because the name is already in use in /var/www/html/core/profiles/standard/tests/src/FunctionalJavascript/StandardJavascriptTest.php on line 0

I think this might fix it. (I can't reproduce the failure locally.)

dawehner’s picture

Thank you @Wim Leers
I think this patch is ready to go. I am a bit hesitant with the premise of the patch itself. Sure it improves performance for the users. One problem I see though is that this makes it harder for people to understand/debug. Content being loaded later, might cause issues with things like google analytics. Making this a conscious choice might help with that.

Wim Leers’s picture

Content being loaded later, might cause issues with things like google analytics.

The main content is never loaded via BigPipe, for this very reason: serving an empty shell is pointless, we want to ensure that the main content is always available from the very start (i.e. the reason for the user to visit this page/URL).

Furthermore, this only affects new sites using the Standard install profile. We want to show Drupal at its best out of the box, don't we?

Wim Leers’s picture

Product manager sign-off in #67:

Making users' sites faster out of the box sounds like a good thing to do. :) So no objections from the product management team. Makes total sense.

Patch sign-off in #74:

I think this patch is ready to go.

So I'd RTBC this again, but we still have a Needs release manager review tag.

dawehner’s picture

Status: Needs review » Reviewed & tested by the community

Fair point :) To be honest I hope the out of the box initiative actually produces something which shows how great Drupal itself is.

vaplas’s picture

Woot! BigPipe super rocks!

xjm’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: -Needs release manager review

Nice research @Mixologic.

Following that, I queued sufficient test runs to convince myself that this is no longer breaking them.

Committed and pushed to 8.5.x. Thanks! I also created and published a change record: https://www.drupal.org/node/2921159

Wim Leers’s picture

OMG yay! 🎉

This probably merits a mention in the 8.5.0 release notes?

Gábor Hojtsy’s picture

Issue tags: +8.5.0 release notes
vaplas’s picture

It's great! Many thanks! 🚀🚀🚀

effulgentsia’s picture

Congratulations, Big Pipe, for being the first D8 core module to make it through the full pipeline of experimental -> stable -> standard! I'm looking forward to more of our experimental modules following that lead and benefitting from all that's been learned along the way by Big Pipe on how to do it!!

Wim Leers’s picture

Thanks, Alex! 😀

xjm’s picture

I haven't gotten to posting it yet, but from now on the release notes are only going to contain things that people need to know to upgrade. Cool stuff is going to be tagged "8.5.0 highlights". Instituting that for the first time here. :)

Wim Leers’s picture

WOOT! 😊

  • xjm committed 113c6dc on 8.5.x
    Issue #2840392 by Wim Leers, JacobSanford, Yogesh Pawar, dawehner, xjm,...
JacobSanford’s picture

Many thanks, @wim-leers for your efforts here. This is a fantastic change for 8.5.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.