4

I have a number of assets resources all set to upload to the same amazon s3 bucket. Two of my four assets resources show "An unknown error occurred" twice when I view them in /admin/assets.

an unknown error occurred

The files in the folder do not show up. In the logs the following error appears:

Error: Call to a member function format() on null in /apps/cms/craft/app/helpers/AssetsHelper.php:81

When I click Upload files I can upload files, but they do not show up once the upload has finished (no files are shown). They do get uploaded to s3 though. The message "an unknown error occurred" appears again.

Subfolders in that same folder show up perfectly and have all of their content visible and it is possible to upload new images without a hitch.

How can I get the top level folders to work again? What could cause this?

Improve this question
4
  • Maybe the path is incorrect? Have you rebuilt the search index and asset index?
    – Clark Nelson
    Commented Jun 7, 2018 at 19:12
  • asset index yes, search index no. Path seems to be correct, subfolders are working and two other asset sources with similar settings are working fine.
    – Florian
    Commented Jun 8, 2018 at 7:00
  • Updating the search index didn't solve the issue.
    – Florian
    Commented Jun 8, 2018 at 7:09
  • For whatever reason your dateModified property is null instead of a valid DateTime. You could temporarily change the code and see if the error disappears or contact pixel and tonic about it since it's likely a bug
    – Robin Schambach
    Commented Jun 9, 2018 at 8:32

2 Answers 2

Reset to default
2

I got an emailed response from Andris from P&T:

That indicates that at some point Craft was unable to index a file, leaving some corrupt data. If you look at craft_assetfiles table, you'll notice that at least one entry has the dateModified column set to null. Removing those should fix the issue for you. Probably the best way to remove them would be to actually delete the records from the craft_elements table, that have the matching IDs. The cascading delete should remove all related records.

Please do make backups before tampering with the database, though!

Deleting the records fixed the issues.

Improve this answer
1

I actually also just came across this issue, just wanted to add that in my case the culprit was folder ownership within the storage/runtime/compiled_templates/ folder. It was part of a new deploy, and ran into several issues with permissions. Setting the correct owner fixed the issue.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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