Imagecache settings should be uploadimage settings.

Well in BETA4 i included 2 imagecache preset which are presets, but programmatically added (big, original). Do you mean them

Fixed in BETA5

The code here seems to have a logical error.

Eg:

1) If no presets, then the module adds two

2) The user uses the presets provided by the module

3) The user / module creates a preset

4) The system flushes the presets, the original / big presets disappear

5) The presets used by the user already are now invalid

Workarounds

a) Make the special case that there may be one option that uses the original image.

OR

b) Create one (or more) presets that are always available

Cheers

Hello Alan,

well thats a good point. My idea was to make the installation easier and work OOTB. But seeing your case, i have only 2 options.

1. Creating presets which stay in the system (that could most likely anoy people)
2. Not creating those at all. So one part of the wyswyg_imageupload installation is creating those presets

I really tend to case 2 seeing your valid point. What do you think?

Well actually there is not much to decide. The case of "not deleteable presets" is just to anoying. I guess there is a hack, using a submodule for this, which users can deactivate by need but still those presets get invalid afterwards. So i better remove them and update the configuration guide.

Fixed in rc2

Same feeling here. It just requires a simple check on the preset count on the selection form, something like:

<?php
Index: wysiwyg_imageupload.form.inc
===================================================================
RCS file: /cvs/drupal-contrib/contributions/modules/wysiwyg_imageupload/Attic/wysiwyg_imageupload.form.inc,v
retrieving revision 1.1.2.5
diff -u -r1.1.2.5 wysiwyg_imageupload.form.inc
--- wysiwyg_imageupload.form.inc	26 Jan 2010 01:46:20 -0000	1.1.2.5
+++ wysiwyg_imageupload.form.inc	30 Jan 2010 10:49:41 -0000
@@ -78,7 +78,8 @@
       '#type' => 'select',
       '#title' => t('Size'),
       '#options' => $styles,
      '#default_value' => $defaults['preset']
+      '#access' => count($styles),
     );
   }
?>

Cheers

Well wont be only that, also the JS part needs to no that "no preset" is possible. In addition, the show ajax handler should be aware of this alternative also.

Hi Eugen

I had a similar imagecache catch-22 on another project, and I think that I have a reasonable workaround. It is a bit more complex than you probably need, but hopefully it may give you some alternative ideas. I'm not sure how far back the schema goes, but it is working fine on my local install with up to date image modules.

Cheers

Alan

<?php
/**
 * Test the existence of a preset, and creates one if it doesn't exist.
 * @param $presetname string
 *  The ImageCache preset name.
 * @param $target string
 *  The section settings, e.g. 'gallery' or 'listing'.
 * @return $presetname string
 */
function userphotos_check_preset($presetname, $target) {
  $presets = imagecache_presets();
  // Use supplied preset if possible.
  if(isset($presets[$presetname])) {
    return $presetname;
  }
  // First fallback, use a preset based on the target.
  // This avoids creating unnecessary presets.
  if (isset($presets[$target])) {
    $presetname = $target;
  }
  else {
    // Second callback, use the supplied preset name (e.g. an old deleted preset)
    // or failing that, the target.
    $presetname = empty($presetname) ? $target : $presetname;
    $preset = array('presetname' => $presetname);
    drupal_write_record('imagecache_preset', $preset);
    $action = array(
      'presetid' => $preset['presetid'],
      'weight' => 0,
      'module' => 'imagecache',
      'action' => 'imagecache_scale',
      'data' => array(
        'width' => '150',
        'height' => '150',
        'upscale' => 0));
    drupal_write_record('imagecache_action', $action);
    // Flush preset cache.
    imagecache_presets(TRUE);
  }
  // Update the settings to reflect the (potentially) new preset.
  $settings = _userphotos_settings($target);
  $settings['preset'] = $presetname;
  variable_set('userphotos_'. $target, $settings);
  return $presetname;
}

?>

Well Alan, i will not find the time to look into this right now, especially as we have a feature-freeze for 6--1-0 anyway due the release canditate.
Anyway i reopen this as a feature request, any patches and especially tests are much appriated.

Thanks for the investigation Alan

Well marking as wontfix. Creating a preset at minimum is a installation-step now. You can select presets you want to use since 1.3 in addition.