![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 9 months ago
Last modified 3 months ago
#64171 new defect (bug)
Cache failed requests to WordPress.org API endpoints
| Reported by: | peterwilsoncc | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | General | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: | performance |
Description
WordPress does not cache failed responses to various WordPress.org API endpoints (theme & plugin updates, etc).
When disconnected from a network this significantly impacts the performance of the dashboard as the requests are repeated as the user navigates:
- Main dashboard page: 2 requests leading to 20 second delay
- Ajax request to planet WP: 10 seconds delay, non blocking
- Plugin dashboard page: 2 requests to the same endpoint, 20 second delay
- Theme dashboard page: 2 requests to the same endpoint, 20 second delay
- Updates dashboard page: 6 requests (3 repeated), 60 second delay
- Site health dashboard page: 1 blocking request, 10 second delay
- Site health dotorg-communication endpoint: 20 second delay
- Site health debug page: 7 blocking requests, 70 second delay
Successful requests to most endpoints are cached for twelve hours, I think it would be wise to cache unsuccessful requests for some amount of time but probably a little less. 6 hours maybe???
For the site health screens, it may be wise to force uncached requests so up-to-date information is known but this ought to occur via the site's REST API so the requests are non blocking.
I picked this up while testing PR#7350.
To reproduce:
- Configure WordPress locally.
- Disconnect your computer from the network
- Run the WP CLI commands:
wp transient delete --all; wp transient delete --all --network; wp cache flush - Navigate around the WordPress admin
Note:
See TracTickets
for help on using tickets.
Hi, I checked this in my local setup by following the steps mentioned but I didn't notice any delays and was not able to reproduce this. My configuration (through LocalWP):
WordPress: 6.9.4
PHP: 8.2.30
Database: MySQL 8.0.35
I will investigate a bit more on it and update here.