You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PHP Sessions are not used within WordPress core, and a few years back, I've talked with @2ndkauboy about wether to use them in a plugin or not. He advised against it, but did not really know why you should avoid using it.
In a recent project I found an objective reason why.
On the site I'm working on, which is quite big, I had to optimize long delays within the backend. In the end there were two major issues that I fixed, that improved the backend performance. Number one, was related to the vast amount of attachments. Number two was about session_start().
In my case Ninja Firewall is using php session, this becomes a problem as soon as multiple requests are fired in short succession, and when one request lasts a little longer.
And when opening the block editor it is absolutely normal that 5-15 requests are fired in the instance that you open the editor.
After profiling with xhprof I saw the following results (simplified)
Request 1: 9s due to a bunch of curl requests.
Request 2: 9.3s, 9s of it just waiting for session_start() and 0.3s for the actual execution
Request 3: 9.6s, 9.3s waiting for session_start()
Similar picture for the next requests.
I could bypass this issue, by adding a redis server to our project structure, but this will not be a solution for everyone.
Describe the solution you'd like
Similar to a warning when using some ini_set() that have WordPress functions for it, or when using a meta_query I would like to see a notice, that using session_start() or accessing $_SESSION is discouraged and considered a bad practice within WordPress.
I second what Juliette wrote in the below referenced issue, that WordPress Extra would be the right place for this.
Is your feature request related to a problem?
PHP Sessions are not used within WordPress core, and a few years back, I've talked with @2ndkauboy about wether to use them in a plugin or not. He advised against it, but did not really know why you should avoid using it.
In a recent project I found an objective reason why.
On the site I'm working on, which is quite big, I had to optimize long delays within the backend. In the end there were two major issues that I fixed, that improved the backend performance. Number one, was related to the vast amount of attachments. Number two was about
session_start().In my case Ninja Firewall is using php session, this becomes a problem as soon as multiple requests are fired in short succession, and when one request lasts a little longer.
And when opening the block editor it is absolutely normal that 5-15 requests are fired in the instance that you open the editor.
After profiling with xhprof I saw the following results (simplified)
Request 1: 9s due to a bunch of curl requests.
Request 2: 9.3s, 9s of it just waiting for
session_start()and 0.3s for the actual executionRequest 3: 9.6s, 9.3s waiting for
session_start()Similar picture for the next requests.
I could bypass this issue, by adding a redis server to our project structure, but this will not be a solution for everyone.
Describe the solution you'd like
Similar to a warning when using some
ini_set()that have WordPress functions for it, or when using ameta_queryI would like to see a notice, that usingsession_start()or accessing$_SESSIONis discouraged and considered a bad practice within WordPress.I second what Juliette wrote in the below referenced issue, that WordPress Extra would be the right place for this.
Additional context (optional)
Back in 2013 this was already discussed but only added to WordPress VIP
In 2022 this was again discussed within the yoastcs project. where @jrfnl already suggested to create a ticket upstream (which is done hereby)
For completeness the Links that Juliette gathered:
The text was updated successfully, but these errors were encountered: