Blog Stats block: not working for simple wpcom sites

[samiff]

The blog-stats block doesn't seem to be fetching stats data on simple wpcom sites. The block works on WoA sites with latest trunk however in my testing. While in the editor when adding the block, I see a request to https://public-api.wordpress.com/wpcom/v2/sites/<site-id>/blog-stats which returns an empty body, and thus the result shown in the editor is NaN hits and 0 hits on the frontend even for posts that have recorded stats data.

CC: @jeherve @kangzj @Aurorum who have been working on this block recently.

[Aurorum]

I'm afraid that I don't have permissions to test changes on WordPress.com Simple sites, so I'll need to leave this to others, but this is definitely strange. Presumably this might be being triggered, unless it's an issue with the endpoint?

https://github.com/Automattic/jetpack/blob/38a852aa0a90b79347e5d3a778c5f539bbf018ff/projects/plugins/jetpack/_inc/lib/core-api/wpcom-endpoints/class-wpcom-rest-api-v2-endpoint-blog-stats.php#L67-L69

[kangzj]

I took a look at the issue. /wpcom/v2/sites/<site-id>/blog-stats is forwarded to rest/v1.1/sites/<site-id>/posts/<post-id> by WPCOM_API_Direct for simple sites.

https://github.com/Automattic/jetpack/blob/c8f8b49223febed6392f3c2996e2adc9c5260cab/projects/packages/connection/src/class-client.php#L459

wp-content/lib/wpcom-api-direct/wpcom-api-direct.php on WPCOM seems only to register wpcom/v2 endpoints rather than rest/v1.1. And it's not working for /wpcom/v2/sites/<site-id>/top-posts either, which is currently showing random posts I believe.

cc @Automattic/jetpack-vulcan @jeherve

[filipanoscampos]

📌 Triage notes

Already triaged, marking it as such.

[Aurorum]

7952306-zen

[github-actions[bot]]

Support References

This comment is automatically generated. Please do not edit it.

• [ ] 7952306-zen
• [ ] 8391022-zen
• [ ] 8546916-zen

[mdtanjid0]

Got a similar issue here:

• [ ] 8391022-zen (needs to be notified once the issue is resolved)

[lsl]

What are the next steps to closing this issue? Should we hide this block on simple sites in the meantime?

I took a look at the issue. /wpcom/v2/sites/<site-id>/blog-stats is forwarded to rest/v1.1/sites/<site-id>/posts/<post-id> by WPCOM_API_Direct for simple sites.

@kangzj Where is this forwarding to a completely new route happening? Does this route just need registering in v2 on the dotcom side or is there more involved here? Thinking maybe it just needs adding to wp-content/rest-api-plugins/endpoints/stats.php?

[dev-sabbir]

Another issue here: 8546916-zd-a8c

[escapemanuele]

This should have been fixed in https://github.com/Automattic/jetpack/pull/38564, and following work continued in https://github.com/Automattic/jetpack/pull/38610

[Aurorum]

@escapemanuele I don't think that this issue has been resolved yet - those PRs simply hide the block for Simple sites, whereas ideally the block should work for them and the endpoint should be fixed.

[lsl]

When suggesting to just hide it, it was my impression this block never worked for simple sites? Was that not quite right?

@Automattic/red feel free to reopen and pick this up if you're able to prioritize a real fix.

@Aurorum sorry if this feels like a bit of a punt, WordPress.com is working through a backlog [Pri] High bugs and broken user experiences. Preventing users from inserting blocks that don't work is the priority for me, ensuring the block remains available is less of a priority compared to some of our other open bugs we need to fix ahead of this.

[Aurorum]

When suggesting to just hide it, it was my impression this block never worked for simple sites? Was that not quite right?

No, I believe your understanding here is perfectly correct. I agree that hiding the blocks until they’re fixed makes sense!

Preventing users from inserting blocks that don't work is the priority for me, ensuring the block remains available is less of a priority compared to some of our other open bugs we need to fix ahead of this.

Totally understand! I think it’d be nice to have an open issue for this so it can be fixed eventually though and any user requests can be tracked, even if that’s relatively low priority. The code in the actual block should work, but I think the endpoint needs to be loaded somewhere (but that’s not open-source nor can I test on Simple site environments, so am afraid I’ll need to leave that for someone else).

[kangzj]

Thanks for disabling the block for simple sites. I tried to fix it but got stuck when it came to the many API forwarding on dotcom. I'll take another look in our next maintenance sprint. Thanks all!

[kangzj]

Closing this one and will track with https://github.com/Automattic/jetpack/issues/34506