Convert block_admin_edit() in block.admin.inc to the new form interface

+++ b/core/modules/block/block.admin.incundefined
@@ -54,36 +54,6 @@ function block_admin_add($plugin_id, $theme) {
-  // Get the theme for the page title.
-  $admin_theme = config('system.theme')->get('admin');
-  $themes = list_themes();
-  $theme_key = $entity->get('theme');
-  $theme = $themes[$theme_key];
-  // Use meaningful titles for the main site and administrative themes.
-  $theme_title = $theme->info['name'];
-  if ($theme_key == config('system.theme')->get('default')) {
-    $theme_title = t('!theme (default theme)', array('!theme' => $theme_title));
-  }
-  elseif ($admin_theme && $theme_key == $admin_theme) {
-    $theme_title = t('!theme (administration theme)', array('!theme' => $theme_title));
-  }
-
-  // Get the block label for the page title.
-  drupal_set_title(t("Configure %label block in %theme", array('%label' => $entity->label(), '%theme' => $theme_title)), PASS_THROUGH);

You need to move this to the block entity form controller. As it isn't executed at this moment.

This patch includes conversion of block_admin_edit and also, user/1 was getting access denied while accessing admin/structure/block/manage because of return false if $operation was not view in BlockAccessController.php. This patch corrects access denied issue.

There was /configure in the URL (admin/structure/block/manage/bartik.login), which was removed from the URL after talking with Tim Plunkett.

#10: 1981144-block-admin-edit-controller-10.patch queued for re-testing.

I believe this is blocked on #2006636: menu_contextual_links() will always return a link to the MENU_DEFAULT_LOCAL_TASK, never the parent. The offending links are being generated by contextual links.

Okay, that went in.

#15: block-1981144-15.patch queued for re-testing.

Last one!

+++ b/core/modules/block/lib/Drupal/block/BlockAccessController.phpundefined
@@ -22,7 +22,7 @@ class BlockAccessController extends EntityAccessController {
     // Currently, only view access is implemented.
...
-      return FALSE;
+      return user_access('administer blocks', $account);
     }

So we also have update access now?

@dawehner - can you elaborate this little more?

So we also have update access now?

Currently, only view access is implemented.

This text is not true anymore.

#23: block-1981144-23.patch queued for re-testing.

Here is a reroll.

Patch reroll

This should be possible to fix.

looks good but needs a reroll

reroll!

+++ b/core/modules/block/block.admin.incundefined
@@ -22,6 +22,25 @@ function block_admin_demo($theme = NULL) {
 /**
+ * Page callback: Build the block instance add form.
+ *
+ * @param string $plugin_id
+ *   The plugin ID for the block instance.
+ * @param string $theme
+ *   The name of the theme for the block instance.
+ *
+ * @return array
+ *   The block instance edit form.
+ */
+function block_admin_add($plugin_id, $theme) {
+  $entity = entity_create('block', array(
+    'plugin' => $plugin_id,
+    'theme' => $theme,
+  ));
+  return Drupal::entityManager()->getForm($entity);
+}

This hunk looks unrelated and wrong.

Wow, that was a mistake. Not only did I add back block_admin_add, but I failed to remove block_admin_edit callback!

See interdiff.

Ha!

This issue was RTBC and passing tests on July 1, the beginning of API freeze.

Committed/pushed to 8.x, thanks!

I don't see #6 being discussed anywhere here. I thought the same thing when I saw this in the commitlog. Why is it safe to simply remove all that code?

I've added a follow-up issue related to the default local task that isn't converted and results in a page not found.

#2052019: Fix block configuration default local task to use block_admin_edit route