Page MenuHomePhabricator

Remarkup links to objects in Phame break if a CNAME is set
Open, LowPublic


Make a blog in Phame and assign a CNAME, for example,

Next, make a post, and link to a repository (or another object) inside your post - for example, by mentioning rP or rPHU.

Now, if you look at these hyperlinks, they will be incorrectly routed to the blog CNAME, *not* the original Phabricator URL. In other words:

  • If your blog does not have a CNAME, rFOO links to /diffusion/FOO correctly.
  • If your blog *does* have a CNAME (, rFOO links to /diffusion/FOO - but this is wrong, because the relative URL is now, making the whole URL

The fix basically is:

  • If an object is referenced by a post,
  • AND a CNAME is set,
  • The hyperlink must instead point to the FQDN of the object, not the relative URL.

Event Timeline

thoughtpolice raised the priority of this task from to Needs Triage.
thoughtpolice updated the task description. (Show Details)
thoughtpolice added a project: Phame.
thoughtpolice added a subscriber: thoughtpolice.
chad triaged this task as Low priority.Oct 13 2014, 6:12 PM

Same issue with any link to Phabricator object, like tasks.

I suggest to raise a little bit the priority to normal with the following use case: a Phame installation to publish server maintenance notifications with links to the Phabricator tasks planned for this maintenance.

This issue is present also on - namely: try cklickin on any author inside Links point to instead of (should be @btrahan) and result in 404.

D12793 might be missing some edge cases with unusual objects but should fix at least 95% of this. Let me know if you run into more cases after D12793 lands.

Well, this is certainly fun drive with policies and edge cases...

on post preview everything looks perfectly and proper uris are generated... However fun is present when rendered on live post:

For sake of shortening lets define: phab is phabricator CNAME and blog means that in post rendered on blog uris reference from root instead of phab CNAME.

  1. Repos
    • Reference non-public repo - address in blog post points to phab (not to repo on phab)
    • Reference public repo - address in blog post points to phab/diffusion/repo (good)
    • reference public repo using {} - address points to blog/diffusion/repo (bad)
  2. Diffs
    • Reference non-public diff Either using D# format or {D#} format - no addres in blog post, not rendered name
    • reference public diff in either format - no render, no link.
  3. Tasks
    • reference non-public task in either format - no address in blog.
    • reference public task in T# format - nice proper link to phab/T#
    • reference public task in {T#} format - task name rendered properly, but uri points to blog/T#
  4. Projects
    • reference non public project - no link, rendered as "#project_name"
    • reference public project - link points to blog/tag/public_project instead of phab/tag/public_project
  5. Users
    • reference user - link points to blog/p/user

Generally: everything non-public is either not rendered or uses root-relative uris, currly blace syntax uses root-relative uris, diffs don't work at all :-) that's what I gathered from short testing.

Haha, sorry, figured I was doing slightly better than that. This should be easy to fix up.

  • The stuff above should be better now, but I'm not sure if I got everything. We should run through that list again.
  • The "Subscribers" and "Projects" links here do not link to the correct domain, and fixing them isn't trivial because they're event-driven extensions:

Screen Shot 2016-06-27 at 8.40.08 AM.png (339×882 px, 35 KB)

  • The blog description also doesn't use the right configuration yet (note bad link to blog domain for user profile):

Screen Shot 2016-06-27 at 8.42.08 AM.png (143×753 px, 20 KB)

In live comments, these links are bad offhand:

  • Badges.
  • Profile photos.
  • Links in remarkup.
  • Caret dropdown menu -> View Raw

Screen Shot 2016-06-27 at 8.51.19 AM.png (269×871 px, 36 KB)