Post Notification Emails: handle Like clicks on WoW sites#48021
Post Notification Emails: handle Like clicks on WoW sites#48021taipeicoder merged 7 commits intotrunkfrom
Conversation
) Atomic/WoW sites do not include the Like button in post-notification emails because the Simple-side `like-button.php` template_redirect handler does not exist on Atomic. Adds a small jetpack-mu-wpcom feature that proxies the email's like link to the new wpcom/v2/email-like endpoint (Automattic/wpcom#211090) via Client::wpcom_json_api_request_as_blog(), then redirects the visitor to the post permalink — restoring parity with Simple sites and unblocking the re-landing of Automattic/wpcom#210242. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖 Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage SummaryNo summary data is available for parent commit cfe2e49, so cannot calculate coverage changes. 😴 If that commit is a feature branch rather than a trunk commit, this is expected. Otherwise, this should be updated once coverage for cfe2e49 is available. Coverage check overridden by
I don't care about code coverage for this PR
|
The wpcom/v2/email-like endpoint from Automattic/wpcom#211090 is site-specific (wpcom_is_site_specific_endpoint = true) and expects post_id (not postid) in the body. Resolve the blog id from Jetpack_Options and prefix the request path with /sites/<blog_id>/, matching the pattern used by class-wpcom-rest-api-v2-endpoint-jetpack-launch-site.php:60. Without this, calls returned rest_no_route (verified on taipeiwoadev). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Switch from Jetpack_Options::get_option( 'id' ) to the package's own get_wpcom_blog_id() helper in utils.php. Matches the idiom used by replace-site-visibility.php:244 and also avoids a hard dependency on the Jetpack class being loaded (the helper reads jetpack_options directly via get_option()). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… call Verifies that wpcom_handle_post_like_from_email() POSTs to the site-scoped /wpcom/v2/sites/<blog_id>/email-like endpoint with post_id/like_actor/ like_hmac in the body and redirects the visitor to the post permalink. Regression guard for the path and body-shape drift we hit against Automattic/wpcom#211090 during iteration. Uses #[RunInSeparateProcess] to define IS_ATOMIC so get_wpcom_blog_id() returns a test blog id, mocks the HTTP call via pre_http_request, and throws from a wp_redirect filter to escape the handler before its exit; runs. The redirect-escape exception lives in its own file to satisfy Generic.Files.OneObjectStructurePerFile. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The Jetpack Connection mocking required for Client::wpcom_json_api_request_as_blog is too complex for the value it provides. The handler has been verified manually against a staging site with wpcom#211090 deployed. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Blog IDs are always integers — no characters to encode. Matches the pattern used by wpcom-dashboard-widgets.php and avoids PhanTypeMismatchArgumentInternal. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…on.php These are wpcom internals that don't need to be documented in the jetpack-mu-wpcom handler. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Fixes DOTCOM-16569
Proposed changes
post-like-from-emailfeature injetpack-mu-wpcomthat hookstemplate_redirectat priority 1.?like=1&postid=…&like_actor=…&like_hmac=…), then proxies them to the site-scopedwpcom/v2/sites/<blog_id>/email-likeendpoint viaClient::wpcom_json_api_request_as_blog()so the HMAC validation andLikes::set_post_like()happen on wpcom infrastructure.post_id(matching the wpcom endpoint's expected field name),like_actor, andlike_hmac.IS_WPCOMto avoid double-firing if jetpack-mu-wpcom is loaded inside wpcom.get_wpcom_blog_id()fromutils.phpto resolve the blog ID, matching the pattern used byreplace-site-visibility.php.Jetpack_Mu_Wpcom::load_features()(alphabetical, unconditional — the email recipient is anonymous, so the handler must run for visitors who are not logged into wpcom).Related product discussion/links
Does this pull request change what data or activity we track or use?
No. This PR only forwards an HMAC-signed
(post_id, like_actor, like_hmac)triple to the wpcom endpoint — no new tracking, telemetry, or PII flow is introduced on the Jetpack side.Testing instructions
Requires Automattic/wpcom#211090 to be deployed first (the
wpcom/v2/sites/<blog_id>/email-likeendpoint must exist).error_loglines around theClient::wpcom_json_api_request_as_blog()call to see the wpcom response.?like=1&postid=<post_id>&like_actor=<wpcom_user_id>&like_hmac=DEADBEEFappended.HTTP 403 invalid_hmac(bad HMAC correctly rejected); no PHP errors.wpl_generate_like_hmac( $post_id, $user_id )on a wpcom sandbox shell and substitute it into the URL — the like should be recorded.Negative paths
issetcheck — no wpcom call, page renders normallyIS_WPCOMguard bails — the like is already handled on wpcomget_wpcom_blog_id()returns false): handler bails before making any callDeploy order