Although brittle in that it only corrects the link structure we specifically reference, the following approach does have the effect of re-basing the URL's inside the content of the posts, so that they get their server name pre-pended and the images/links display & work as expected:
What
When viewing the contents of a SharePoint blog post in a notification email, for example, images and links will be broken because their URL's are missing the servername. For example; Image is trying to go to: http://blogs/Lists/Posts/Attachments/777/myimage.png instead of https://go.mysharepoint.com/blogs/Lists/Posts/Attachments/777/myimage.png ..and so displays as a nasty red X (or nothing at all) in your users email client.
So What
So, Nintex to the rescue:
In the workflow that emails our staff notifications of the new blog post (including the blog post content), we do some string replacements on the body of the email:
1. Create a new Muliline Text variable called vOutputText2. Create a new Regular Expression Action in your Nintex workflow: Pattern (ignore case): src="/blogs/Lists/ Operation: Replace Text Replacement Text: src="http://go.mysharepoint.com/blogs/Lists/ Store Result In: vOutputText 3. Rinse and repeat step two for each variation of links you encounter in your posts. You may find that authors consistently use other SharePoint Document Library, List and Site link patterns in their posts. You should add a new regex for each one of those.4. Set the vOutputText to be the content of your notification email action.5. Fire up the workflow and the email containing your blog post content should display the rebased URLs you addressed as expected.
Now What
Emails sent out now will have full URL's in the elements you addressed and thus the links and images should work properly when the end user views the email in their client. That being said - as mentioned this is a basic & brittle approach - chances are other link patterns will sneak in there and you'll still get broken links when people reference new parts of your SharePont site that you didn't account for. If you care to go deeper into Regular Expressions, the Nintex Regular Expression action is fully capable of supporting more advanced expressions that would be able to rebase URL's that are missing their root domain name and not get tripped up on differences in subfolder paths. Since this is a Nintex Action lesson and not a Regular Expression lesson, I will refer you MSDN for learning more about Regular Expressions and to the great program RegexBuddy for developing and testing your fabulous new bullet-proof Regex's.