Transforms now causing error when used with Redactor: finfo_file(FILENAME.jpg): failed to open stream: No such file or directory

[peter-tell]

Issue:
Selecting an image and then a transform from the Redactor Modal Window produces a 500 Error

Steps to Reproduce:

1. Create a Transform
2. Create a WYSIWYG with an Image Button
3. Insert an Image with a Transform
4. Save the post.

finfo_file(writing.jpg): failed to open stream: No such file or directory

1. in /vendor/yiisoft/yii2/helpers/BaseFileHelper.php at line 158

[andris-sevcenko]

What Craft version are you using?

[peter-tell]

Sorry, that would have been helpful:

Image driver & version | Imagick 3.4.3 (ImageMagick 6.9.6-2)
-- | --
Craft Pro 3.0.7
-- | --
Redactor | 2.0.1

[noxify]

I can't reproduce the problem.

• Craft PRO 3.0.7
• Redactor 2.0.1

Assets Configuration:

• Volume: local ( @webroot/uploads)
• Transformer: Thumb / Small / Medium ( copied from the HappyLager example)

I have tested it with the following:

• Upload image via Redactor Editor
• Upload image via Assets page and choose it via the Redactor Editor

---

Question:

• If you have no transformer defined, is it working?
• Are all directory permissions set correctly

[peter-tell]

Ok thanks @noxify - I'll dig deeper into it and try to get more info.

[peter-tell]

If you have no transformer defined, is it working?

Yes

Are all directory permissions set correctly

They are. This was working before I updated from Craft 3.0.5 and Redactor 2.0.0.1

For what it's worth, both of these are in Matrix blocks. Not sure if that makes a difference but I'll keep testing to see if I can isolate the problem.

[noxify]

I have tested it with an Matrix field - and it's working, too.

[noxify]

Maybe you can give it a try with a fresh installation?

[peter-tell]

Thanks for the help @noxify. I'll keep digging.

[peter-tell]

Not sure this helps at all, but for some reason it's not getting the full file path for my transformed image, just the filename:

5. in /vendor/craftcms/cms/src/helpers/FileHelper.php at line 260 – yii\helpers\BaseFileHelper::getMimeType('test-file.jpg', null, true)

     /**
     * @inheritdoc
     */
    public static function getMimeType($file, $magicFile = null, $checkExtension = true)
    {
        try {
            $mimeType = parent::getMimeType($file, $magicFile, $checkExtension);
        } catch (\Throwable $e) {
            if (!$checkExtension) {
                throw $e;
            }
            $mimeType = null;
        }

[jameskrill]

I had this issue just happen. What I figured out in my case, is that the selected image source had a smaller resolution/size than the transform selected, resulting in the file not being found.

Seems like a bug that you could select a transform that doesn't exist... OR... craft should fall back on the next available transform.

For example, if the transform 'full' is 1600px wide, but your source image is 800px, the source image should be served if 'full' is selected as the transform to insert. Or better yet, you shouldn't be able to select that transform when inserting the image.

[peter-tell]

Thanks @jameskrill -- Unfortunately that's not it in my instance.

I've tracked this down to a change in vendor\craftcms\cms\src\elements\Asset.php on line 708 in either 3.0.6 or 3.0.7

Specifically FileHelper::isGif($this->filename) is causing my problem. If I remove that, the issue is gone.

[peter-tell]

@andris-sevcenko Not sure it's worth the paper it's printed on, but adding the full path to the image fixed my problem.

I changed line 708 of vendor\craftcms\cms\src\elements\Asset.php

From:

if (FileHelper::isGif($this->filename) && !Craft::$app->getConfig()->getGeneral()->transformGifs) {
            return AssetsHelper::generateUrl($volume, $this);
        }

To:

if (FileHelper::isGif(FileHelper::normalizePath($volume->getRootPath().DIRECTORY_SEPARATOR.$this->getPath())) && !Craft::$app->getConfig()->getGeneral()->transformGifs) {
            return AssetsHelper::generateUrl($volume, $this);
        }

Without being more familiar with the codebase I'm not sure if there are repercussions to this.

[noxify]

@page-8 - Is this then not a craftcms/cms issue?

Btw. The path info was removed in this commit:
craftcms/cms@112e2f6#diff-1439c2c7558601e6752050108ba410d4L708

[andris-sevcenko]

@page-8

Without being more familiar with the codebase I'm not sure if there are repercussions to this.

This will fail for remote Volumes, sadly.

The codeblock you pasted above is there exactly because Craft sometimes needs to decide on the mimetype based just on the filename. It's curious that it's not working for you, though.

Are you, by any chance, overriding or disabling the error handler component in your app configuration? That particular block of code relies on Yii's error handler converting errors to exceptions.

[peter-tell]

@andris-sevcenko

That's what's really weird about this. The only place the exception is (seemingly) not getting caught is in the Redactor Transform. For example, I'm not getting an error on the Assets Listing page.

Are you, by any chance, overriding or disabling the error handler component in your app configuration?

No, this is the only thing in my general config:

'*' => [
        'defaultWeekStartDay'  => 0,
        'enableCsrfProtection' => true,
        'omitScriptNameInUrls' => true,
        'cpTrigger'            => 'webmaster',
        'securityKey'          => getenv('SECURITY_KEY'),
        'useEmailAsUsername'   => true,
        'allowUpdates'         => false,
        'phpSessionName'       => 'MTMSessId',
        'sendPoweredByHeader'  => false,
    ],

This is happening on my local environment using MAMP 4 and the Arcustech server where we have the site hosted.

This is also happening for me on a fresh installation of Craft 3 with only the Redactor plugin installed and one field type called Body with one Transform called testTransform

Per your comment @noxify , it seems like it's only happening with Redactor's use of this only when it comes to a transform. (as far as I can tell)

[andris-sevcenko]

Got it, I'll see if I can reproduce!

[andris-sevcenko]

See the issue, working on a fix

[peter-tell]

Sweet, thanks @andris-sevcenko !