[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:  SergeyBiryukov
     Type:  defect (bug)        |      Status:  closed
 Priority:  normal              |   Milestone:  5.5
Component:  Site Health         |     Version:  5.2
 Severity:  trivial             |  Resolution:  fixed
 Keywords:  site-health commit  |     Focuses:
--------------------------------+-----------------------------

Comment (by cfm168):

 Replying to [comment:19 netweblogic]:
 > @cfm168 This is a regular wp snippet, you could add it to your theme's
 functions.php file for example.
 >
 > Replying to [comment:18 cfm168]:
 > > Hi @netweblogic,
 > >
 > > Where to add these codes? I want to try it. Thanks in advance!
 > >
 > > Replying to [comment:4 netweblogic]:
 > > > @Clorith thanks for the feedback... upon some further research,
 making use of session_write_close() and keeping sessions open/locked only
 when we know it'll be needed for writing seems to have done the trick and
 probably a better approach anyway.
 > > >
 > > > For anyone with a similar problem, maybe this explains it better, my
 previous snippet failed the site health tests, this one doesn't:
 > > >
 > > > {{{#!php
 > > > <?php
 > > > add_action('init', function(){
 > > >     session_start(); //this loads variables to $_SESSION for reading
 > > >     if( empty($your_plugin_needs_session_saving) ){
 > > >         session_write_close(); //other plugins can restart a session
 again via session_start()
 > > >     } // if session writing is needed, close session after writing
 is done
 > > > });
 > > > }}}
 > > >
 > > > I'm not sure if this would work for all use cases, but in my case I
 only need to write to sessions when particular actions are taken, avoiding
 (hopefully) all situations where there'd be a conflict due to session
 locking.
 > > >
 > > > The only argument I'd make towards it possibly being a bug in Site
 Health is that in my case, until now, my plugin session handling worked
 fine with all other WP functionality (at least, I've not been made aware
 of any issues).

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