Closed (fixed)
Project:
Drupal core
Version:
7.x-dev
Component:
image system
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
28 Aug 2012 at 23:14 UTC
Updated:
4 Jan 2014 at 02:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
berdirComment #2
larowlanNice catch.
Should we add tests?
Comment #3
berdirNot sure if it makes sense or what the best way to do it would be. Maybe implement a hook that is invoked and count how many times it's invoked?
Comment #4
cameron tod commentedAre you sure that removing that !empty() is ok?
Comment #5
cameron tod commentedHere's a test that uses a call to drupal_alter() to check whether image effects are coming from the cache or not.
The patch in #1 seems good to go if my test is not flawed (a big if :P).
Comment #6
larowlancache hits or 'non-cache' hits?
Comment #7
cameron tod commentedDuh! Nice pickup.
Comment #8
berdirTests look ok to me. Who wants to RTBC this? :)
Comment #9
larowlanComment #10
dries commentedGreat catch. Committed to 8.x. Moving to 7.x. for backporting.
Comment #11
larowlanbackporting in progress
Comment #12
larowlanComment #14
cameron tod commentedThe D7 patch still has the !empty($cache->data) in it, maybe that is causing the fail? Seems odd though.
Comment #15
larowlanYeah, weird because it passed locally.
I left the empty($cache->data) in because I've a recollection in D7 that cache_get can still return an object with no data, happy to be wrong on that.
Comment #16
larowlan#12: image-effects-caching-1761086-12.pass_.patch queued for re-testing.
Comment #18
berdirIf that would really be the case, then we would have to check it on every single cache_get(), no? But we don't., we only do it here and in one other instance in update.module, which is using the custom pseudo-cache API.
Comment #19
larowlanThanks Berdir, glad to have that cleared up. Will re-roll when I get a chance.
Comment #20
cameron tod commentedThe reason this fails is because ImageEffectsUnitTestCase extends ImageToolkitTestCase, which in turn extends DrupalWebTestCase. ImageEffectsUnitTestCase calls parent::setUp('image_test'), but doesn't deal with any arguments from ImageEffectsUnitTestCase, so when this happens:
...those arguments never make it up to ImageToolkitTestCase and image_module_test is never enabled. That makes the test fail.
I'm just working out how best to move things around, and will post a patch soon. If anyone has any ideas, please let me know.
Comment #21
larowlanCan we change ImageToolkitTestcase->setup to include image_module_test instead?
Comment #22
cameron tod commentedWe might be able to, but a bunch of other tests inherit from it, and it might make those fail and/or stress out the testbot more than necessary. I'll give it a shot though and see if it works locally. These are the tests that inherit:
Comment #23
cameron tod commentedLooks ok here I think, lets try it.
Comment #24
xjmRather than enabling the module in the parent's
setUp(), we should modify the parent class to enable modules passed from its children. See the pattern here: http://drupalcode.org/project/drupal.git/blob/refs/heads/7.x:/modules/no...Comment #25
cameron tod commentedMuch nicer, thanks for the advice. New patches attached.
Comment #26
berdirBackport looks good and has tests.
Comment #27
David_Rothstein commentedLooks good to me.
Committed to 7.x - thanks! http://drupalcode.org/project/drupal.git/commit/4d39299