append wrong path

Currently, if using page.Body() in widget script, it will return a non-fully-qualified absolute URL for embedded images. In this case, that would be "/resized-image/__size/940x0/__key/communityserver-wikis-components-files/00-00-00-02-26/image.jpg". It shouldn't be prepending file://, and that may just be a side-effect of post-processing in the exported file or the default OS behavior of clicking on a link without any domain in Word.

That said, I understand that a path of "/resized-image/etc" isn't what you want either. Currently, only the REST endpoints for content will convert embedded medias URLs to be fully qualified. So, loading this same wiki page over REST will include the domain.

I'm logging a bug to address this as an option to the Body() method. As a workaround, you could use a regular expression to approximate this behavior. 

As an aside, what role is velocity playing in exporting to Word? This may be more easily accomplished with a plugin than a widget.

Currently, if using page.Body() in widget script, it will return a non-fully-qualified absolute URL for embedded images. In this case, that would be "/resized-image/__size/940x0/__key/communityserver-wikis-components-files/00-00-00-02-26/image.jpg". It shouldn't be prepending file://, and that may just be a side-effect of post-processing in the exported file or the default OS behavior of clicking on a link without any domain in Word.

That said, I understand that a path of "/resized-image/etc" isn't what you want either. Currently, only the REST endpoints for content will convert embedded medias URLs to be fully qualified. So, loading this same wiki page over REST will include the domain.

I'm logging a bug to address this as an option to the Body() method. As a workaround, you could use a regular expression to approximate this behavior. 

As an aside, what role is velocity playing in exporting to Word? This may be more easily accomplished with a plugin than a widget.