Undefined index: file_src when uploading file

[jeroenbraspenning]

Hi,

I've encountered an issue with Timmy regarding the generating of "resizes". When i upload an image i get the following error and the resizes are not generated.

Notice: Undefined index: file_src in /var/www/html/wp-test/wp-content/plugins/timmy-0.14.4/lib/Timmy.php on line 867

I am using the following configuration in a fresh WP install (v5.4.1) with the latest version of Timber@1.15.2 and Timmy@0.14.4.

if (class_exists('Timmy\Timmy')) {
    new Timmy\Timmy();
}

// reset thumbs sizes
set_post_thumbnail_size(0, 0);

// set Timmy sizes
add_filter('timmy/sizes', function ($sizes) {
    return array(
        'custom-4' => array(
            'resize' => array( 370 ),
            'srcset' => array( 2 ),
            'sizes' => '(min-width: 992px) 33.333vw, 100vw',
            'name' => 'Width 1/4 fix',
            'post_types' => array( 'post', 'page' ),
        ),
    );
});

// prevent wordpress downscaling image
add_filter('big_image_size_threshold', '__return_false');
// generate all sizes upon upload
add_filter('timmy/generate_srcset_sizes', '__return_true');

I'm tracking down the issue and it seems that the following function does not return a 'file_src' attribute, but it does supply a 'file' attribute.

File: Timmy.php, line: 867

// Get unfiltered meta data to prevent potential recursion.
$meta_data = wp_get_attachment_metadata($attachment->ID, true);
$file_src  = $meta_data['file_src'];

But 'file' does not contain an absolute path to the image which the resize function demands. This results in the system skipping the "resizes".

I've encountered this on an existing setup as well, that's why i made a fresh install within a production environment to double check and skip potential php errors.

Does anyone else encounter this?

[jeroenbraspenning]

A quick update, replacing line 867 with the following, fixes the issue for me. But i'm still unsure if this is an issue or just something i'm encountering in my specific setup.

// Get unfiltered meta data to prevent potential recursion.
$meta_data = wp_get_attachment_metadata($attachment->ID, true);
// Get upload path
$uploads = wp_upload_dir();
$file_src  = $uploads['baseurl'] . '/' . $meta_data['file'];

[gchtr]

@jeroenbraspenning Thanks for providing such a detailed test case! I’ll see whether I can reproduce that. Just a quick question: Does it also happen for newly uploaded images or does it happen for an image that has existed in the Media library for a longer time?

[jeroenbraspenning]

@gchtr quick reply! thanks.

I first encountered it with an existing project and started testing with an empty environment. In this fresh environment i can confirm that it also happens with fresh uploaded images.

On a side note, the version of the Timmy plugin states 0.14.1 in Wordpress but i downloaded 0.14.4.

[gchtr]

Okay, thanks for checking! I’ll look at this, hopefully this week.

On a side note, the version of the Timmy plugin states 0.14.1 in Wordpress but i downloaded 0.14.4.

Oh, okay. I’m mostly working with Timmy as a Composer dependency these days, so I definitely forgot about changing the version number for the plugin. Thanks for the hint, will fix that, too!

[gchtr]

Hey @jeroenbraspenning

Took me a little longer, busy times!

I’m not exactly sure why the file_src doesn’t exist anymore, or if it ever existed. But anyways, in 0.14.4 I added a new method for getting the file src, which apparently has to be used where the error happened, too 🙂.

Could you please check whether the fix-generate-srcset-sizes branch solves the issue?

composer require mindkomm/timmy:dev-fix-generate-srcset-sizes

[jeroenbraspenning]

Hey @gchtr

Thanks for the work! this fixes the issue!

[gchtr]

This is fixed with the 0.14.5 release.