Adding remote URL in Media Browser fails

Got exactly the same problem on the dev and the beta4 and the dev version.
NB. I am adding the media inside a field collection.

Same here, I hit save and then it opens /admin/content in the tiny little space where the media browser was.

Using media 7.x-1.x

Having the same problem as #3 in both dev and beta4.

The problem seems to be related to remote_stream_wrapper_file_add_form_submit(), check out this paragraph in the end of the function:

  if (drupal_valid_path('file/' . $file->fid . '/edit')) {
    $destination = array('destination' => 'admin/content/file');
    if (isset($_GET['destination'])) {
      $destination = drupal_get_destination();
      unset($_GET['destination']);
    }
    $form_state['redirect'] = array('file/' . $file->fid . '/edit', array('query' => $destination));
  }
  else {
    $form_state['redirect'] = 'admin/content/file';
  }

Same problem, any fix ??

I believe that I upgraded to the 7.x-2.x branch of the media module, and RSW stopped doing this.

7.x-2.x branch of the media module is currently marked unstable, so not really the ideal solution.
Subscribing

Also having this problem. Is this module only designed to work with Media 7.x-2.x?

I think I have a fix here for media 7.x-1.2.

Patch at #10 is great for the media browser, but kills the file/add/remote form.

#10: remote_stream_wrapper-media_browser_submit-1557580-10.patch queued for re-testing.

The patch in #10 is currently working for me.

I am able to:

• create a new node
• click Select Media
• click Remote URL
• paste in the URL of my video
• click Submit to close the select video popup
• click Submit to save my new node

It would be great to have someone else test and confirm, but I'm marking this Reviewed & Tested in hopes it can be committed.

Mile23, can you explain your issue a little better, I don't understand what form you're referring to. Has anyone else had this problem?

Verified: I was also experiencing the problem of viewing the admin page within the Media Browser's window footprint. (Select Media Browser > Remote URL , enter URL, press Submit , can not move forward). Site config is remote_stream_wrapper 7.x-1.0-beta4, media 7.x-1.2 and Drupal 7.14.

I added patch at #10 and I was able to complete the process successfully. My experience is the same as described by Kristi in #13.

@dafeder #14: This module uses the same form for the AJAX-y overlay form as well as a stand-alone form at file/add/remote. See remote_stream_wrapper_menu().

The patch ignores the stand-alone form, causing it to break. That's why all that funky logic was in there.

I don't know enough about the internals of generating the overlay form to be able to fix it or I'd be more constructive.

.

Ahhhh I see. Did not realize that form even existed!

The attached patch fixes the issue following dafeder's approach in #10 while also keeping the standalone form operational.

[edit]Removed comments as that distracts ... media-7.x-1.3 seems so fix just my comment here[/edit]

Patch from #19 breaks my images when the popup closes.

Selecting the same image through the Web tab is ok.

+++ b/remote_stream_wrapper.module
@@ -294,15 +296,20 @@ function remote_stream_wrapper_file_add_form_submit($form, &$form_state) {
+    $form_state['redirect'] = array('media/browser', array('query' => array('render' => 'media-popup', 'fid' => $file->fid)));

Why is this redirect working in the first place? It closes the media popup.

( I would like to have it move to the media/$fid/edit first ... is that possible at all? )

#19 seems to work for me. Media uploads for images are ok.
@clemens.tolboom can you describe what problem you had.

@doublejosh: the images are not rendered when in node edit while adding more images. I'll try this again tomorrow as we start using media-7.x-2.x-unstable7 (I'll try to add some screenshots if possible)

I'm not sure but I guess I have the core token bug as my image has '%3Fitok%3DmrscqK5h' aka '?itok=mrscqK5h' so my remote url images are broken. Removing the itok shows the images.
(Caused by? #1934498: Allow the image style 'itok' token to be suppressed in image derivative URLs)

I'm not using the patch as we upgraded to media-7.x-2.0-unstable7 + file_entity + media_youtube but the popup works.

(does this help?)

#19 works for me too.

#19 seems to be working for me too. Thanks for this :)

Typos

As with a couple of other people, #19 seems to fix this problem.

19: remote_stream_wrapper-media_browser_submit-1557580-19.patch queued for re-testing.

Any word on this? Updating to RC1 breaks this module, and patch #19 fails. The popup won't close and permissions aren't working correctly. Getting access denied for all admins except user 1.

Reverted to beta4 with patch 19 to get working again. Thanks.

I have the same issue using rc1 version.

For me patch #19 applies to RC1 (although 5 lines offset). Both AJAX and stand-alone forms work after the patch. I attach the very same patch fixed for RC1 to apply cleanly. All credit to jamix. Would it be possible to release RC2 with this patch?

Glad I found this thread. Patch #34 seems to fix the problem for me. I've done minimal testing.

Perhaps off-topic, I also had to clean up the cruft that remote_stream_wrapper_media_browser_plugin_info() returns. It places strings into a datastructure where drupal's render expects arrays. I cleaned that up with a custom alter hook:

function CUSTOM_media_browser_plugins_alter(&$plugins) {
  foreach (element_children($plugins) as $k1) {
    foreach (element_children($plugins[$k1]) as $k2) {
      if (!is_array($plugins[$k1][$k2])) {
        unset($plugins[$k1][$k2]);
      }
    }
  }
}

test patch #34 on a clean setup and it really resolves the issue.

I think this is the problem here too. https://www.drupal.org/node/1969280

I'm having this problem too, the module is completely unusable, what do I do to fix it?

This bug is 3 years old and still not fixed O_O !!!!

:@ :@ !!! I will happily fix it and release the next RC, but why do I have to patch in order to solve this when the patch was released 6 months ago... I don't get it, is the module dead? so ridiculous

1. +++ remote_stream_wrapper/remote_stream_wrapper.module	2014-09-16 21:55:39.000000000 +0200
   @@ -251,6 +251,8 @@
   +  $form['#render'] = isset($options['render']) && $options['render'] == 'media-popup' ? 'media-popup' : 'standalone';
   

   Should we be using $form_state instead for storing this value?

2. +++ remote_stream_wrapper/remote_stream_wrapper.module	2014-09-16 21:55:39.000000000 +0200
   @@ -289,15 +291,20 @@
   +  else if ($form['#render'] == 'media-popup') {
   

   Should be elseif

@Dave Reid - what? Do you plan on releasing an updated RC any time soon? It seems as though this is the only solution for embedding external media in the way we need it, yet it doesn't work. I was wondering why there were so little sites reported using this module compared to the total number of downloads.

oook...

@kitzinger - While I can understand your frustration, I suggest that you tone down your responses and cut out the anger, complaints, and sense of entitlement. Posts of this nature will not get you very far in this community.

Dave Reid is maintainer and co-maintainer of dozens of important modules. It is likely that without his efforts your project (whatever it is) would not have the features that it has. Please show some respect and gratitude. And understand that all of the efforts of all module contributors are gifts to you. Please stop bouncing around issues complaining about the gifts people have given you, demanding they give more.

:@ :@ !!! I will happily fix it and release the next RC, but why do I have to patch in order to solve this when the patch was released 6 months ago... I don't get it, is the module dead? so ridiculous

@lunk_rat I really appreciate that, thanks. However, I do absolutely require the functionality this module provides for my project, and therefore would kindly ask you what you think the best solution would be. I need to accomplish this without patching. Could I download this module, fix it, and then just use my modified version for my project? Whats the best thing to do? thanks again

@Dave Reid - My apologies!

@kitzinger - Yes, you can absolutely modify this module with a fix and use the modified version in your project. I'm not sure why this would be preferable to applying a patch to the module, as the end result is essentially the same.

Whenever you make changes to a module or theme, you need to make sure you accommodate your changes in future upgrades and builds of your project, being careful not to overwrite your changes. The best way to do this is to simply create a patch containing your fix and submit it here to be included in a future release of the module! If this is not possible, you can create a sandbox of your modified module, or use GitHub or some other version control solution.

Is there a reason why the patch in #34 is not an option for you?

@lunk_rat - The project I'm working on is for a small business, not a personal project, so I'm concerned that patching is not the right way to go, simply because I won't have access to their website long-term after it is built. I'm worried that once the patch is applied, it will have to be removed at a later date (if the module is updated in the future) and it may stop working correctly if the patch isn't removed. Is my understanding of patches correct or have I misunderstood them? I always thought a patch had to be removed when the module is updated. ?? Thanks for the guidance.

@kitzinger - Just apply the patch. Seems the maintaner is aware of the issue so I'm sure this issue will be fixed in any version that would be updated to later, either by this exact patch or another way.

Downgrading from "Reviewed & Tested by the community" because the latest patch (34) is only going to fully work for you if you're running media 7.x-2.x, which is still alpha. This plugin's hook_media_browser_plugin_info is written for the 2.x API.

Will post another patch shortly in an effort to be compatible with media 7.x-1.x as well.

oh god......

Patch is against 7.x-1.0-rc1, although it's built on the patch in #34.

#52 patch works for me on 7.x-1.0-rc1!

#52 worked for me as well.

Here is a new patch based #52 which fixes 3 whitespace issues as shown when attempting to apply the patch via git:

remote_stream_wrapper-media_browser_submit-1557580-51.patch:21: trailing whitespace.

remote_stream_wrapper-media_browser_submit-1557580-51.patch:23: trailing whitespace.
    $plugins['remote_file'] = array();
remote_stream_wrapper-media_browser_submit-1557580-51.patch:33: trailing whitespace.

Checking patch remote_stream_wrapper.module...
Hunk #1 succeeded at 204 (offset 6 lines).
Hunk #2 succeeded at 269 (offset 6 lines).
Hunk #3 succeeded at 309 (offset 6 lines).
Applied patch remote_stream_wrapper.module cleanly.
warning: 3 lines add whitespace errors.

Please review.