Macros are disabled in Phame posts, via markup engine. This originated in D2202.

It may have been copy/pasted from Feed (which disables macros for reasons similar to T11845) or might have just been a product decision aimed at aligning Phame more with serious corporate blog use cases.

I think there's no reason to prevent use of macros in Phame posts in the modern product, which targets both internal and external use cases. It's also not obvious why macros wouldn't work in Phame, while it's more obvious why we no longer allow autoplay looped audio in Feed.

@chad, any thoughts here or better recollection about why we disabled them? If you don't have any better reasons than I do, I believe fixing this is just an issue of removing this line:

https://secure.phabricator.com/source/phabricator/browse/master/src/infrastructure/markup/PhabricatorMarkupEngine.php;4c7d464f8bf2627ef7455596fde2ae5667e67a57$356

I blame the fun police.

I can fix if it's one line, I just assumed it was something super hard with external urls or something.

I guess we actually have to test this use case:

• No security.alternate-file-domain configured.
• Blog on an external domain.

That might incorrectly link to /file/data/... which won't exist. If so, the Macro remarkup rule needs to respect the uri.full option.

That is, the problem would be:

• You visit blog.install.com.
• It generates links to /file/data/..., which won't exist (that path isn't served by blog.install.com).
• It should be generating links to https://real-phabricator.install.com/file/data/... instead.

@epriestley, I wouldn't mind testing that scenario out this weekend (I'll have to change a couple of domain name settings to create the scenario, but that's easily undone).

In the meantime, you should be aware that I changed that one line from false to true in my copy of Phabricator, but Macros still aren't rendering in Phame. (I also tried removing that line, no dice.)

Remarkup is cached, so you'll need to run bin/cache purge --purge-remarkup (or make an edit, or create a new post) to purge the cache.

Ah! That fixed it, thanks @epriestley. I'll let you know once I test out that configuration.

@epriestley, I tested out the scenario with the change applied.

• Turned off Alternate File Domain.
• Set custom domain name for blog.
• Set Phame and blog visibility to Public.
• Created post in blog with macro.
• Published post.
• Viewed post "live" - the post displays, but the image URL is incorrect, pointing to the blog URL (and therefore giving a 404).

This is the case, regardless of whether the parent URL is set on the blog.