Skip to first unread message
Alex Fletcher
Sep 18, 2018, 3:27:03 PM9/18/18
to AtoM Users
We had a digital object on one of our fonds that was a URL to an online archive.
That links is as follows:
When this is added as a digital object, the icon at the top of the fonds displays and links to the correct place.
But, the URL at the bottom of the display page breaks the URL as follows:
but displays the rest of the URL after that, but not as a parsed link/etc.
We can put that URL into the "General note" field and the same thing happens (just without displaying as a digital object at the top of the fonds).
Alex
Dan Gillean
Sep 18, 2018, 4:25:16 PM9/18/18
to ICA-AtoM Users
Hi Alex,
Interesting. It does seem that AtoM's regex is not working properly for link identification in 2.4.0. The good news is, I tested this in multiple places in our 2.5 development branch, and it seems that this has already been addressed - the link worked in static pages, in the body of descriptions, using Markdown to style the link (full markdown support in AtoM is coming in the 2.5 release), and in the digital object URL field:
I also had a coworker test throwing this link into a static page, and as a digital object URL, in our upcoming 2.4.1 release, and the full link worked there as well. So, it seems that this has been addressed already along the way?
Now, you may already know this, but for anyone else reading this thread, I do want to share one point about the ability to link to external digital objects via URL. That is, the way you are using the digital object module *can* work if you are doing it intentionally, but I want to make sure you're aware that this is not how it is intended to be used.
When linking to an external digital object, AtoM expects that the URL provided meets the following criteria:
- It is prefixed by http:// or https:// - FTP links will not work, nor will links to attached network storage/alternative drives on a local computer, etc.
- It is publicly accessible on the web - not behind any firewalls or requiring passwords to access, etc.
- The URL ends in the file extension of the digital object - that is, it is a link DIRECTLY to the digital object, and not a landing page on which the object is found
It is because of this last point, #3, that I mention this. I suspect that you are getting a blank generic icon for your link, and a filesize of 0B, and a MIME-type of "unknown." This is because you are not actually pointing directly at a digital object, but at a landing page - and AtoM doesn't know what to do with that, since it is trying to pass what it finds to tools like ImageMagick, to generate the thumbnail and reference display copies. You can manually upload your own versions, and by doing so, sort of mimic the functionality (for example, it's possible to paste in a YouTube video link, take a screenshot of the video, replace the blank derivatives with your screenshot, and sort of fake a link to the video). However, for this to work properly, you end up having to change the media type, which can lead to unexpected outcomes in search and browse when faceting or filtering for specific media.
In any case, we are now finalizing the 2.4.1 release, so hopefully you will be able to upgrade and resolve this issue very soon. In the meantime, if you don't want to wait for the formal public release to upgrade, I have shared details in the following thread how you can access the bug fixes in 2.4.1 now:
--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To post to this group, send email to ica-ato...@googlegroups.com.
Visit this group at https://groups.google.com/group/ica-atom-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/586ec274-80e3-4f58-8eec-d18db44c560d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dan Gillean
Sep 18, 2018, 4:29:51 PM9/18/18
to ICA-AtoM Users
Oops, hi again,
I've just heard back from my colleague, and strangely, it seems to work inconsistently in 2.4.1 - sometimes the regex worked fine, and other times it didn't. I've tried it a couple times in 2.5, and it seems to work consistently there, so I'm not going to file an issue ticket - but my promise of this being resolved in 2.4.1 may have been premature?
Sorry! We'll keep playing around and will update this thread if we find anything of further use.
Reply all
Reply to author
Forward
0 new messages