Cms: Not being able to interrupt loading the plugin store..
Description
It would be amazing if we could interrupt the loading of the plugin store, as of now, if you accidentally click the plugin store you have to wait till it's loaded completely before you can navigate to a different page.
It might sounds like a silly and small problem, but as my internet connection isn't the best, which means it sometimes takes around 20 seconds before the plugin page is loaded. And unfortunately I misclick it a lot. Easily 20 times during a full working day.
To put this in perspective:
20 seconds every misclick =
- 06:40 a day.
- 33:20 a week.
- 26:24:00 a year (48 weeks, 4 are holiday)
That means on yearly basis I am waiting on a request for 26 hours and 24 minutes!
Steps to reproduce
- Log in to craftCMS
- Accidentally click plugin store
Additional info
- Craft version: Craft 3.0 or up
- PHP version: 7.3
- Database driver & version: 10.3.17-MariaDB-0+deb10u1 Debian 10
- Plugins & versions: CraftCMS core
Mikesnoeren
All 6 comments
This came up on Twitter recently, and we’ve been looking into how to fix it ever since. It turned out it was a side effect of how the Plugin Store loads its data – rather than the JS making the API request directly, it sends a request to the Craft install, which then makes the actual API request, and then responds to JS with the API’s response.
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ │ │ │ │ │
│ │ │ │ │ │
│ │────▶│ │────▶│ │
│ JavaScript │ │ Craft │ │ API │
│ │◀────│ │◀────│ │
│ │ │ │ │ │
│ │ │ │ │ │
└──────────────┘ └──────────────┘ └──────────────┘
Problem with that is that a lot of environments (especially local) have a small limit (often 1) on the number of concurrent connections that can be handled. And when you navigate away from a page in a web browser, the web browser doesn’t immediately close any of the existing requests it’s loading – until the subsequent page request has received a response. And if that next page request is to Craft, and Craft is tied up being the middleman for this API request, then it won’t be able to process the subsequent page request until the API request is completed.
So… there are a couple things we are doing to improve things. First is to stop using Craft as a middleman for JS API requests, unless there’s a good reason to (i.e. the API response is going to have an effect on Craft’s state.) Also we are splitting up the API requests into much smaller, more cacheable chunks, so A) there’s a much better chance that the response comes back immediately thanks to being cached, and B) even if it’s not cached, there won’t be nearly as much data to generate in the first place.
We expect these changes to be ready in the next 2-3 weeks.
brandonkelly
on 1 Nov 2019
Great to see this is getting its deserved attention!
Mikesnoeren
on 1 Nov 2019
@brandonkelly interesting problem and analysis, caught the eye.
Digging a little earlier in morning, and since you're using Axios already, seems you may be able to back out right away now that you're going to do it all in the browser.
http://axios-js.com/docs/index.html#Cancellation
There's some interesting background perhaps via https://blog.bloomca.me/2017/12/04/how-to-cancel-your-promise.html and
https://medium.com/@bramus/cancel-a-javascript-promise-with-abortcontroller-3540cbbda0a9, if the straightforward Axios implementation makes these kind of side notes.,
On the humor side, ran into this mis-type on another article this morning: 'use-aster-free bug'...
narration-sd
on 1 Nov 2019
Yes, sorry, that is another part of this. Once the JS is pinging the API directly, we will be able to start cancelling the request if the user is trying to navigate away from the page.
brandonkelly
on 1 Nov 2019
cool...
narration-sd
on 1 Nov 2019
We just released Craft 3.3.16 with a fix for this!
- All plugin store API requests now go through JS rather than PHP, so there’s no chance of the server getting locked up if its max connections is reached as a result of an API request.
- Plus, the individual API requests are faster now, as all plugin data loaded on demand rather than in one big bulky request up front, combined with better caching on the API end.
- Plus the plugin store will actively cancel current API requests when the user navigates away from the current page / category.
brandonkelly
on 22 Nov 2019
Related issues
leigeber
·
3Comments
michel-o
·
3Comments
mccombs
·
3Comments
mattstein
·
3Comments
timkelty
·
3Comments
Most helpful comment
This came up on Twitter recently, and we’ve been looking into how to fix it ever since. It turned out it was a side effect of how the Plugin Store loads its data – rather than the JS making the API request directly, it sends a request to the Craft install, which then makes the actual API request, and then responds to JS with the API’s response.
Problem with that is that a lot of environments (especially local) have a small limit (often
1) on the number of concurrent connections that can be handled. And when you navigate away from a page in a web browser, the web browser doesn’t immediately close any of the existing requests it’s loading – until the subsequent page request has received a response. And if that next page request is to Craft, and Craft is tied up being the middleman for this API request, then it won’t be able to process the subsequent page request until the API request is completed.So… there are a couple things we are doing to improve things. First is to stop using Craft as a middleman for JS API requests, unless there’s a good reason to (i.e. the API response is going to have an effect on Craft’s state.) Also we are splitting up the API requests into much smaller, more cacheable chunks, so A) there’s a much better chance that the response comes back immediately thanks to being cached, and B) even if it’s not cached, there won’t be nearly as much data to generate in the first place.
We expect these changes to be ready in the next 2-3 weeks.