Hi Tom,
I should clarify: you can make links that "work" to just about anything on the public web. However, if it's not a path directly to an object that ends in an extension then there are two consequences:
- You won't get a derivate generated (since AtoM can't make a derivative without a specific file as an input)
- The media type will likely be wrong (marked as "Other") which can affect other page display elements
Either 1, 2, or both tend to make these not great options for most cases.
So, for example:
- I could if I wanted add a YouTube link, but won't have a thumbnail for it or the right media type
- I could then edit the digital object and manually set the media type to "Video" - but then AtoM tries to load the video player for the access derivs, so you end up with an empty video player and no way to access the YouTube link
- Instead, I could set the media type to "Image", then after saving, go back into the edits and manually upload my own custom images to use for the display copy and the thumbnail. In this case, if a user clicks on the access derivative shown on the description view page (i.e. my manually uploaded screen grab of the video), it will properly take them to the YouTube link... so this almost works! However.... now AtoM thinks this digital object is an image, not a video, meaning search and browse facets and filters won't work as expected, etc. If I change it to video again, we go back to the problems above
Now, in your case, if you are:
- unable to get links that meet the recommended requirements but want to proceed anyway; AND
- are linking to images; AND
- are willing to manually make and upload your derivatives, AND
- understand the risks that you may need to redo all this work again in the future (see below)...
THEN you probably can use this approach for adding your links to whatever external DAMS or CMS your objects are held in.
Regarding 4:
The risk here is in re-running the "generate derivatives" command line task (
described here). If rerun without any other parameters, then all derivatives are thrown away, and AtoM will attempt to fetch new ones from the source - i.e. the original object, or from the provided URL if linking to a remote digital object. Obviously if you had to manually create and upload your own, then this would fail... so you would need to reapply all the changes manually again yourself.
Regenerating derivatives isn't something you should need to do all the time, but can be useful during troubleshooting, and is sometimes part of the recommended upgrade process. You can use the task options to only generate derivatives where they are missing, or only for a specific media type, for example - but what if someone else runs the task without knowing what you've done? What if the knowledge about this is not properly passed to your successor? etc? So it's up to you to consider the risks and how best to mitigate them if you decide to proceed.
Finally, if you are deleting things but they are still displaying in the user interface, then it may be that you need to clear the caches, or rebuild the search index.
For rebuilding the search index, see:
In terms of cache clearing, there are a few to consider. First, the application cache:
PHP-FPM also has its own cache, and if you installed the additional optional caching engine memcached, then it also needs to be cleared:
Finally, don't forget that your web browser also has its own cache! You can either clear this, use a different browser (that you haven't visited AtoM with recently), or try testing in an incognito or private browser window where the cache is typically disabled by default.
Let us know how it goes!