Support #13379
closedCommenting issue with Mapped Domain (Using Jetpack)
0%
Description
(This is different from https://redmine.gc.cuny.edu/issues/13374 but could possibly be related)
Sissel has this Commons site: https://newsliteracymatters.commons.gc.cuny.edu/ that is mapped to https://newsliteracymatters.com 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 (https://newsliteracymatters.com) 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 https://newsliteracymatters.commons.gc.cuny.edu/****. 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.
Files
Related issues
Updated by Boone Gorges about 4 years 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: https://github.com/Automattic/jetpack/issues/15696 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 newsliteracymatters.commons.gc.cuny.edu but are attempting to send a comment to newsliteracymatters.com.
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 https://jetpack.wordpress.com/jetpack-comment/.
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 https://newsliteracymatters.commons.gc.cuny.edu/2020/09/25/q-it-feels-as-if-important-stories-can-fade-to-obscurity-fairly-quickly-and-be-replaced-by-something-more-eye-catching-is-this-ever-done-on-purpose/, redirect to the corresponding mapped URL. This should guarantee a match.
Updated by Boone Gorges about 4 years 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?
Updated by Raymond Hoh about 4 years ago
- Related to Bug #13455: Switch from WPMU Domain Mapping to Mercator added
Updated by Raymond Hoh about 4 years ago
I think a simple workaround might be to try disabling Jetpack Comments under:https://newsliteracymatters.commons.gc.cuny.edu/wp-admin/admin.php?page=jetpack#/discussion
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.
Updated by scott voth about 4 years 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.
Updated by Boone Gorges about 4 years 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.