[wp-trac] [WordPress Trac] #47320: Site Health: Call to API with $_COOKIE and PHPSESSID

[WordPress Trac]

#47320: Site Health: Call to API with $_COOKIE and PHPSESSID
----------------------------+------------------------------
 Reporter:  matthieumota    |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  5.2
 Severity:  trivial         |  Resolution:
 Keywords:  site-health     |     Focuses:
----------------------------+------------------------------

Comment (by netweblogic):

 Replying to [comment:5 matthieumota]:
 > I think it will be better to close session in the plugin code base no ?
 Everybody get this issue I think...

 I think what @Clorith means is the problem with 'fixing' the site check,
 in this case, is that the way we're using sessions might be 'wrong'.
 Other parts of core might do the same thing and therefore our code would
 cause problems there too, hence the site check giving a warning of the
 potential problem.

 I'd be interested to know what other instances a loopback like this occurs
 in core, requiring this check to also maintain session data the same way.
 The only thing that springs to mind is maybe multiple modifications in the
 block editor triggering multiple async API calls. Crons like updates for
 example I believe are fired off independently without any user/session
 data?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47320#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform