Closed hacdias closed 2 years ago
At least one of these queries will be to check what post types to display on the homepage.
At least one or two of these will then be checking what properties your post types support, so Micropublish can show all the properties that are relevant to edit.
It used to be that q=config
was cached in Micropublish's session state, but the size of the q=config
was starting to get quite large (across many peoples' implementations) so I believe we removed that, hence the multiple hits.
That being said, I think Barry should be able to see if there's anything else in there
I would expect only one call for /micropub?q=config
. There's 9 for the same page request. Maybe the data could be passed along in the code somehow.
Hmm, that's a bit too noisy. Jamie's right: config was getting too large to be stored in a cookie (#76) so Micropublish requests this from your endpoint when it needs it, but this is probably excessive.
My alternative approach was to use something like Redis to cache the config response. I'll raise an issue and link it here.
@hacdias Did you see this issue was fixed? It should mean there are many fewer requests to your server.
@barryf it is much better, indeed! Thanks!
Every time I do anything, Micropublish.net makes dozens of GET requests to my Micropub endpoint, until one returns 404 and then it proceeds normally. I'm not sure if this is an issue on my implementation or not.
If I open Micropublish.net, click on "Note", it happens. Quill and others do not have this behaviour.
This is the list of requests: