After upgrading from ver. 2.3 to 2.4. The image browser comes up empty.

hmm, the new 2.4 is working with a view to show the images in the browser. The view is using a relationship to node and then nodeaccess to determine if the users should have access to the image. Maybe this is somehow broken, not sure.

Marking as bug. Needs testing

hmm, the new 2.4 is working with a view to show the images in the browser. The view is using a relationship to node and then nodeaccess to determine if the users should have access to the image. Maybe this is somehow broken, not sure.

Marking as bug. Needs testing

Yes, I have the same bug (with a new install, not updated) and I confirm #1.

# drush @dolp pm-list | grep -i image

# drush @dolp pm-list | grep -i views

Jap, but confirmed. I will word on this.

Ok currently i cant reproduce it. Using a fresh installation, the browser does what it is supposed to: Shows all images of nodes the user has access to.

I need more informations here, there is something else fishy ( there are users in the queue where the browser works fine, so there must be something else )

// Would like to fix this one for 2.5. ASAP, so would be nice to have a quick answer

Hrm so its a permission problem, well i check that.

I'm having a related problem.

Although it worked for a while, now, when I attempt to insert an image the popup window comes up and says it is loading but never finishes. I have to close the window/tab eventually. I wonder if the problem is due to a memory limit. When I attempt to use some other views I get the following error: (Fatal error: Out of memory (allocated 31719424) (tried to allocate 3531787 bytes) in /homepages/23/d199252998/htdocs/drupal-canada/includes/common.inc on line 167)

I know that my webhost 1&1) has insufficient memory (30M) and am considering moving to a host without this limit. Perhaps this is the cause of my hanging inserts.

Had the same problem - browser is empty. I managed to solve it by adding such strings
$options = parent::option_definition();
parent::options_form($form, $form_state);// HERE IS MY ADDITION
to functions
function option_definition()
and
function options_form()
correspondently
in the views/wysiwyg_imageupload_handler_field_image.inc file of the module.
Now these functions look like:

  function option_definition() {
    $options = parent::option_definition();// HERE IS MY ADDITION
    $options = array();
    $options['preset'] = array('default' => TRUE);
    $options['link_for_browser'] = array('default' => FALSE);
    return $options;
  }
  
  function options_form(&$form, &$form_state) {
    parent::options_form($form, $form_state);// HERE IS MY ADDITION
    $presets = imagecache_presets();
    $styles = array();
    foreach ($presets as $preset) {
      // We can use the presetid here (http://drupal.org/node/694188).
      $styles[$preset['presetname']] = t("!preset", array('!preset' => $preset['presetname']));
    }
    $form['preset'] = array(
      '#type' => 'select',
      '#title' => t('User this imagecache preset'),
      '#default_value' =>  $this->options['preset'],
      '#options' => $styles,
    );
    
    $form['link_for_browser'] = array(
      '#type' => 'checkbox',
      '#title' => t('Links images for browser'),
      '#default_value' =>  $this->options['link_for_browser']
    );    
    return $form;
  } 

Вut now I have some absolet form fields in the view options form, though it can be handled by unsetting them like unset($form['some_field'].
This works, but I don't know why are these strings necessary. May be anyone explain or find better solution?

Issue should be fixed in 2.5, fixed several issues.

If you have build any views ontop of the views integration you have to rebuild them, as i changed the option names (namespaced)

The shipped views are already reexported