Fix routing for admin/content.

[queenvictoria]

On an existing project, when I use file entity with Drupal 8.0.1, I get a WSOD at admin/content. Adding this route corrects the issue.

[Berdir]

Sounds like you're missing the file_entity view?

I know this is a problem, not sure what the best fix is. It uses the default entity list builder, so trying to actually use that will result in a completely useless page. I'd rather go for defining the local task dynamically, similar to what we did in our past module: https://www.drupal.org/node/2614124

[queenvictoria]

I can see the View in the config/install path but as far as I can tell it's merging with the underlying core/file/config/install View. This path also gives a WSOD (after fixing admin/content admin/content/files has WSOD). I was going to post a separate patch for that when I figure out how to fix it.

Is it the routing that you think should be removed? I've looked at the past db patch. Looks like it removes the routing, removes the path from the View, and adds a tab to the View. Is that correct? Still looks like the View itself it broken.

The error I get on that is that created is not in the GROUP BY statement. If I remove the default sort on the table (created) it works well. The only columns that actually sort without throwing a similar error are type and name.

If I remove the field usage and the relationship everything works well.

I notice only type and name have src/Plugin/views/field classes. It's the only thing that I can see that they have in common that the other columns don't share.

[Berdir]

The trick is only adding the local task if the view is present in the system. That's done in the new code added in that page.

Errors on the views sounds like a different problem, but I don't really see why that should fail just for you, are you using postgresql? But even then, mysql strict should behave the same.

[queenvictoria]

Ok cool that's what I thought it did.

The errors I am chasing down. I'm not using postgres but the error does seem to be about an SQL strict standard that is stronger than the one used when I run the query manually. Also I've discovered that if I enable aggregation on the file_entity_files View then everything works. It just doesn't install that way. I'm trying to locate the differences between a good .yml export of the View and the config/install View. Too many differences though. And the critical line (group_by: true) is set properly in config/install.

[queenvictoria]

PS I'm still having the same issue. I'm building the site from my install profile. Does that give any clues?