Support #13379

Commenting issue with Mapped Domain (Using Jetpack)

Added by scott voth over 1 year ago. Updated over 1 year ago.

Priority name:
Category name:
Domain Mapping
Target version:
Start date:
Due date:
% Done:


Estimated time:


(This is different from but could possibly be related)

Sissel has this Commons site: that is mapped to and is having commenting issues. She wants to accept comments from both Commons members and the general public. I spent some time trying to figure out when it works and when it doesn't. It seems that if you are using the mapped URL ( and are not logged on, it works. When you are logged to the site (and maybe are a member of the site??), the URL is****. When you try to comment, you get user error -- email and name not provided. There is no place to provide these fields, and you get stuck after typing in your comment. See attached.

She is using Jetpack to add subscribers to the site. It seems like her discussion settings are okay.

comment 1.png (123 KB) comment 1.png scott voth, 2020-09-24 05:45 PM
comment 1 error.png (98.9 KB) comment 1 error.png scott voth, 2020-09-24 05:45 PM

Related issues

Related to CUNY Academic Commons - Bug #13455: Switch from WPMU Domain Mapping to MercatorResolved2020-10-10


#1 Updated by Boone Gorges over 1 year ago

  • Category name changed from WordPress (misc) to Domain Mapping
  • Assignee set to Raymond Hoh

Thanks for the detailed report, Scott.

I found a GitHub thread discussing this problem: The upshot of that thread is that, in certain cases, the WP authentication cookies are not being properly sent with the request. In the case of the GH thread, I think the problem is due to an HTTPS/HTTP mismatch, where certain cookies are marked HTTPS-only so aren't being sent over non-SSL. In the case of this CAC ticket, it appears that the problem is with cross-domain requests: the auth cookies aren't properly being sent because you're viewing but are attempting to send a comment to

Ray, do you have any ideas about how to work around this issue? I see a few different strategies:
1. When viewing a comment form, make sure that the form action always matches the current URL (mapped vs unmapped). Sounds pretty straightforward, but I don't know how this will work when using Jetpack comments, which seem to do some weird juggling of requests to
2. On sites with mapped domains, don't allow commentable posts to be viewed at the non-mapped URL. That is, when viewing something like, redirect to the corresponding mapped URL. This should guarantee a match.

#2 Updated by scott voth over 1 year ago

Any update on this one?

#3 Updated by Boone Gorges over 1 year ago

Ray mentioned on a recent dev call that he had some ideas about how we might approach this, but I forgot what they were :) Ray, could you chime in?

#4 Updated by Raymond Hoh over 1 year ago

  • Related to Bug #13455: Switch from WPMU Domain Mapping to Mercator added

#5 Updated by Raymond Hoh over 1 year ago

I think a simple workaround might be to try disabling Jetpack Comments under:

Then, comments should work as expected. Scott, can you ask Sissel to try that?

To be compatible with Jetpack Comments and mapped domains, Boone's note about redirecting to the mapped domain sounds correct. However, we made some design decisions back in #5525 to redirect logged-in users to the Commons subdomain due to HTTPS.

Since we now use Let's Encrypt, we shouldn't need to redirect back to the Commons subdomain, but we need to ensure that logged-in users to the Commons are also logged into their mapped domain. To solve this, I'm looking into switching our usage of the WPMU Domain Mapping plugin to Mercator in #13455.

#6 Updated by scott voth over 1 year ago

Awesome workaround Ray! Since I have admin rights to her site, I have implemented and commenting seems to work in both logged-in and logged-out state. Thanks! I have also asked her to verify.

#7 Updated by Boone Gorges over 1 year ago

  • Status changed from New to Resolved
  • Target version set to Not tracked

On the basis of this, I think we can close the current ticket. The broader issue will be addressed with #13455.

Also available in: Atom PDF