EDIT 3: Started using imager and no longer have the problem. It's not a real answer to the problem but solves the problem.

This is the situation that has me pulling my hairs... I've looked at other related Q&A's but can't seem to distill a solution for the issue I'm facing.

I'm trying to apply an image transform but I get a link like /cpresources/404?x=TBKkjeyyP returned. Also, no image is being generated.

Files can be uploaded trough the backend just fine, can be linked to an entry and can be shown without applying the transform.

Any pointers as to what is going wrong? I'll gladly provide additional information if/when needed.

My setup is as follows:

  • Using Craft CMS 2.6.2986 on apache
  • 3 locales configured (nl, en, fr)
  • local storage (File System Path: uploads/& url: {baseUrl}uploads/)
  • relevant config below (using process described here)

General config:

// All environments
'*' => array(
    'omitScriptNameInUrls' => true,
    'overridePhpSessionLocation' => true,
    'usePathInfo' => true,
    'cacheDuration' => false,
    'useEmailAsUsername' => true,
    'generateTransformsBeforePageLoad' => true,
    'siteUrl' => array(
        'nl' => getenv('CRAFTENV_SITE_URL').'nl/',
        'fr' => getenv('CRAFTENV_SITE_URL').'fr/',
        'en' => getenv('CRAFTENV_SITE_URL').'en/',
    'craftEnv' => CRAFT_ENVIRONMENT,
    'environmentVariables' => array(
        'baseUrl'  => getenv('CRAFTENV_BASE_URL'),
        'basePath' => getenv('CRAFTENV_BASE_PATH'),
    // development environment
    'development'  => array(
        'devMode' => true,
        'enableTemplateCaching' => false,
        'allowAutoUpdates' => true,

Relevant CRAFT_ENV settings:

'SITE_URL' => $protocol . $_SERVER['HTTP_HOST'] . '/',

'BASE_URL' => $protocol . $_SERVER['HTTP_HOST'] . '/',

'BASE_PATH' => realpath(dirname(__FILE__)) . '/www/',

EDIT: Part of the code applying the transform:

{% set thumb = blog.previewImage.first() %}
{% if thumb %}
    <img src="{{ thumb.getUrl("blogPreview") }}" width="{{ thumb.getWidth("blogPreview") }}" height="{{ thumb.getHeight("blogPreview") }}">                     
{% endif %}

EDIT 2: relevant log entries

Level warning Category application Message [Forced] Image “gasmeters.png” could not be found.

Level trace Category system.db.CDbCommand Message Executing SQL: DELETE FROM craft_assettransformindex WHERE id = :id. Bound with :id='70'

  • Show us how do you apply image transform Jul 13, 2017 at 11:34
  • Done, see main question
    – mrsmn
    Jul 13, 2017 at 11:54
  • Your 404 is being generated here github.com/craftcms/cms/blob/2.6.2986/src/services/…. you must read logs. It might be file permissions. Jul 13, 2017 at 12:46
  • Added the relevant log entries, from what I can see, craft fails to get the file, but I have no clue why...
    – mrsmn
    Jul 13, 2017 at 12:59
  • I was able to reproduce this by removing image directly from filesystem. Assets page still shows image preview, but when I try to view image 404 is returned. Same when I try call transformation with broken asset file. Find this gasmeters.png in assets page and reupload it Jul 13, 2017 at 13:06

2 Answers 2


For what it's worth, I also had his issue, turned to imager, which gave me some more useful error messages as to my root cause of the issue:

You may need to make sure that the path to the asset file is complete, not just relative to the site base. So for instance, a base path of ./assets works fine for standard purposes, but appears no use for transforming images, you would need http://site/assets.

If your setting a base path in config, you can use something like

'environmentVariables' => array(
    'assetsBaseUrl' => '/assets',
    'assetsBasePath' => "{$_SERVER['DOCUMENT_ROOT']}/assets",
  • FWIW, this was the issue for me too. Fixed the path and it fixed the problem. Jan 24, 2018 at 9:43
  • Pretty much the issue I experienced too, thanks dude! For anyone else running Craft CMS on IIS in a Windows server, additionally the "basePath" settings seem to follow the slash rule native to the environment being ran in. (So in my case I was originally following Linux forward slash for directories, but because I was on Windows in IIS, I needed to use the backslash instead for my directories.)
    – J.D.
    Nov 4, 2020 at 23:10

Started using imager and no longer have the problem. It's not a real answer to the question but it solves the problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.