imageapi_optimize can not correctly process image_imageapi_optimize_get_info

I can not confirm this issue, I have not seen it personally.

Can you please try the latest dev version and let me know if the issue is still there, and if so, anything additional about your setup you can provide would be greatly appreciated.

Cheers,
Deciphered.

Hi, I've just reproduced the same error. I'm using latest -dev version on Drupal 7.23.

FiNeX,

How about you provide the steps on how you reproduced the same error so I might actually be able to see it and fix it?

Forgive me for sounding snarky, but as helpful as it is backing up an issue, it's 100 time more helpful actually providing information that helps the developers resolve the issue.

I would greatly appreciate any information you can give that helps resolve this issue.

Cheers,
Deciphered.

Well, the bug is reproducible using both internal tools and the remote service (Yahoo! smush.it).
I'm using a public (and writable) file system and GD2 toolkit method is working fine. Source files are JPGs and PNGs. PHP memory limit is set on 256M and I've enabled "transliteration" module. I'm using Apache 2.2.16, PHP 5.3.3 with APC enabled (I didn't try to disable it).

... after doing some test I've discovered that the Temporary directory file system settings (/tmp), even if writable, doesn't work.

By configuring a relative path on the Temporary directory file system settings the problem disappeared.

Probably imageapi_optimize doesn't handle absolute paths, or the server configuration doesn't allow php to go out from the base directory. In the second case it should be displayed a warning on the File System settings.

Would you like to confirm?

Thanks :-)

Well, I confirm the bug by myself, the problem is always reproducible.

Hi,

Sorry I haven't got back to this issue, but I specifically got involved with this project for a client, and that clients work has long since been completed and I don't currently have a lot of time.

Unfortunately that is the nature of opensource, it's a scratch your own itch system. I had requirements for this module which could benefit the community, I scratched those itches and I moved on to my next itch.

I never personally saw this issue and therefore it wasn't an itch. I would recommend digging around in the code and trying to figure out what's going on, as having an itch is the best way to learn.

Sorry if this doesn't help you, but I can't currently do more.

@Deciphered: I know very well how opensource works, don't worry.

If I (or someone else) will create a patch will you be available to review/commit?

Thanks for your feedback :-)

P.S: if you're not working anymore on this module you should update the "Maintenance status" on the project page ;-)

Same here.

I changed my temporary directory url from sites/etc/etc

to start at the root of the server.

/home/****/public_html/****/sites/etc/etc

The errors went away.

I was using /tmp and it still gave me the error

