Compatibility with big_pipe

[Berdir]

I'm still on 1.x, but I'm having problems with the big_pipe module in 8.1.

Apparently behat/mink/goutte/guzzle doesn't follow the http-equiv refresh metatag that the module ads, and then it doesn't see messages or other "big-piped" blocks.

We should test if 3x still has that problem and possibly explicitly run the tests against 8.1 + big_pipe

[Berdir]

As a possible Workaround, Wim suggested to force the bigpipe no-js cookie for all requests.

[jhedstrom]

@Berdir so #259 is passing, but that doesn't actually mean this is fixed (we might just not be testing the right things--although there is a test for printed messages). I haven't been able to find any code in Guzzle, or Goutte, or Mink that indicates if http-equiv=refresh is actually used or respected. We might need a fix in the RawDrupalContext, or wherever else might make sense.

[Berdir]

I have tons of tests that assert messages. For example, create a node and then check that the confirmation message is shown. Do you have any of those? They all fail for me.

[jhedstrom]

@Berdir I added explicit tests over in #259 for messages, and they are still passing.

[jhedstrom]

259 has been merged, not sure what else can be done here without a way to make the tests fail with big pipe enabled.

[zaporylie]

BigPipe currently only is enabled for requests with a session. see https://www.drupal.org/node/2657684

259 only test messages for anonymous user.

[mglaman]

I know this is stale, but I hit this when needing to test local tasks block.

<div data-big-pipe-placeholder-id="callback=Drupal%5Cblock%5CBlockViewBuilder%3A%3AlazyBuilder&amp;args[0]=bartik_local_tasks&amp;args[1]=full&amp;args[2]&amp;token=7daf9ccc"></div><div id="block-bartik-content" class="block block-system block-system-main-block">

But tests fail. On "drupal/drupal-extension": "^3.2" 3.2.2

[mglaman]

The PR #259 with the BigPipeContext fixed my problems.

[leymannx]

You mean #325? It has the BigPipeContext, which also fixed it for me.

Strange enough I had two similar scenarios, one with a publisher user role, one with an editor user role, both log in, access a random node and should click the "Edit" button. For the publisher this worked, for the editor it doesn't.

Feature: Let's login as users with certain roles and check that node edit
  forms are accessible.

 @api
  Scenario: Login as publisher and try to edit some random node forms
    Given I am logged in as a publisher
    And I visit a random URL # custom step
    And I click "Edit"
    Then I should be redirected to a node form # custom step
    And the response status code should be 200

  @api
  Scenario: Login as editor and try to access some random node forms
    Given I am logged in as an editor
    And I visit a random URL # custom step
    And I click "Edit"
    Then I should be redirected to a node form # custom step
    And the response status code should be 200

This first one always was successful, the second always failed with:

Link with id|title|alt|text "Edit" not found. (Behat\Mink\Exception\ElementNotFoundException)

Finally triggered it down with an HTML screenshot using https://github.com/integratedexperts/behat-screenshot. I searched for the "Edit" string and found it wrapped in some BigPipe related <script> tag. Which after googling for drupal 8 bigpipe local tasks finally brought me here.

[leymannx]

And interesting to add, as soon as I used @javascript everything worked fine in a browser. It only happened on the bare @api tagged sessions.

[AlexSkrypnyk]

https://github.com/jhedstrom/drupalextension/pull/259 was merged in 2016, but I still do not see the BigPipeContext.php file in the codebase with version 3.4.1.

Had to convert that class into a trait to include intot my FeatureContext.php:

<?php

use Behat\Mink\Exception\UnsupportedDriverActionException;
use Drupal\big_pipe\Render\Placeholder\BigPipeStrategy;

/**
 * Big Pipe trait.
 */
trait BigPipeTrait {

  /**
   * Prepares Big Pipe NOJS cookie if needed.
   *
   * @BeforeScenario
   */
  public function prepareBigPipeNoJsCookie() {
    try {
      // Check if JavaScript can be executed by Driver.
      $this->getSession()->getDriver()->executeScript('true');
    }
    catch (UnsupportedDriverActionException $e) {
      // Set NOJS cookie.
      $this
        ->getSession()
        ->setCookie(BigPipeStrategy::NOJS_COOKIE, TRUE);

    }
    catch (\Exception $e) {
      // Mute exceptions.
    }
  }

}

[vever001]

Hello everyone,

I just attempted an update from v4.0.1 to v4.1.0 and I also run into issues with big pipe now.

I tried the BigPipeContext from https://github.com/jhedstrom/drupalextension/pull/325 but this doesn't seem to fix the issue. @Berdir 's comment here might explain why.

The failure happens when it tries to get a task from the Drupal local tasks block. The HTML is replaced by big_pipe which results in a: Element matching css ".block-local-tasks-block" not found. (Behat\Mink\Exception\ElementNotFoundException)

Running git bisect, it identified the following commit as the culprit: https://github.com/jhedstrom/drupalextension/commit/f0ecbb4645a0a0abb9128aa66d27823e7516c7ec

Any idea on what could be causing this from that commit? Before I investigate further. Thanks, Hervé

[pfrenssen]

It doesn't seem likely that this commit is related to the big pipe functionality since it is not involved with retrieving data from the page. Maybe the bisect failed because this commit is depending on a development branch of drupal/drupal-driver that no longer exists.

[vever001]

I didn't run composer during git bisect. Commenting those lines causes the issue to disappear.

// Log the user in on the backend if possible.
if ($this->driverManager->getDriver() instanceof AuthenticationDriverInterface) {
  $this->driverManager->getDriver()->login($user);
}

So I guess logging in to the backend causes big_pipe to change behavior and become truly active?

[mglaman]

So I guess logging in to the backend causes big_pipe to change behavior and become truly active?

Authenticated users bypass page_cache and BigPipe is then used to deliver dynamic_page_cache items.