Hi Dev Community,
Working with Scroll and PDF exporters, using storage and view formats as well as the content from the contexts provided during the exporting pipeline. The issue below is solvable but it uncovers other issues, mainly due to the fact that the Conversion Context in cloud is singular (and we can only provide one) whereas in Server the context is always the original and therefore the issue described below can be fixed without collateral.
We are facing an issue regarding Links to headings on included pages, as they are not resolved correctly and thus do not work. This is due to the fact that the content ID associated with the context at a certain time, is bound to the wrong page, and thus when resolving the anchor or link to a specific href (heading in this case) it breaks. We can fix this by changing the source in which we resolve the elements by pointing to the Original Source where any inclusion macro is being included, the problem is that if we do this, the resolution of attachments (images) becomes broken.
Because the access of the API when fetching the attachments during content resolution will only allow us to access the content via Page ID, which is broken due to the fact that the lookup of the content ID for a certain context is looked into the original source, and in turn when accessing a certain attachment, the Page ID is wrong, because the provided content ID was changed to the original Source. In this case, instead of an error message in the returned URL, we get a broken link pointing to the attachment, which is another issue.
Therefore I have two questions:
- Is it possible to improve the API, returning an error message in the HTML when accessing an attachment that does not exist for the provided URL
- Is there a chance you could extend the API when accessing the attachments within confluence, to be done in a way that attachment resolution is not necessarily bound to the pageID but via other input values like resource name for example?
TLDR: Content resolution for include macros is bound to context and content IDs, which when solved breaks attachment resolution because the API only allows Page ID based lookups and even if the provided Page ID (content ID) is wrong, the API returns an HTML with a broken link instead of an error message.
Thanks!
BR 
,
Miguel