We're using experience fragments to produce HTML fragments that are consumed and displayed by an external application. Since the html in that case is no longer being served by the AEM instance we need any assets to be referenced by an absolute path rather then a relative one. I've seen some older blog posts that mention modifying the externalizer but I was wondering if that's still the only option and if so if there's better documentation available.
OOB features like Externalizer, Transformers, Sling Rewriters etc. would require custom coding & configuration.
If you don't want to create any custom components in AEM then you may achieve this use case in apache/dispatcher; write a cron to parse cached fragments and replace urls or use mod_proxy, mod_substitute etc. to modify response. It depends on the current setup and feasibility based on your use case.
No, we're just publishing experience fragments in a very stripped down template to produce an html fragment. The number/types of component's being used might change from page to page and we don't want the downstream application to need to process any json at all. We just want each to produce a single fragment of simple html that can be included. It's working great so far, except for the relative links.
No, the html fragments are being consumed by an angular app and injected into it so there's no iframe. The needs for the content are fairly simple so we are hoping to just work with the out of the box components. I'd rather not create custom components if I can avoid it
If you are including the HTML fragments in an iframe within an external application, then that page will be served from AEM in which case the externalizer helps.
if not another way I can think of is to handle that within your component renderer (HTML). When you read the image link and add that value in your html, make it as an absolute path (if you want to hardcode the domain or read it from the browser)