1

I'm trying to get my Craft 2 site running locally again (it worked at one point but now does not). I have gotten all the db related issues (seemingly) done and dusted and the admin loads fine, but it seems that anything linked to Amazon S3 (or perhaps the {{ craft.config.rootUrl }}?) seems to be failing.

The devtools console has a lot of : Failed to load resource: the server responded with a status of 404 (Not Found)

The local set up is using docker inside a virtual machine and is brought up using vagrant. I have all the code locally tied to lvh.me (on a specific port) and when the site loads, some external services (such as Imager) are still working – just nothing relating to aws / S3 for some reason.

Has anyone encountered this before? Have I forgotten to set something up re: Multi Environment variables or perhaps did Google change a policy that requires me to add permissions to the IAM user to allow for local access?

Thanks in advance for any steers.

Really at an impasse here. Can anyone help?

edit: After helpful comments, I am getting the impression that since the path to the root of the Assets folder is something that is controlled by the general.php file and the files that aren't loading seem to be directly inside there (and local, as opposed to on S3), that maybe this isn't an S3 issue (yet). It seems that the local path to the Assets folder is least part of the problem.
Here's what my set up in general.php looks like:

// $protocol = isset($_SERVER['CRAFT_PROTOCOL']) ? $_SERVER['CRAFT_PROTOCOL'] : 'https';
$protocol = $_ENV['CRAFT_PROTOCOL'];
// force http on local environment
if ($_SERVER['REMOTE_ADDR'] == '127.0.0.1' ) {
    $protocol = 'http';
}

return array(
    '*' => array(
        'devMode' => false,
        'omitScriptNameInUrls' => true,
        'preserveImageColorProfiles' => true,
        'backupDbOnUpdate' => false,
        'generateTransformsBeforePageLoad' => true,
        'maxUploadFileSize' => 33554432,
        'environmentVariables' => array(
            'baseUrl' => $protocol.'://'.$_ENV['SITE_URL'].'/',
            'basePath' => $_ENV['DOCUMENT_ROOT'].'/',
            'assetsUrl' => $protocol.'://'.$_ENV['SITE_URL'].'/'
        ),
        'rootUrl' => $protocol.'://'.$_ENV['SITE_URL'],
        'siteUrl' => array(
            'en_gb' => $protocol.'://'.$_ENV['HTTP_HOST'].'/',
            'ja_jp' => $protocol.'://'.$_ENV['HTTP_HOST'].'/'
        ),
    ),
);

Anything look out of place to anyone? The assets that won't load locally, via lvh.me, are in the *public > assets > folder (e.g. public> assets > js > app.js). They load fine in the staging environment, but just not locally. It feels like either a Docker / CI issue relating to the Sandbox or just a config issue with the settings above. The error is a 404 not found and that URL is reading: http://lvh.me/assets/js/app.js?v=14

What do you think?

3
  • Do you have the S3 volume set through the Control Panel? – whoisjuan Jul 15 '20 at 2:00
  • @whoisjuan thanks for the reply. Yes, it's all working as it should on staging and production (assuming you mean the craft control panel?). Everything locally matches up with what is on the servers, except obviously the base url which changes to either localhost or lvh.me (both running on specific ports). It just seems like for some reason the site isn't able to resolve the amazon S3 links. Other services though, such as Imager, are still delivering. Any ideas? – J. Ktz Jul 15 '20 at 15:49
  • It feels like it might be relating to the assetsURL potentially though, looking at the assets repos locally in the Craft CP, they all have a URL Prefix corresponding to the S3 bucket. When on the server, it seems that craft is able to parse these and load from mydomain.com/assets/pathtofile, but locally this isn't the case. Do I need to change the basePath and baseURL for this to work? – J. Ktz Jul 17 '20 at 17:04
1

My guess is that your bucket doesn't have the right permissions. Try adding this permission to your bucket (use with caution since this will make the S3 100% public):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::bucketname/*"
        }
    ]
}

Replace bucketname with your actual bucket name. You can add this policy via the AWS UI console. In S3 > YourBucket > Permissions > Bucket Policy.

If by doing this you actually manage to get URLs that resolve, then your problem are permissions. I would still delete this bucket policy and set the correct permissions for your use case.

6
  • Thanks @whosisjuan – really appreciate the lead. I gave it a go and opened up the bucket to public but unfortunately it didn't rectify things. It appears that all problems loading seem be coming from the "assets" folder and I am getting at: Failed to load resource: the server responded with a status of 404 (Not Found). Could it be a Craft issue? – J. Ktz Jul 17 '20 at 10:31
  • Hi @whoisjuan – any further ideas? I'm completely stuck still on this. – J. Ktz Jul 24 '20 at 7:51
  • @J.Ktz I'm thinking this is a misconfiguration problem. What I would do is go to the local installation CP at Settings > Assets > Volumes, and I would delete your S3 volume and add it again. Maybe you have the wrong URL or wrong credentials. – whoisjuan Jul 27 '20 at 17:57
  • thanks for the suggestion. I tried, but it sadly wasn't the issue, though doing so pointed out the fact that the bits that aren't loading, despite being located in the assets/ folder, are not actually coming from S3, rather sitting in the craft public assets folder. So it seems the problem might not be with S3, rather the local path to the assets or permissions. I tried to changing the folder permissions on the assets folder (recursively), making sure everyone had read and write access, but that didn't do the trick. It sounds like something to do with the asset path? – J. Ktz Jul 31 '20 at 13:41
  • @J.Ktz I think the problem is then with Docker itself. Seems like Docker is preventing the write and/or blocking S3. Still could be a policy issue on S3 side (see: stackoverflow.com/questions/54237228/…) – whoisjuan Aug 2 '20 at 0:10

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.