Entity browser views that do not have use_ajax explicitly enabled are broken with 8.3.7

Yep, +1

Marked #2903097: AJAX 403 Error with Browser Content using View display as duplicate of this one.

When you apply the patch, go to the view and apply the Use ajax option.

I was affected by this and can confirm that the patch and instruction in #5 worked.

However, doesn't this mean that all the modules that depend on Entity Browser need to update their view configs to include the following line?

display:
  default:
    display_options:
      use_ajax: true

For example, the Media Entity Browser view doesn't come with that line. So I feel that this ticket should be escalated to other projects, but I'm not sure about the procedure there.

Thank you :)
Same question as in comment #6

Confirming this issue, haven't tested the patch.

Answering to the question on #6, yes as Berdir commented in the issue description, all old views must be updated:

> As discussed with @slashrsm, we might want to a) display a clear error upfront in the entity browser instead of the view and/or add an update function to force the flag to enabled for all entity browser displays, might not be trivial.

I was also affected by this and also the instruction in #5 worked. The patch wasn't necessary.

Hi everyone,

I did a patch to update existing views that use entity_browser plugin in order to save them with use_ajax to TRUE.
It should solve reload problems on entity browser views. It worked for me, I hope it will resolve the problem for you either :)

Hi @phjou
Looks like you do not need the

$update_needed = FALSE;

Do we need to post an issue in the media_entity_browser queue as well? Does that need a similar patch?

Indeed, I changed the code and forget to remove that variable.
I've just removed the line.

I don't think it's necessary to use a queue because I doubt that a website has so many views with entity_browser plugin.

#16 Working for me. Thanks

Sorry @drupalninja99, I haven't read correctly your comment.
Indeed I think it could be usefull to do a patch in order to set use_ajax to TRUE into the views export.

But it also affects every module that uses an entity browser views. I've checked file_browser and they have exported "use_ajax" to TRUE which is not the case for entity_media_browser.

Thanks @phjou!

Tested, this fixes the issue.

#16 is working for for existing views, but when you create a new view after the update the problem still persists.

Hi I have custom media solution and when perform any ajax based operation i.e. search items by name. Logs gives access denied with message

/views/ajax?uuid=ca31ea2117de4e5ed6dfbjuy68484766357d7e9377&original_path=/node/add/page&_wrapper_format=drupal_ajax

It get fix after applying patch :)

So this is a core bug, right? The 8.3.7 SA change

https://github.com/drupal/drupal/commit/65cef2e9f5c37c7b0d1b70627779bd47...

should use ajaxEnabled() rather than looking at the checkbox on the display?

@ahebrank This issue is linked to many problems.
The original problem is that the views used by entity browser should have use_ajax set to TRUE.
That implies that:
- Every module that provides an entity browser view sould set use_ajax to TRUE into the export.
- Existing views should be updated to use_ajax to TRUE

The problem could not be "visible" if the core used his ajaxEnabled API but I think it's better to set use_ajax to TRUE in order to avoid future problems if the call to ajaxEnabled is broken like it is now. Indeed, the call to ajaxEnabled should be done but it is another issue. Maybe someone has created it...

In the Views source use of ajaxEnabled() is consistent for determining functionality of a View and getOption('use_ajax') is only used for form defaults... EXCEPT for the 8.3.7 SA patch. I think patching core to follow the API is a much cleaner fix here, so I'll open an issue over there.

If it's helpful to anyone, I've been patching projects today with https://gist.githubusercontent.com/ahebrank/70b98af2f4df3c66c432046ec155...

#30 makes sense to me and indeed solves the problem!

I looked into the test failures and they're the same as the branch failures - I believe that when Paragraphs releases again these will be resolved, as #2881459: Build failing: Schema errors for field.field.node.paragraphed_content_demo.field_paragraphs_demo with the following errors: field.field.node.paragraphed_content_demo.field_paragraphs_demo:settings.handler_settings.target_bundles is not included in the latest release. There's nothing we can do to fix Paragraphs schema in Entity Browser.

Putting back into needs review.

@berdir Confirming this issue. Your suggestion in #2 above fixed it for me. +1

Is there an issue to follow yet for the core fix?

Adding the link to the core issue.

Adding in @berdir's suggestion in #30.

Agreed, it would be great to get a new release with the fix - we ran into this also (on multiple sites).

However, the patch in #37 has wrong paths so it does not apply. Here is a re-roll.

+1 RTBC for #39.

Committed. Thanks!

Thank you so much for this patch!!!

Hi everybody, with this bug, you can enable Always show the master (default) display in tab settings of Views, after that you back to the views not working ajax, and set view allow ajax in master display and save this views, all display in this views will update allow ajax.
I did it, and my Entity browser is working.

#46 worked for me. Thanks

Deleted. Not applicable.

I came across this issue because I found a note in the codebase to update Drupal\entity_browser\Plugin\views\display\EntityBrowser::getOption when a core issue landed. I checked and it has landed:

#3044021: Remove EntityBrowser::getOption