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
In PHP the session functions by default store session date in files.
On many WordPress hosts creating files in this manner can lead to errors, either due to the amount of files being created or due the directory these files are written in not being writable to the user the PHP process is running as.
As such we should never use these functions in our plugin, other mechanisms such as options, usermeta or custom cookies should be used instead when required.
There is also a WordPress health check that detects if PHP sessions are used and throws a performance warning if this is the case, so even on hosts that do not have technical problems users will still see a failing health check due to us.
The text was updated successfully, but these errors were encountered:
I had a feeling this was already being checked for in WPCS, but a quick file search I just did, shows it's not.
Turns out this used to be checked via the VIP ruleset, but was removed when VIP was removed.
I'm pretty sure there must have been a discussion about whether or not the session_* function sniff should be retained at the time, but unfortunately, I can't seem to find the relevant issue at the moment.
All the same, IMO this is something which is not Yoast specific, but a best practice which could be recommended for all projects running in a WP context, so more suitable for WPCS itself (in WordPress-Extra).
Some links to previous discussions/PR on this upstream:
In PHP the session functions by default store session date in files.
On many WordPress hosts creating files in this manner can lead to errors, either due to the amount of files being created or due the directory these files are written in not being writable to the user the PHP process is running as.
As such we should never use these functions in our plugin, other mechanisms such as options, usermeta or custom cookies should be used instead when required.
There is also a WordPress health check that detects if PHP sessions are used and throws a performance warning if this is the case, so even on hosts that do not have technical problems users will still see a failing health check due to us.
The text was updated successfully, but these errors were encountered: