Hello, first of all I really like your module. Before I had hardcoded some IM post effects, suffice to say it wasn't pretty!

However, there's a really weird an for me critical bug, which causes IM RAW to completely disappear from Imagecache (option to add IM RAW actions gone, existing IM RAW actions gone). Worse, all images are displayed without IM RAW processing, which means that in my online shop, all pics are displayed in their original upload size (imagine thumbnails suddenly 1280x1024)!

So far I've managed to solve the problem by disabling the module, re-enabling it and flushing all affected Imagecache presets. Unfortunately, I wasn't able to further track down the cause.

Thanks & cheers

CommentFileSizeAuthor
#9 im_raw.patch716 bytesaccount-deletion-needed

Comments

account-deletion-needed’s picture

Forgot to mention that disabling and re-enabling the module makes IM RAW and all of its actions re-appear in Imagecache.

adrinux’s picture

Assigned: Unassigned » adrinux
Status: Active » Postponed (maintainer needs more info)

Hi, I just hit the same problem on a drupal-5 install a couple of days ago, and after a couple of hours came up with the same solution. Disable module, re-enable module, flush preset.

It became obvious when I added a new image, because of the cache it stays hidden until then.

I'm also clueless as to why it happened, I assume it happened after an imagecache module update, but why imagecache was suddenly unable to see the module and register the action I don't know. It was definitely still enabled.

Odd.

Setting this to active (needs more info) for now.

account-deletion-needed’s picture

Priority: Normal » Critical

Changing this to critical as it's a site breaking bug for production pages.

adrinux’s picture

Drama queen :P

Without some idea of why it happened, and whether it's going to happen again, changing the priority is moot.

account-deletion-needed’s picture

Well I'm still clueless as to why this is happening. However, if you need a temporary fix, you can put the following code in hook_cron of your own module or im_raw (make sure the cronjob runs often enough, like once per hour):

module_disable(array('im_raw'));
module_enable(array('im_raw'));

I know it ain't pretty, but at least it works this way until the problem has been solved.

adrinux’s picture

drimsun, are you saying that this is happening repeatedly for you?

Although I hit the same issue I only had it occur once, I'm using Drupal 5 though.

If it's happening repeatedly this is more serious than I thought.

account-deletion-needed’s picture

Yes, unfortunately it's happening regularly, often multiple times a day.

account-deletion-needed’s picture

Actually, better don't use the hook_cron trick above, it seems to make the module fail more often than fixing it. Though, maybe it can be used repeatedly to track down the problem?

account-deletion-needed’s picture

Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new716 bytes

Thank god I finally found the damn bug!

The problem is the permission check in:

function im_raw_imagecache_actions() {
  if (user_access('Allow user to enter raw ImageMagick command options')) {
    $actions = array(
      'im_raw' => array(
        'name' => 'IM raw',
        'description' => 'Enter raw imagemagick command line options.'
      )
    );
    return $actions;
  }
}

A regular user doesn't have permission to enter IM RAW commands of course, which causes this function to return nothing and thus imagecache sees no IM RAW actions. However, because imagecache caches these action arrays, the module works until the cache is reset and imagecache recalls this function from a user without permission.

You can test this by disabling imagecache actions caching by inserting false into the if condition in imagecache.module on line 246. Thus, the code will always go to the else condition and try to load actions from the module hooks, which fails for IM RAW if the user has no permission to edit IM RAW actions. Use 2 browsers to test, one with a user with IM RAW permission to flush a test preset and another one with an anonymous user to view the test image.

The attached patch simply removes the permission check. I'm not sure if a permission is needed at all for IM RAW, as there's already an administer imagecache permission.

adrinux’s picture

Status: Needs review » Needs work

Aha! Great detective work drimsun. Thank you!

However, I'm reluctant to remove the access check entirely, most imagecache actions are readily usable by normal users and very much designed to be so, im_raw is more technical and potentially open to abuse (imageapi filters the command before passing it to imagemagick so it shouldn't be, but I'd rather be careful – I'd imagine it's possible to do a DOS attack for instance by creating a looping or just plain complicated imagemagick command).

Given this bug it makes sense to move the access check to the form though – then everybody gets to use im_raw actions, but only people with permission get to enter them in the form.

Don't worry about re-rolling your patch, I'll get this sorted and push out updates for Drupal 5 and 6 this afternoon.

adrinux’s picture

Status: Needs work » Fixed

Fixed in new releases 5.x-1.1 and 6.x-1.2.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.