Views uses non-existent "default" view mode, which causes Quick Edit to break

We don't want to hardcode this sort of thing.

IIRC, the actual bug here is either:

1. Views allowing you to select the Default view mode, which is not an actual view mode
2. or Entity API having changed some metadata that causes Views to expose "default" as a view mode, which wasn't the case before

I know I've been on an issue related to this before.

Pinged @tim.plunkett about this.

Also pinged @yched: https://twitter.com/wimleers/status/724635440859516928

It is problematic that Views allows you to use Default as an explicit view mode. However, AFAIK that itself is just a workaround for a deeper issue that you can also face in Quickedit: You can have entity types without any view modes. As view modes are only stored in Config and there is no way to provide them with code, you can get into a state where you have no view modes.

I still find QuickEditController::renderField() buggy, though. It invokes a hook on a non-existing module (i.e. default or full) in case an incorrect view mode is passed, and then returns an empty string as though everything is fine leading to a vanished field.

Yeah conceptually this sounds like a 404 for me. The URL requested a certain view mode, but we could not find it.

So why would it be bad to define a default view_mode as per #7?

Because we're guessing. And assuming 'default' exists for all entity types.

This should be fixed in Views.

Here's a port of the patch from #2952300: Drag-and-drop image uploading in Quick Edit doesn't work on Media fields, only File fields, with test coverage. This is ready for review now.

Since both the fix and test are in quickedit, moving this to that queue. If this turns into something Views specific feel free to move it back.

So this makes it so that quickedit will actually render fields in the 'default' view mode, right? I don't think that is the correct fix. The 'default' view mode was never meant to be an actual view mode, it's just an implementation detail of the UI to facilitate quicker configuration. It has already crept into various places e.g. Views, etc. but I don't think it's wise to continue that pattern. We have #2844203: Improve/Simplify situation around Default/Full view modes/view displays to improve that situation in general, but I don't think it's a good idea to continue in this direction (i.e. to "worsen" the situation from my point of view).

It's quite possible that I'm missing something, maybe we can get @Berdir to comment here, I think he has a much broader picture of the whole situation.

Yeah, I'm conflicted :)

I fully agree with @tstoeckler that default should never be used like that.

The problem is, it is. Even our API's, as this patch shows, return default as a view mode option. And I don't really see how we can get rid of that in 8.x (and I don't even see a way forward so far that is backwards-compatible in some way..).

Given that, it probably makes sense to do this, so that we're doing it consistently wrong ;)

And maybe re-open the other issue or create a new so that media by default does not use the default view mode for rendering?

Given that, it probably makes sense to do this, so that we're doing it consistently wrong ;)

Should we make the consistently wrong thing the new right thing then?

Hi!
I have no idea, how and when it'll be fixed, but until then, here is a patch for 8.7.
Doesn't include tests.

Just confirm that #25 works for me

Patch #25 works for me as well.

Great to see a fix, but we do need a test.

I started to create a test, but couldn't finish it. If someone has time they can finish it.
I’d appreciate any feedback on my current test.

Best Regards Malte

I created a test that basically bases on the approach in #17. Attached is also a test-only patch that's supposed to fail due to the missing fix from #25.

@malte.koelle i did go a different way with my test. Instead of rebuilding the steps in the video, i focused on the quickedit process, that uses the "default" view mode in its requests.

Ok the tests in #30 are failing. For some reason getViewModeOptions was renamed to getViewModesOptions in #29 and i didn't see that. Sorry for that. Here are 2 new patches that hopefully work like they should.

Fixing patch names and the file ending of the interdiff - to give a better overview.

Patch #36 is working for us in resolving the issue #3061101: Quick Edit with Paragraphs: stuck on 'saving'.

Closed #2982359: Quick Edit hides field on save as a duplicate so added it here as related add added the contributors here for credit.

There is a test here but the file name isn't standard, removing the needs test tag. I will start a test against 9.2.x.

1. +++ b/core/modules/quickedit/src/QuickEditController.php
   --- /dev/null
   +++ b/core/modules/quickedit/tests/src/Functional/QuickEditDefaultViewMode.php
   

   File name should be QuickEditDefaultViewModeTest.php

2. +++ b/core/modules/quickedit/tests/src/Functional/QuickEditDefaultViewMode.php
   @@ -0,0 +1,113 @@
   + * Test quick edit does not break if view uses non-existent default view mode
   

   "Tests Quick Edit works when the default view mode does not exist." would be simpler and correct the case of Quick Edit.

3. +++ b/core/modules/quickedit/tests/src/Functional/QuickEditDefaultViewMode.php
   @@ -0,0 +1,113 @@
   +   * Test views does not use a non-existent view mode, to avoid Quick Edit to break
   

   I am having trouble understanding this comment. Is this testing that Quick Edit works when the view does not have a view mode or that the view does not have a non existing view mode?

Rerolled patch #36 for 9.2.x and made the suggested changes in #47 along with some coding standards fixes.

Updated tests for deprecated assert statements , missing test standards and missing code checks in tests.

Updated Coding standards.

The patch at #52 still works for 9.1.x. I'd say RTBC, pending confirmation it works on 9.2.x.

Due to Quickedit being moved out of Drupal Core and into a Contrib Module, moving this issue to the Contrib Module queue.

I confirm the patch in #52 works with Drupal 9.3.

The problem not only affects Views, but basically any entity, because all of them have a Default view mode. For example Paragraphs or Media entities are also affected.

This can be seen by going to any entity's Manage display settings and seeing how all of them have a Default element at the start of the view modes tabs. So yeah I think there's no way to not support a Default view mode.

Although this issue has been moved to the not-in-core-anymore quickedit module, I think it would be nice if it was backported to 9.x, as it's still a bug.

This bug still exists Drupal 9.4.7 version. This patch #52 applied but bug still exist.