Custom block creation form redirect is inconsistent

This was fixed in #2064591: Missing test coverage for multiple custom block types

Apparently it wasn't, according to xjm.

Grr you can see the destination in the URL on the list screen but either it's not in the links or overlay stuffs it. Hoping it's the latter cause the tests do exactly what the video does. The only difference is overlay.

Nope doesn't work. Has to be seven.

Yep http://drupalcode.org/project/drupal.git/blob/refs/heads/8.x:/core/theme... missed the override. Mystery solved.

I'm not sure which is stranger, seven_custom_block_add_list completely bypassing the preprocess, or custom-block-add-list.html.twig using the "node-type-list" class :)

Good find!

So in terms of 'needs tests' do we need to duplicate the tests with the seven theme enabled </groan>

Can't we just gut/remove the seven override? Also, put the test into a helper method and run it twice...

I can't comment on tim.plunkett's idea in #10, but after applying the patch in #8 by larowlan, I can confirm that desired redirect effect happens.
Here is a video of after the patch: http://www.youtube.com/watch?v=8PaGHF110Pg

This still needs tests.

Agreed approach: remove the override in seven

Working on this.

Well this is fun!

CustomBlockInterface::getTheme() and CustomBlockInterface::setTheme() are never actually used.
Or, that is, setTheme() is never used.

So this isn't even really related to the OP, but is covered under the title.

Current URL is 'http://ns4007744.ip-192-95-30.net/checkout/admin/structure/block/add/custom_block%3A35922bf3-3d37-4bed-8502-2a192c94b332/seven'.
Current URL is 'http://ns4007744.ip-192-95-30.net/checkout/admin/structure/block/add/custom_block%3Ae570ce8e-e2b9-4227-9105-5d711f7568ce/bartik'.

Those are wrong because it always 'stark' due to getTheme() always returning NULL because setTheme() is never called:

CustomBlockFormController:

        if ($theme = $block->getTheme()) {
          $form_state['redirect'] = 'admin/structure/block/add/custom_block:' . $block->uuid->value . '/' . $theme;
        }   
        else {
          $form_state['redirect'] = 'admin/structure/block/add/custom_block:' . $block->uuid->value . '/' . \Drupal::config('system.theme')-          >get('default');
        }

+++ b/core/modules/block/custom_block/lib/Drupal/custom_block/Controller/CustomBlockController.php
@@ -106,6 +106,7 @@ public function addForm(CustomBlockTypeInterface $custom_block_type, Request $re
     if (($theme = $request->attributes->get('theme')) && in_array($theme, array_keys(list_themes()))) {
+      throw new \Exception('Betcha this code will never fire!');
       // We have navigated to this page from the block library and will keep track
       // of the theme for redirecting the user to the configuration page for the
       // newly created block in the given theme.
       $block->setTheme($theme);
     }

If we try to do something like block/add?theme=bartik, that breaks drupal_get_desintation (which is insane, btw).

So I don't have any obvious solutions on how to track the theme name from page to page...

We discussed this in irc and decided not to use drupal_get_destination

Okay, here we go!
We can't use a proper local action because we need a query string, so we fake it.
CustomBlockController::addForm() now checks $request->query
seven_custom_block_add_list() is not outright removed yet, but it is brought into line with template_preprocess_custom_block_add_list().

+++ b/core/modules/simpletest/lib/Drupal/simpletest/WebTestBase.php
@@ -2377,7 +2377,11 @@ protected function assertUrl($path, array $options = array(), $message = '', $gr
+    // Paths in query strings can be encoded or decoded with no functional
+    // difference, decode them for comparison purposes.
+    $actual_url = urldecode($this->getUrl());
+    $expected_url = urldecode($this->container->get('url_generator')->generateFromPath($path, $options));
+    return $this->assertEqual($actual_url, $expected_url, $message, $group);

By the way, I have this hunk in about 3 different issues, I've been doing a lot with query strings lately :) It's in #2083877: Add a theme selector to the place block form which is RTBC

That went in.

Thanks @timplunkett for resolving this

#2074037: Add drupalPostUrl() — drupalPost()/drupalPostAjax() are for forms only, D8 JS performs non-form HTTP requests is going to break everything.

Updated issue summary.

Committed and pushed to 8.x. Thanks!

Thank you!

If anyone is having this issue in Drupal 9, you can do this:

use Drupal\Core\Form\FormStateInterface;
use Drupal\Core\Url;

/**
 * Implements hook_form_alter().
 *
 * Redirects any 'Add custom block' event here: /admin/structure/block/block-content.
 */
function module_name_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  $custom_blocks = [
    'block_content_xxxx_form',
    'block_content_xxx_1_content_form',
  ];
  if (in_array($form_id, $custom_blocks)) {
    $form['actions']['submit']['#submit'][] = 'module_name_block_list_form_submit';
  }
}

function module_name_block_list_form_submit($form, FormStateInterface $form_state) {
  $url = Url::fromRoute('entity.block_content.collection');
  $form_state->setRedirectUrl($url);
}

I still get this inconsistent behavior in 9.5.5. Adding a submit handler like in comment #28 worked for me.