Bug #6989

Digital object linking to external resource is broken

Added by Dan Gillean almost 8 years ago. Updated over 7 years ago.

Status:VerifiedStart date:07/14/2014
Priority:CriticalDue date:
Assignee:Dan Gillean% Done:


Category:Digital object
Target version:Release 2.1.0
Google Code Legacy ID: Tested version:
Sponsored:No Requires documentation:


To reproduce:

  • Create a new description
  • Find an image online (must end in file format, e.g. http://www.example.com/this-image.jpg), copy URL
  • In AtoM, click Link digital object on your description, and add the image URL to the external linking option

Resulting error

AtoM attempts to append the URL of the external resource to the file path when creating, causing it to throw a 500 error. See attached stack trace for details.

Expected result
AtoM successfully links to the external digital object, and locally creates reference and thumbnail images.

Marking critical because 1) this is a regression that should not go into 2.1, and b) it is a basic application functionality that should work as expected in a public release.

stack-trace.htm Magnifier (181 KB) Dan Gillean, 07/14/2014 04:20 PM

linkedImageImportFail.png (35.1 KB) Dan Gillean, 07/18/2014 03:55 PM

digital-object-upload-limit.png (16.4 KB) Dan Gillean, 09/09/2014 03:51 PM

Related issues

Related to Access to Memory (AtoM) - Bug #7221: Digital object upload "limit reached" message page needs ... Verified 09/09/2014
Blocks Access to Memory (AtoM) - Bug #6548: showDownloadComponent assumes digital object is located o... Verified 04/02/2014


#1 Updated by Dan Gillean almost 8 years ago

Note: this is also affecting imports that include links to external digital objects, causing the import to fail - see attached screenshot.

#2 Updated by Mike Gale almost 8 years ago

For what it's worth I took 15 minutes to look at this since it was messing up my testing. It doesn't appear, strangely enough, that any of the recent commits in the last several months broke it? I at least tested the code before the last 3 commits and it seemed broken still.

https://github.com/artefactual/atom/blob/qa/2.1.x/lib/model/QubitDigitalObject.php#L1309 is where it's building the file path before attempting to the write the file. This is the point of failure, since we're apparently saving the URL in the 'path' column in the database where normally a file path should be.

There is also a temporary file for the URI image saved here: https://github.com/artefactual/atom/blob/qa/2.1.x/lib/model/QubitDigitalObject.php#L1403

Does it make sense that we move the temporary file into uploads/ and make the path column point to that instead of the original URI? I'm not sure what our preferred design is supposed to be, keeping the original URI or downloading the image / copying it to uploads, but the latter would definitely fix this.

#3 Updated by Jesús García Crespo almost 8 years ago

I think that we need the original URI so we can generate derivatives in the future? There may be other reasons, like the archivist wants to keep that link for some reason.

#4 Updated by Jesús García Crespo over 7 years ago

  • Status changed from New to Code Review
  • Assignee changed from Jesús García Crespo to Mike Gale

This commit broke it: bb40680f.
Mike, what do you think about https://github.com/artefactual/atom/pull/48? Feel free to merge, I feel like you have a better understanding of what's going on there as you updated that function recently. I tested it and it seems to work and both ref and thumbs are created and stored locally while the master is kept as external. It seems correct, if that's the result that we want to achieve?

#5 Updated by Dan Gillean over 7 years ago

Jesus, passing this to you.

I tested this on a branch in my local 1.3ES VM and got a weird error that must be a regression - I am directed to a message saying that the upload limit has been reached - however, I checked the repo page, Admin > Settings, and in /config/app.yml, and all areas were set to -1. The message even said "The maximum disk space of -1 GB available for uploading digital objects has been reached." - see attached screenshot.

Just to make sure this wasn't something messed up in my local environment, I had Mike G merge it into qa/2.1.x - and I've just recreated it on the test site.

It seems possible that this regression has been caused by your work with the uploads folder? Not sure. Could be any number of commits made in the last week. Please check it out when you can.

Related minor issue (if we have time to fix) - #7221

#6 Updated by Jesús García Crespo over 7 years ago

  • Status changed from Feedback to QA/Review
  • Assignee changed from Jesús García Crespo to Dan Gillean

#7 Updated by Dan Gillean over 7 years ago

  • Status changed from QA/Review to Verified


Also available in: Atom PDF