I think one of the benefits of the linkit module is, that it always will have the proper paths to the content, regardless of alias changes.
This feature is missing in this small module. When the files inside an atom changes, it is not reflected and the links are dead.

The idea for a general linkit support for scald atoms is great though.

CommentFileSizeAuthor
#4 scald_linkit-exchange_file_in_atom_breaks_link-2889696-4.patch2.89 KBRudi Teschner
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Rudi Teschner created an issue. See original summary.

bdimaggio’s picture

bdimaggio
he/him
Location Boston, MA
CreditAttribution: bdimaggio commented

Yeah, you're right about that. What do you think about creating a new path per atom (something like 'atom/[sid]/direct') that would then drupal_goto() the atom's file's direct path?

Rudi Teschner’s picture

Rudi Teschner CreditAttribution: Rudi Teschner commented

This would be a reasonable choice, I think. Considering that it cannot be handled at the context level. :)

Question though is, could those defaults defined on the linkit ui be "overridden" on link-level, if necessary?

Rudi Teschner’s picture

Rudi Teschner CreditAttribution: Rudi Teschner commented
FileSize
scald_linkit-exchange_file_in_atom_breaks_link-2889696-4.patch2.89 KB

Here's a start for this workaround, changing the inserted link to the proposed atom/%/direct version.
The patch is based on how the sandbox module https://www.drupal.org/sandbox/zekeweeks/2377669 handles a similar issue.

And it works for me. I think we just need to ensure that additional permission checks will be added to guarantee data safety.

And maybe something like a popup if one does not have access to that file.