Pages listing pages fails to render due to requesting unused data about each Post

[getdave]

Before reading on please see p2EDhh-18T-p2.

Essentially on sites with very large Pages and lots of revisions/attachments the Pages page in the Calypso UI can fail due to a 500 error from the REST API. If it doesn't fail then it can take upwards of 10s to load the view.

Currently Calypso makes a blanket request to the endpoint for all data relating to each Page. However, most of the data isn't required for this particular view. Instead, we should explore requesting the specific subset of the data required to display a list of Pages (eg: ignore revisions, attachments...etc). Requesting a subset of data protects somewhat against the 500 error which may be due to memory usage.

See the p2 post for more details on how to filter the requests to only return particular fields for each Page.

Steps to reproduce

This is difficult to reproduce. You should see the p2 post for an example site that will cause the error to manifest itself.

What I expected

The Pages listing page to render a list of Pages quickly and consistently.

What happened instead

The Pages list page either:

• Took +10s to load.
• Failed to load due to a 500 error from the REST API

Browser / OS version

All

[mreishus]

When I navigate to the posts page in calypso (example url: http://calypso.localhost:3000/posts/example.com), I see the API request fired off to //public-api.wordpress.com/rest/v1.1/sites/12345678/posts include &number=20 as a parameter, which caps the number of results returned to 20, even if there are more. When we were debugging earlier, the public-api urls we were testing did not include &number=20. Is there a way for a user to hit the /v1.1/sites/12345678/posts endpoint without including a &number=20 parameter?

[davemart-in]

This seems like it's larger than a simple Janitorial issue. Sending this one back to the Ajax team to prioritize in their backlog.

[github-actions[bot]]

This issue is stale because it has been 180 days with no activity. You can keep the issue open by adding a comment. If you do, please provide additional context and explain why you’d like it to remain open. You can also close the issue yourself — if you do, please add a brief explanation and apply one of relevant issue close labels.

[davipontesblog]

@tjcafferkey, is there to prioritize this in the next janitorial run? See p2EDhh-18T-p2#comment-6586 for more context. Thanks!

[tjcafferkey]

@obenland I'm moving this to the Manage Backlog so there's more visibility on it, and to ensure it gets properly triaged. Also to make sure it's not overlooked/missed in our teams backlog as this is getting phased out.

[bobmatyas]

3983254-zen is another more recent example of this happening.

[davipontesblog]

Moving back to triaging board since it's been reopened.

[kwight]

@obenland FYI fo visibility, @taggon for flow patrol consideration.

[retnonindya]

Hi team! I would like to ask your assistance on this user's issue: 3983254-zd-woothemes (refer to @bobmatyas' comment above.)

The user requested us to assist on trashing/deleting the problematic page. Problem is, we can't trash/delete it.

I tried using Calypso-display and WP Admin-display, both to no avail.

When in Calypso-display, there will be a quick "Trash is failed" notification; then the page disappeared, as if the Trash process is successful. However, if we refreshed the Pages page again, the page reappears under Published.

When in WP Admin-display, it will lead to blank page with Error 500 warning.

In this case, how do we delete the page from the website? Since this website is a simple site (no plugin installed and not on Business plan,) I don't have access to PHPMyAdmin to delete the page. Thank you in advance 🙇

[retnonindya]

So sorry for the direct ping here since I noticed no movement at all 🙇‍♂️

@kwight, @taggon, @obenland -- I'm so sorry for the ping. Can you check or share some steps on how to trash a page (per above comment) as it's not possible to do so from Calypso and WP Admin? I'd figure we need developer's sandbox access for this.

I tried:

• Trashing the page using Calypso,
• Trashing the page using WP Admin, and...
• Trashing the page using REST API method

All of them to no avail.

Since this is a public repo, I'm not putting the user information here. Feel free to let me know if there are better places to do so. Thank you 🙏

[kwight]

@retnonindya I was able to force delete the problematic old home page – from what I can tell, it was a huge amount of content, which I guess was contributing to out-of-memory errors. It no longer shows up in WP Admin, and everything seems to be working well for that user.

[retnonindya]

@kwight THANK YOUUUUUUUUU! ✨ Thank you so much thank you thank you thank you!

[davipontesblog]

Is this something that can be closed now? Seems to be an isolated event for now.

[kwight]

I only fixed an individual user's semi-related problem – the OP issue remains (requesting huge amounts of page data can cause failing UI renders).