Editing a config entity from a listing page results in a 'page not found'

Tagging

I confirm, today installed drupal 8, and has the same problem.

Tackling

Fail then pass

this is definitely critical

Various things are also getting fixed in #1983548: Convert contact message entities to the new Entity Field API, including at least the manage fields/display, without test coverage for that though. contact.module is hopelessly broken right now ;)

relevant #1938386-17: Convert contact_category_* pages to a new-style Controller

Okay this issue does not affect just contacts it also affects roles. The issue is a direct result of #1995620: [policy, no patch] Document how to handle routes for MENU_DEFAULT_LOCAL_TASK.

Totally different patch to #4

And we obviously have absolutely no tests for this in atm...

Thanks, will combine your fix with my tests asap

#8 was 100% the right fix.

I was overriding this as I went in my conversions, not sure what happened with contact.
Menu was #2019735: operatuins typo in MenuListController.php, closing that.

Here's the fix from #8, the test from #4, and my fixes and clean-ups.
We should really go through and change more of these web tests to use clickLink().

Contact categories are not fieldable, so they shouldn't have provided links to Field UI code.
#1983548: Convert contact message entities to the new Entity Field API seems like it might change that, but that can be done there.

Unlike all other config entities, the default task for Vocabulary is listing, and /edit is a local task.

I just broke shortcuts, so maybe we need tests after all.

Contact messages are fieldable, that's what the links were for.

Fixed shortcut, added a test there too.

Could have sworn I fixed that one.

Just realized I was fixing many of the same bugs in #2006348: Remove default/fallback entity form operation, so postponing that.

+++ b/core/modules/contact/lib/Drupal/contact/CategoryListController.phpundefined
@@ -19,22 +19,6 @@ class CategoryListController extends ConfigEntityListController {
-    if (module_exists('field_ui')) {
-      $uri = $entity->uri();
-      $operations['manage-fields'] = array(
-        'title' => t('Manage fields'),
-        'href' => $uri['path'] . '/fields',
-        'options' => $uri['options'],
-        'weight' => 11,
-      );
-      $operations['manage-display'] = array(
-        'title' => t('Manage display'),
-        'href' => $uri['path'] . '/display',
-        'options' => $uri['options'],
-        'weight' => 12,
-      );
-    }

that was fun:) config entities dont have fields, i always wondered why contact categories had the manage fields link in the dropbutton:P
thanks for restoring some sanity there:)

+++ b/core/modules/contact/lib/Drupal/contact/Tests/ContactSitewideTest.phpundefined
@@ -189,6 +192,20 @@ function testSiteWideContact() {
+    $this->addCategory($name = drupal_strtolower($this->randomName(16)), $label = $this->randomName(16), implode(',', array(
+      $recipients[0],
+      $recipients[1],
+      $recipients[2]
+    )), '', FALSE);

this could be cleaner, also i cant see where you use the $name after that

well, there, lets make it beautiful:P

random failure #2017217: Random failure on UserPasswordResetTest

#23: config-list-2010290-23.patch queued for re-testing.

Contact Message entities are fieldable, that hunk needs to go back in

That hunk was in CategoryListController. Which is used by \Drupal\contact\Plugin\Core\Entity\Category. Also, it doesn't work.
\Drupal\contact\Plugin\Core\Entity\Message doesn't specify a list controller.
Neither of them specify a route_base_path.

Back to RTBC before the random fail.

Aren't Contact messages content entities?
The route base path missing was part of the earlier fix and test.
Happy to be wrong here

#1825044: Turn contact form submissions into full-blown Contact Message entities, without storage

seems we are confused with categories and messages:)
Contact messages are fieldable, Contact categories are not

CategoryListController::getOperations()

It gets passed an $entity which is a CategoryInterface.

    $uri = $entity->uri();
    $operations['manage-fields'] = array(
      'title' => t('Manage fields'),
      'href' => $uri['path'] . '/fields',
      'options' => $uri['options'],
      'weight' => 11,
    );

That is a 404, since categories are not fieldable, \Drupal\field_ui\Routing\RouteSubscriber doesn't provide a route for them.

Message is a fieldable entity, but it does not provide a route_base_path, so it also is ignored by Field UI.

Okay, so what happened here was @larowlan was trying to fix contact.module.

His initial patch had a bunch of fixes, like adding route_base_path.

I missed that completely when I was pinged by @alexpott to look at this, and went off of #8, which was a more generic bug.

So yes, Contact Messages are supposed to be fieldable, and this whole confusion now make sense.
But we've polluted the issue with a generic fix for a separate bug.

We can split one off, not sure if anyone cares which one.

Committed 096b8c5 and pushed to 8.x. Thanks!

A bit confused that the patch was now committed :)

As @larowlan said above, contact messages *are* fieldable, it's just the field UI integration that's broken (together with various other things), so there's no reason to remove those links, they should simply be fixed.

I already partially fixed it in #1983548: Convert contact message entities to the new Entity Field API, should I merge the non-committed things from here into my patch there, including test coverage?

@Berdir, larowlan said he'd file a new issue for the previous fix/tests, but rolling that into the above issue could be okay too.