Problem/Motivation

To reproduce:

Go to Block layout (admin/structure/block).

Choose a region and click Place block.

Select a block to place, and configure it.

After this is done, I would expect to go back to the Block layout page. Instead, I am looking at the list of available blocks (admin/structure/block/library/bartik, which you normally only see as a pop-up window after clicking Place block).

The bug appears in 8.2.x and exists in 8.3.x.

Proposed resolution

Make it so after placing a block, you get back to the main block layout page.

Remaining tasks

Fix the bug and make a patch. If possible, make a test for it too.

User interface changes

After placing a block, you should get back to the main block layout page.

API changes

None.

Data model changes

None.

Comments

jhodgdon created an issue. See original summary.

evaldask’s picture

A bit weird for sure. This patch should fix that.

evaldask’s picture

Status: Active » Needs review
evaldask’s picture

A nicer implementation

Status: Needs review » Needs work
cilefen’s picture

Title: After placing block, I'm returned to a weird page » [regression] after placing block, you are directed to the block library (example: admin/structure/block/library/bartik) rather than to the block layout
Priority: Normal » Major
Issue summary: View changes

This appears in 8.2 and exists in 8.3.

cilefen’s picture

cilefen’s picture

Title: [regression] after placing block, you are directed to the block library (example: admin/structure/block/library/bartik) rather than to the block layout » [regression] After placing a block and saving, you are directed to the block library (example: admin/structure/block/library/bartik) rather than to the block layout
willzyx’s picture

StatusFileSize
new3.1 KB

The problem seems to be the usage of RedirectDestination::get(). This method always return a result even if the 'destination' query string is not set:

  /**
   * {@inheritdoc}
   */
  public function get() {
    if (!isset($this->destination)) {
      $query = $this->requestStack->getCurrentRequest()->query;
      if (UrlHelper::isExternal($query->get('destination'))) {
        $this->destination = '/';
      }
      elseif ($query->has('destination')) {
        $this->destination = $query->get('destination');
      }
      else {
        $this->destination = $this->urlGenerator->generateFromRoute('<current>', [], ['query' => UrlHelper::buildQuery(UrlHelper::filterQueryParameters($query->all()))]);
      }
    }

    return $this->destination;
  }

so if the destination is not set the current route path is returned.
Probably you can use the value retrieved from the request instead of rely on redirect destination service

willzyx’s picture

Status: Needs work » Needs review
willzyx’s picture

Added a test for ensure that if destination query string is not present you are redirected by default to the block list page

The last submitted patch, 11: regression_after-2794559-11-test-only.patch, failed testing.

tim.plunkett’s picture

Honestly I would consider this a bug in RedirectDestination::get(), but I don't think we can change that behavior without breaking BC, so I agree this is a good fix.

We should probably document that RedirectDestination::get() will ALWAYS return something, even if it's the current page.

tuutti’s picture

StatusFileSize
new5.72 KB
new611 bytes

+1 to this.

I copied @return comment from RedirectDestinationInterface::getAsArray() to ::get(). Not sure if further documentation is needed.

dawehner’s picture

Given the regression, I think we should actually revert the patch and then fix stuff without introducing a regression in the first place. This could easily affect other code as well.

tim.plunkett’s picture

Status: Needs review » Closed (duplicate)

Marked #2745911: Block add links should respect destination for revert.
Let's correctly fix it again from scratch.