I just double checked and you are right, the errors are still there. :(

#7 this module is actively maintained. We have two maintainers who follow the issue queue. If there are RTBC patches, they will be soon committed. However in this case, there is no clear thing about how to reproduce the bug. Nothing can be done here.

Seeing the same error here, and using a path relative to my site root (as suggested in #4) fixes the issue. Unfortunately I can't use the module in production unless I can get an absolute path working somehow. Will post a patch if I can figure it out.

I'm using Drupal 7.24, imageapi_optimize 7.x-1.0, PHP 5.3.28, Ubuntu 10.04.4 LTS

EDIT: Switched to the latest dev (2-14-2014) and this error isn't coming up. Thanks!

Mark as fixed even there is only one confirmation at #13. If anyone still encounters the problem with the dev version, then please reopen.

I just updated to the latest dev on Feb 24th. I'm only having the issue when using the image resize module.
I can confirm changing the tmp location to a location inside the root of the website fixes the issues.
If anyone else is using the image resize module this is a quick fix to shut off image optimize toolkit.

http://drupalcode.org/project/image_resize_filter.git/blob/e5d2b431bd0c0...
Comment out Line 514 $res = image_load($image['local_path']);
and add the following:

$base_image_toolkit_selected = (module_exists('imageapi_optimize')) ? variable_get('imageapi_optimize_toolkit', 'gd') : FALSE;
$res = image_load($image['local_path'],$base_image_toolkit_selected);

That just checks if you have the image optimize module enabled. If so it tells image resize filter to use whatever toolkit you told image optimize to use.

I've never had any issues with normal file fields regarding the tmp directory. It only breaks with image resize filter.

Based on #15 it seems that ImageAPI Optimize does not implement an image_imageapi_optimize_load function. But this function is indeed already present. So I don't understand.

Maybe it is because you haven't chosen the toolkit to use?

I've attached a screen shot to show the settings.
This module works fine when rendering normal image fields.
It seems to be related to the tmp directory issue. Since image resize filter works fine if I change the tmp directory to be inside drupal root.
If I want to keep the tmp directory set to /tmp I needed to change the code in image resize filter.

I'm not sure if normal core image fields use the tmp directory differently than the image resize filter.

Before I changed the image resize filter module I was getting these 2 errors when trying to view the page that was using an image that needed to be resized.

The selected image handling toolkit imageapi_optimize can not correctly process image_imageapi_optimize_get_info.

Recoverable fatal error: Argument 1 passed to image_resize() must be an instance of stdClass, boolean given, called in /***/sites/all/modules/image_resize_filter/image_resize_filter.module on line 517 and defined in image_resize() (line 279 of /***/includes/image.inc).

If I had to guess image_load is not returning anything due to the weird tmp directory issue.
http://drupal.stackexchange.com/questions/7082/use-image-scale-and-crop-...

I had the same problem and decided to dig a little deeper.

It turned out that no default methods (get_info, resize, crop, ...) were returned from _imageapi_optimize_get_methods() because the image_gd_... functions were not present when doing the get_defined_functions() callback. This is because the imageapi_optimize module does its stuff and runs its hook too early, being before any of the Base toolkit that it relies upon (in my case GD) loads its stuff. I guess this is what the image_get_available_toolkits() function call should prevent, but that doesn't seem to work.

There is really no out-of-the-box way of controlling this, Drupal just decides on its own in which order things are run. So if you're not having this problem it is because you are in luck and Drupal decided to run the core image functions before the Imageapi module.
You can however influence this order by manually altering the weight of modules in the system table in the database. Or you could implement an update hook doing it for you, this is what I have done in the attached patch.

However this only seems like a temporary fix to me. I believe it would be better to find a more solid way of getting the defined methods, preferably one that doesn't include listing every possible function and using php's eval() function.

EDIT: It seems to me the only functions that you'd need to create a wrapper for are the ones listed here: https://api.drupal.org/api/drupal/includes%21image.inc/function/calls/im..., the ones that will be called by image_toolkit_invoke. Why not just create those functions (e.g. image_imageapi_optimize_crop etc) and drop them in the .module file? Seems way more sturdy and light-weight than listing all functions, seeing if any of them might be image toolkit functions and then including your wrapper functions in hook_init through eval().

#18 sounds like an interesting find, but I still don't have time to test. Instead of forcing module weight, you can you hook_module_implements_alter() to change invoke order of a hook. It is still weird, because in _imageapi_optimize_get_methods() we call image_get_available_toolkits() to load all toolkits before calling get_defined_functions(). Maybe we need some tuning here?

About manually put all image effects in the .module file (and avoid those problems + ugly eval()s): it was the case, but then it won't work with dozens of contrib modules that add effects into the GD toolkit, so we changed it (in this commit).

It is indeed weird because system_image_toolkit() runs this line specifically include_once DRUPAL_ROOT . '/' . drupal_get_path('module', 'system') . '/' . 'image.gd.inc';, should take care of loading all the methods. Either way, with the weight update it works for me, maybe someone else can test this and report back here?

About listing the methods/wrapper functions "hardcoded" in the .module file: it just dawned on my that, indeed, this would be a very rigid approach as we'd need to find out every invocation of image_toolkit_invoke(), and keep an eye on other modules as they implement new invocations.
I guess neither solution is a particularly pretty one.

1. +++ b/imageapi_optimize.install
   @@ -37,3 +37,12 @@ function imageapi_optimize_update_7000() {
   + * Update weight of ImageApi
   

   Modules name is ImageAPI Optimize

2. +++ b/imageapi_optimize.install
   @@ -37,3 +37,12 @@ function imageapi_optimize_update_7000() {
   +  db_query("UPDATE {system} SET weight = 100 WHERE name = 'imageapi_optimize'");
   

   In Drupal 7 you should be using db_update() instead of db_query() here.

I commented in #13 that the dev version solved the issue for me, but I soon discovered after enabling it on our prod site that the error was still coming up sometimes. When it did work, though, the performance improvement was great.

Anyways, I can help test the patch. Here it is with the edits suggested in #21.

I applied the patch from #22 and ran drush updatedb. It is still throwing the same error when trying to use image resize filter.
The code change I posted #15 is still needed for the image resize filter module or it will throw an error when trying to save the node.

Right, so I arrived at this issue because of the db_insert error, but this might be a separate problem resulting in the same error. Let me know if I should raise a new issue for it and attach the patch there.

Basically my problem is that the curl call to smush.it times out, leading to an empty $json object, which isn't tested for, leading to errors. Simply adding a test for an empty $json object lets us fall back to the default image.

Hi Carl,

Thanks for getting involved, but based on the patch and a quick skim over your text it appears this is a completely different issue. The problem is that now the latest patch in no way relates to the primary issue that was originally opened which will cause confusion for those who come to this issue with the original problem.

In future, can you be sure to open a new issue? And if possible, please remove your previous comment.

Cheers,
Deciphered.

Just wanted to confirm that setting the module weight to 100 and flushing caches got this working for me with an imagemagick/local setup.

I've encountered this issue several times while developing some new functionality for one of our sites. The problem isn't related to module weights, execution orders, etc.

The problem is that hook_init() is invoked as soon as the module is enabled, but before you've chosen your base toolkit. From investigating the issue, I can definitively say than on two different sites after enabling the imageapi_optimize module, the imageapi_optimize:methods cache entry is created but it is an empty array.

I think the cache entry is empty because the imageapi_optimize_toolkit variable is not created until you've visited the image toolkit settings and clicked "save". As this variable is not created when the module is enabled, the _imageapi_optimize_get_methods() function looks for functions with a prefix of "image__" rather than "image_gd_" - hence it doesn't find anything and populates the cache entry with an empty array.

Subsequently, visiting the image toolkit settings, choosing the "imageapi optimize" toolkit, with GD2 as the base (or in my case only) toolkit and the internal tools and saving the settings does not cause the imageapi_optimize:methods cache entry to be rebuilt. So you must clear the cache to trigger the imageapi_optimize:methods cache entry to be rebuilt.

The caching of methods and using eval to dynamically create them seems like a really odd way to deal with just five out of eight methods an image toolkit needs to implement - so the attached patch simply gets rid of all the weird code.

Per #19 we use the eval() for a reason.

Maybe one solution is when the cache is empty (no methods), we rebuild it?

#27 seems to solve the problem for me. @jcisio could you clarify why the evals are needed in regard to #27's solution? #19 didn't really explain it well.

In #19 there is a link to the commit. We have to use eval() because we don't know about actions added by contrib modules (like "overlay" in imagecache_actions). Patch #27 didn't re-add the "overlay" action, or the canvasactions_roundedcorners action etc. The related issue is #852860: Support imageapi actions implemented by other modules.

ah I see. So you may need some kind of hooks api to allow more to be added? Like how views and panels allow plugins to be created?

In D8 they are plugins that can be easily discovered and used. In D7 they are discovered by function_exists(). However the idea here we don't want to manually declare them: neither in other contrib modules (that won't happen) nor in this module. And nothing other than eval() can help that.

In summary, I prefer to keep using eval() if we can fix it in this issue. If we can't, of course we'll have to manually declare most of the image actions -- not necessarily all, but they will be added issue by issue. FWIW I haven't checked how many image actions there are in contrib.

Here's another approach.
I had also the issue that the imageapi_optimize:methods was set but empty.
I've added new conditions in imageapi_optimize_init() to hopefully make a more sensible fallback and rebuild the cache if required.
The cache is rebuild if a base toolkit is configured but $cache->data is empty.

For me this seems fixed in the latest .dev Version. I think a new stable release is very very important, the old version seems quite unusable.

I doubt it, dev hasn't seen an update since 2014-Feb-14. The problem was still there at that point in time.
Also, just because it works for you doesn't mean it works for everybody else. Seems to be one of the tricky parts of this bug.

Okay I'm sorry for my short reply. I just wanted to say that I had this problem before and with the stable NOTHING worked for me AND this bug appeared in log. After using dev the bug appears no more in my logs and everything works fine, so this may be two different pairs of shoes ;) Thanks a lot for clarification!

BTW a new stable release is a good idea. I was waiting too long for it. Maybe with the patch in #33, it looks safe.

Just release a new stable with the last patch.

We just experienced this same error in a Drupal 7 installation with the newly released imageapi_optimize 1.2. It happened about 1-2 weeks after installation – uploading worked before.

I tried clearing the caches (drush cc all), and the error went away: saving uploaded images works again now.

But it still seems to indicate that there can still be some conditions where the cache is incomplete or corrupted. I can't find a way to reproduce this again, so let's hope somebody else (or me later) can shine some light on this. I'll tentatvely reopen this again though ...

Unfortunately I can confirm this.
Fully patched, still seeing this error. I'll try to figure out where it comes from.

I think I found a a cause.
Currently Image Optimize is very polite and just accepts the module order in the hook_init() implementation. This can cause other modules to fire before Image Optimize has registered the image handling functions - and those modules can trigger image functions which will fail.
Attached patch uses two approaches:

1. Set module weight globally to -100
2. Use hook_module_implements_alter() to set imageapi_optimize_init() before all other modules.

There could be another extreme solution, we store the generated functions into a file (temp directory) and include it right when the module file is included.
Or we store methods returned by _imageapi_optimize_get_methods() in a variable and or cache and populate the functions at module file include time right away. I think as soon as the module file is included we should have variable / cache support. hook_init() would be degraded to a fall-back in the case the variable / cache wasn't found.

Oh needs review of course :)

Oh, just figured out that hook_init() definitely is to late. Especially if you've a site that's translatable menu_set_custom_theme() can trigger a whole cascade of functions may leading to a call of image functions.
So as we need the full bootstrap (without using the above mentioned "extreme" approach) I suggest we move from hook_init() to hook_stream_wrappers_alter() which is the very first hook fired in _drupal_bootstrap_full().
Updated patch attached.

And the next update, looks like there are occasions in which hook_stream_wrappers_alter() is invoked twice - seen when using drush updb.
So we need to ensure the functions are just registered once, otherwise we get errors.
Added a static variable to keep track of the state.

Tried the last patch, but it doesn't resolve the error for me.

I've lowered the weight further, now only autoload has a lower weight, but no cookie.

After disabling the module and re-enabling it, it works. Wonder which cache got rebuilt doing that that didn't get rebuilt after a drush cc all...

I have a feed that imports an image using the media and remote_stream_wrapper modules.

I tried patch 46.

Because of the patch, I get an error because these lines recurse until my memory is exhausted

79.3173 194721816 22. call_user_func_array() d7includes/image.inc:97
79.3173 194722464 23. image_imageinfo_cache_get_info() d7/includes/image.inc:97
79.3173 194722568 24. _image_imageinfo_cache_get_details() sites/all/modules/imageinfo_cache/imageinfo_cache.toolkit.inc:28
79.3173 194722616 25. image_toolkit_invoke() sites/all/modules/imageinfo_cache/imageinfo_cache.toolkit.inc:119
79.3173 194723072 26. call_user_func_array() d7/includes/image.inc:97
79.3173 194723448 27. image_imageapi_optimize_get_info() d7/includes/image.inc:97
79.3173 194723712 28. _imageapi_optimize_invoke() sites/all/modules/imageapi_optimize/imageapi_optimize.module(41) : eval()'d code:3

EDIT: Dumb comment.Have you tried any of the patches @socialnicheguru?

For anyone using patch #46, it no longer works as of the 2016-Feb-24 dev release. The commit made for Smush.it (https://www.drupal.org/node/2458453#comment-10889292) requires an installation file update, and the update number (7001) directly conflicts with patch #46. It will cause 500 errors if applied.

I posted a possible workaround for this issue here #2528904-1: Remote_stream_wrapper:The selected image handling toolkit imageapi_optimize can not correctly process image_imageapi_optimize_get_info.

EDIT: I just look a look at the patch in #46 and it seems to be a better solution.

Ran into this issue as well and the workaround in #27 (save the image tooklit settings form and then clear caches) seems to be working. I'll keep an eye out to see if the issue crops up again, and if so, I'll try to do some additional debugging.

The comment #55 is strange, that commit was 2 years ago.

Saving the form and clearing the cache worked for me to.

Here's a re-rolled patch from #46, let's work at getting this into 7.x-1.x.

@SocialNicheGuru further to your review in #49 you must be using the imageinfo cache module too? Looks like we have an incompatibility with that module.

Thank you all SO MUCH!! The patch in #58 finally solved this problem for me. I'm using imageapi_optimize in combination with Imagick toolkit OR GD2 and both work great now.
Without the patch I had this issue and the options below "Choose which optimization service to use" in the admin section were missing.

RTBC +1

@Anybody feel free to actually mark this issue as RTBC :)

Yes, I think we can do this :)

I'll take back my RTBC because it wasn't the finaly solution for my problem in the combination of:

• imageapi_optimize
• imagick

The problem sadly still exists. I have no clue ...

With that patch, I fix it

Patch for core and imageinfo_cache. Fix should be in this module though, to route the function call through to the correct toolkit.

patch for this module

lame that imageapi_optimize_init uses eval... #66 is a no go.

Edit: This makes #66 work

diff --git a/sites/all/modules/imageapi_optimize/imageapi_optimize.module b/sites/all/modules/imageapi_optimize/imageapi_optimize.module
index a9ec9047d..9f4716ef0 100644
--- a/sites/all/modules/imageapi_optimize/imageapi_optimize.module
+++ b/sites/all/modules/imageapi_optimize/imageapi_optimize.module
@@ -31,6 +31,9 @@ function imageapi_optimize_init() {
   }

   foreach ($methods as $method) {
+    if ($method === 'get_info') {
+      continue;
+    }
     eval('function image_imageapi_optimize_' . $method . '($image) {
       $params = array_slice(func_get_args(), 1);
       return _imageapi_optimize_invoke("' . $method . '", $image, $params);

The latest patch looks good and could be the real fix for this long standing issue. Is there anyone still having a D7 install with this bug to confirm that patch?