Feature request: Allow fragments (and query string) for media-links about sulu

[alexander-schranz]

If I understand you correctly you are missing the #fragments fields inside the Text Editor / CKeditor links? Because outside of it via single_media_selection I would go this way via 2 fields:

<property name="document" type="single_media_selection" colspan="9">
    <meta>
        <title lang="en">Document</title>
    </meta>
</property>

<property name="documentPage" type="number">
    <meta>
        <title lang="en">Page</title>
        <info_text lang="en">Optional page of a selected PDF</info_text>
    </meta>

    <params>
        <param name="step" value="1"/>
        <param name="multiple_of" value="1"/>
    </params>
</property>

{% set mediaUrl = sulu_get_media_url(content.document, 'inline') %}
{% if content.documentPage %}
     {% set mediaUrl ~= '#' ~ content.documentPage %}
{% endif %}

<a href="{{ mediaUrl }}">Download</a>

[spackmat]

Hey, thanks for your solution for single_media_selection types. That could be helpful in other contexts.

Here I mean both a link content-type and the links within the Text Editor.

The link content-type already has a enable_anchor option, but that only applies to internal links, not external links (that do not need it) nor media links. At that point, I just want the other link types have that input field for the anchor. (I call that fragment as the anchor describes the target and not the part of the URI, which I mean here.)

Inside the Text Editor a link to media also just has inputs for the file, a link-target-attribute and an alt-text in that case, which the link content-type does not have.

In both cases, it would be great to have that "anchor" field from the internal link type.

[spackmat]

Btw. the fact, that I cannot link to media with inline=1 from a media link within a text editor, is even more cumbersome than the missing fragments. So now, all our linked PDF files are downloaded instead of being shown in the browser. That raises the question for me: Why are those already existing fields disabled on purpose for media links in the first place? The inline-query-parameter is a core functionality of Sulu and fragments are also valid parts of an URI of media resources.

[alexander-schranz]

@spackmat you can make inline=1 the default for your installation see the documentation about inline links here: https://docs.sulu.io/en/2.5/reference/twig-extensions/functions/sulu_get_media_url.html. There is no purpose behind it I think just nobody yet had the usecase yet to modify media urls or link inside pdfs, even I was not aware that fragments exists inside pdf links.

[spackmat]

That helps, indeed. Thanks.

Would a PR to enable fragments and query strings for media links be appreciated?

[spackmat]

Hey, I bump that topic as that problem arises again for us. If I provide a PR enabling the anchor field for internal media links, would that stand a chance to be accepted?

[spackmat]

We have some (quite large) PDF files with regulatory content and thus an official published state (as in we cannot change the requirements) where we heavily (as in hundreds of links) rely on that #page=x URL fragment. At the moment we link to those files via the external link type, but that is a cumbersome workaround as it also works around the whole media system of Sulu. So you could make us very happy, if my little PR could be accepted.