if ($cache = cache()->get("image_effects:$langcode") && !empty($cache->data)) {
      $effects = $cache->data;
    }

Who can spot the error?

Exactly, this can never be TRUE, because the () around the assignment are missing, so $cache is never defined. This is like that since the very day image styles were added to Core back in 2009 :)

I have no idea what the !empty() is supposed to do, that can be removed IMHO. Patch coming up in a second.

I'm seeing a cache_set() on every page with this in 8.x when displaying an image derivate.

Comments

berdir’s picture

Status: Active » Needs review
StatusFileSize
new513 bytes
larowlan’s picture

Nice catch.
Should we add tests?

berdir’s picture

Not 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?

cameron tod’s picture

Are you sure that removing that !empty() is ok?

cameron tod’s picture

Here'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).

larowlan’s picture

Status: Needs review » Needs work
+++ b/core/modules/image/tests/image_module_test.moduleundefined
@@ -38,3 +38,14 @@ function image_module_test_image_effect_info() {
+ * Used to keep a count of cache hits in image_effect_definition().

cache hits or 'non-cache' hits?

cameron tod’s picture

Status: Needs work » Needs review
StatusFileSize
new388 bytes
new2.89 KB

Duh! Nice pickup.

berdir’s picture

Tests look ok to me. Who wants to RTBC this? :)

larowlan’s picture

Status: Needs review » Reviewed & tested by the community
dries’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Great catch. Committed to 8.x. Moving to 7.x. for backporting.

larowlan’s picture

Assigned: Unassigned » larowlan

backporting in progress

larowlan’s picture

Assigned: larowlan » Unassigned
Status: Patch (to be ported) » Needs review
StatusFileSize
new2.72 KB
new2.22 KB

Status: Needs review » Needs work

The last submitted patch, image-effects-caching-1761086-12.pass_.patch, failed testing.

cameron tod’s picture

The D7 patch still has the !empty($cache->data) in it, maybe that is causing the fail? Seems odd though.

larowlan’s picture

Yeah, 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.

larowlan’s picture

Status: Needs work » Needs review
Issue tags: -Needs backport to D7

Status: Needs review » Needs work
Issue tags: +Needs backport to D7

The last submitted patch, image-effects-caching-1761086-12.pass_.patch, failed testing.

berdir’s picture

If 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.

larowlan’s picture

Thanks Berdir, glad to have that cleared up. Will re-roll when I get a chance.

cameron tod’s picture

The 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:

class ImageEffectsUnitTest extends ImageToolkitTestCase {
  function setUp() {
    parent::setUp('image_test', 'image_module_test');
  }

...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.

larowlan’s picture

Can we change ImageToolkitTestcase->setup to include image_module_test instead?

cameron tod’s picture

We 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:

./modules/image/image.test:248:class ImageEffectsUnitTest extends ImageToolkitTestCase {
./modules/simpletest/tests/image.test:72:class ImageToolkitUnitTest extends ImageToolkitTestCase {
./modules/simpletest/tests/image.test:465:class ImageFileMoveTest extends ImageToolkitTestCase {
cameron tod’s picture

Status: Needs work » Needs review
StatusFileSize
new3.18 KB
new2.7 KB

Looks ok here I think, lets try it.

xjm’s picture

Status: Needs review » Needs work
+++ b/modules/image/image.testundefined
@@ -255,7 +255,7 @@ class ImageEffectsUnitTest extends ImageToolkitTestCase {
-    parent::setUp('image_test');
+    parent::setUp('image_test', 'image_module_test');

+++ b/modules/simpletest/tests/image.testundefined
@@ -14,7 +14,7 @@ class ImageToolkitTestCase extends DrupalWebTestCase {
-    parent::setUp('image_test');
+    parent::setUp('image_test', 'image_module_test');

Rather 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...

cameron tod’s picture

Much nicer, thanks for the advice. New patches attached.

berdir’s picture

Status: Needs review » Reviewed & tested by the community

Backport looks good and has tests.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed

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