4.7 image.imagemagick.inc was reverted to 4.6

I replaced form_textfield in an attempt to make it 4.7 compatible, but it still doesn't work for me. The attached patch includes changes from issue 29528.

The problem is that the new form API isn't letting the imagemagick.inc file's toolkit settings display in the system.module image handling box. In fact, it isn't even calling it at all. I had to a.) move my image.imagemagick.inc file into my root /includes directory and b.) hack my system.module file so that the image handling area read as:

  // Image handling:
  $toolkits_available = image_get_available_toolkits();
  if (count($toolkits_available) > 1) {
    $form['image'] = array('#type' => 'fieldset', '#title' => t('Image handling'), '#collapsible' => TRUE, '#collapsed' => true);
    $form['image']['image_toolkit'] = array(
      '#type' => 'radios', '#title' => t('Select an image processing toolkit'),
      '#default_value' => variable_get('image_toolkit', image_get_toolkit()), '#options' => $toolkits_available
    );
	$form['image']['image_imagemagick_convert'] = array(
		'#type' => 'textfield',
		'#title' => t('Location of the "convert" binary'),
		'#default_value' => variable_get('image_imagemagick_convert', '/usr/bin/convert'),
		'#size' => 64,
		'#maxlength' => 64,
	  );
	$convert_file = variable_get('image_imagemagick_convert', '/usr/bin/convert');
	if (!file_exists($convert_file)) {
		form_set_error('image_imagemagick_convert', t('%file does not exist or is not executable.', array('%file' => "<em>".$convert_file."</em>")));
		}	  
	}

It wasn't pretty, but it seems to have worked. There's got to be a better method of dealing with this, though.

I created a patch from your changes, but it did not work for me. Even though I can use /usr/bin/convert from the command line, Drupal claimed that it did not exist or was not executable.

Changing the convert install path may not be sufficient:
http://drupal.org/node/66311#comment-144309

Suggestions?

I have tested different paths in the "Location of the convert binary" field, and every time I submit a new path I get the message, "/usr/bin/convert does not exist or is not executable. The settings have not been saved because of the errors." The system module is testing not the newly submitted path but the old path. I haven't had time to find out how to make it test the submitted path.

It turns out that my problem was caused by my hosting provider's server configuration. PHP was not able to access the directory where the ImageMagick binary was located. Linking to the binary from other directories didn't work because PHP resolves all symbolic links.

To determine if the problem is caused by your hosting provider, look in the log for this message after trying to set the ImageMagick path:

file_exists() [function.file-exists]: open_basedir restriction in effect. File(/home/darrenoh/convert) is not within the allowed path(s): (/home/darrenoh/:/usr/lib/php:/usr/local/lib/php:/tmp) in /home/darrenoh/public_html/includes/image.imagemagick.inc on line 69.

After my hosting provider modified the server configuration, I was able to test this patch successfully and can confirm that it is ready to be committed.

Moving back to image.module

This patch adds a textbox designating the location of the convert binary to image settings when the imagemagick toolkit is selected.

It works by updating image_imagemagick_settings to use fapi and by calling in to those settings during image.module's settings hook:

  $image_toolkit_settings = 'image_' . image_get_toolkit() . '_settings';
  if (function_exists($image_toolkit_settings)) {
    $form = array_merge($form, $image_toolkit_settings());
  }

This patch makes sense and works great when ImageMagick is selected; but, when it isn't selected, I can't open the image settings page. While the page is trying to open, the following message is stored in the error log, over and over again:

array_shift() [function.array-shift]: The argument should be an array in /home/darrenoh/public_html/includes/form.inc on line 473.

After modifying the third line of code in comment #9, it works:

if (is_array($image_toolkit_settings()) && function_exists($image_toolkit_settings)) {

I don't like the usage of $_POST in this patch... Also - the intention is to have the setting on admin/settings, since image.module is not the only place where the image.inc / toolkit is used.

Then the patch you want is in comment #3. Killes rejected it because it modified the system module. If we are not allowed to modify the system module, the patch in comment #11 may be our only solution.

Here's what happened the "location of convert binary" field. It was never updated to work with Drupal 4.7. As a result, it caused errors on the system settings page. See issue 50078.

In order to get image toolkit selection to work, image_toolkit_invoke('settings') was removed from system.module by CVS commit 26667.

So the solution is to update image.imagemagick.inc for Drupal 4.7 and then pursuade the Drupal maintainers to restore image_toolkit_invoke('settings') to system.module.

I have attached a patch here to take care of the Image project side of things. See issue 99160 for the system.module patch.

New patch includes update for form validation.

I learned a little more about the validate element. Corrected patch attached.

Darren : it looks like your latest patch no longer includes UI for the settings? I recognize the core issue... and if killes says no, then we need to resort to adding the UI on admin/settings/image. Can you add this to your patch?

thanks!

Image toolkit settings have been restored to Drupal core.

great. thanks darren !

I've applied the patch but I have the following problem. My path to the convert reads something like
/kunden/homepages/18/d12345678/htdocs/newSiteDevelopment/ImageMagick-6.2.9/utilities/convert
If I add this as the location to the new version of the image.imagemagick.inc the string gets cut off somewhere in the middle and obviously I get the error message that 'convert does not exist or is not executable'. With the last version I didn't have a problem.
xl

changed '#maxlength' => to 128 and now it works.
xl

Opened issue 109188 to deal with the bug reported by Axel_V.

This fix needs to be ported to the 4.7 branch, where the issue originally appeared. This was done once, but for some reason the fix was reversed in CVS commit 47484.

Tagged issue 108157 as a duplicate of this issue.

I just downloaded the latest image.imagemagick.inc for drupal 4.7...

// $Id: image.imagemagick.inc,v 1.2.2.2 2006/12/08 15:18:26 walkah Exp $

however, it appears as if this utilizes a "form_textfield" that is undefined in 4.7 on line 22 "Call to undefined function on line 22"

Thanks for all your hard work!

Blessings,
Albert
www.ithou.org

form_textfield is a relic of Drupal 4.6. It appears that the fix has been completely reversed.

committed. sorry about the bad commit guys. fixed now. thanks darren!