jetpack-mu-wpcom: Limit comment like requests to edit-comment and gate by module

[ebinnion]

Problem statement

This functionality was initially added for simple sites in #41475 and later for WoW sites in #42300. When the functionality was added for WoW sites it resulted in many API calls that occurred on each page load that includes comments. I initially noticed this on the wp-admin of my site.

But, after investigating the code, the API calls were also present on the frontend of the site.

Proposed changes:

The solution that I am proposing is:

• Move existing functions into a singleton pattern class.
• On WoW sites, only load the functionality if the comment-likes module is enabled.
• Only hook on comment_class if we're in the admin to minimize frontend requests.
• Cache the API requests via transient.

Potential future changes

I'm not a fan of making $x number of requests, one for each comment. I think the way that we'll solve this in the future is probably by hooking in when the comments table is being rendered and making a batch API request. If we take this approach, we'd request early, store in an array in the singleton class, and then pull from that array as we render.

Further, we could consider expanding the is_comment_likes_enabled method to include WPCOM simple sites. Deferring for now because of the minimal performance implications.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

• Ensure that you have a simple and WoW site with comments.
• On a simple site, ensure that comment like rendering at /wp-admin and /wp-admin/edit-comments.php continues to function.
• On a WoW site, while proxied so that you have the debug bar, test /wp-admin and /wp-admin/edit-comments.php as well.
• Before this change, you'll notice on these pages that you have multiple http calls for the comment likes endpoint. You can attempt to disable the comment likes module in Jetpack settings and the http calls will persist.
• After this change, check the same URLs and you should notice that after a refresh, the cache will be primed and the http calls go away. You can then test the network requests don't show when comment likes are disabled by running wp transient delete --all && wp jetpack module deactivate comment-likes over SSH and then loading the same URLs above.

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (WordPress.com Site Helper), and enable the update/jetpack-mu-wpcom-improve-comments-performance branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack-mu-wpcom-plugin update/jetpack-mu-wpcom-improve-comments-performance

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

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:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Boost plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Search plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Social plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Starter Plugin plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Protect plugin:

• Next scheduled release: September 1, 2025

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Videopress plugin:

No scheduled milestone found for this plugin.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

---

Wpcomsh plugin:

• Next scheduled release: Atomic deploys happen twice daily on weekdays (p9o2xV-2EN-p2)

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/packages/jetpack-mu-wpcom/src/features/wpcom-comments/wpcom-comments.php	0/71 (0.00%)	0.00%	16 💔

Full summary · PHP report · JS report

_{If appropriate, add one of these labels to override the failing coverage check: Covered by non-unit tests Use to ignore the Code coverage requirement check when E2Es or other non-unit tests cover the code Coverage tests to be added later Use to ignore the Code coverage requirement check when tests will be added in a follow-up PR I don't care about code coverage for this PR Use this label to ignore the check for insufficient code coveage.}

[rcrdortiz]

Since we’re now caching requests, the likes feature isn’t working as expected. From the wp-admin comments screen, I can like a comment, but after reloading it appears as if I didn’t. Here’s a video demonstrating the issue.

likes-broken.mp4

[ebinnion]

Thanks for the review @rcrdortiz. I've just pushed a fix that address the cache busting.

[rcrdortiz]

Sorry, I didn't do the complete review on Saturday. Just wanted to mark this PR so that it didn't get merged.

The feature should be enabled regardless of whether the module is enabled. This code was created when we untangled the comments screen. To achieve feature parity with Calypso, we need to always enable the "Liked by me" functionality on all WPCom Atomic sites.

[rcrdortiz]

I'm not a fan of making $x number of requests, one for each comment. I think the way that we'll solve this in the future is probably by hooking in when the comments table is being rendered and making a batch API request. If we take this approach, we'd request early, store in an array in the singleton class, and then pull from that array as we render.

There’s an endpoint Calypso used to use that already returns this information, but it wasn’t accessible through wp-admin and was out of scope when we implemented feature parity. Now that Calypso comments aren’t available to our customers, maybe we could revisit and update the API.

[ebinnion]

Thanks. I've changed the expiration to 900 seconds, or 15 minutes, which I think is a reasonable cache timeout for this scenario.

[rcrdortiz]

We need to remove this. Any user on WPCom should be able to like comments from wp-admin regardless of whether Jetpack comment-likes is enabled or not.

[ebinnion]

I don't think that I agree with this. But, I'll consider it a bit further. 😄

[rcrdortiz]

Thanks. I've changed the expiration to 900 seconds, or 15 minutes, which I think is a reasonable cache timeout for this scenario.

Consider the scenario where a user goes to wp-admin → Comments, opens a post, likes a comment, then returns to wp-admin and sees their like hasn’t been registered. This issue will recur regardless of cache duration unless we actively invalidate the cache after a like action. Could you help me understand how introducing a 15-minute cache window would mitigate this problem?

[ebinnion]

It doesn't directly mitigate this issue. It does definitely minimize the impact. Not having caching of the requests is not an option in my opinion. Otherwise, we have greater than 1 second of http requests on every comments page load.

[rcrdortiz]

Hey @ebinnion , thanks again for iterating on this! I wanted to recap where we landed and propose the next steps, so we’re all on the same page:

---

1. Preserve Calypso-style comment likes in wp-admin

• ⚙️ This isn’t Jetpack’s standalone Comment Likes module—it’s the Calypso-derived “like from the admin screen” feature.
• ✅ We want to keep it live for all WordPress.com users (i.e. you shouldn’t be able to disable likes in wp-admin).

2. No front-end caching in wp-admin

• 🚫 The comments iframe lives on WordPress.com (outside our cache-control), so caching i_like here leads to stale counts.
• 🔄 We’ll continue to fetch likes live, exactly as Calypso does.

3. Batching via the WP.com comments endpoint

• We have a bulk endpoint that we can try to adapt:

  GET https://public-api.wordpress.com/rest/v1.1/sites/{siteId}/comments

[ebinnion]

I've thought about it some bit, and I think that there's a decent stopping point for now by just removing the transient caching. Only making the requests on the edit-comments.php screen and allowing disabling the requests by checking for the comment-likes module provides a significant improvement.

Transient caching removed.