Is it bad to use the default PHP session engine?

As every resource needs to understand it completely, read all documentation and eventually look for undocumented information. Something complex like this may have a lot of details that may go unnoticed. I'm not going to try to put everything that needs to be checked, because I'm not an expert on the subject, and I do not think it fits. My intention is not to give a definitive answer.

The main reason for frameworks provide its own mechanisms for any technology is resource abstraction.

Abstraction is one of the most misunderstood concepts in computing. It has always existed even before there were modern computers. The abstraction gives more meaning to what you are doing and puts a layer on top of the concrete, allowing the actual implementation to be hidden from the user of that resource.

One of the great advantages of abstraction is that if it is well done you can change the implementation without requiring the codes that use it to be modified. This is very important in many scenarios. It is not always possible to do well, however good the programmer. And the complication of abstraction that will be needed is not always worth the effort.

So it's interesting that these products have a form that at least does not depend on the PHP standard.

And since the standard has a relatively simple and fixed implementation, it is only natural that they provide a more powerful and flexible implementation. I can imagine a lot of things that it is possible to do in a session in addition to what the default implementation provides. There are several scenarios where the pattern does not respond well. Although most scenarios do not require any other solution.

In addition to obviously supplying more information, better integration with database and session and transport distribution, and otherwise identifying information and counting of active sessions are some examples of what can be improved.

As stated in the comments, the fact of creating your own version does not mean it will look better. Although the intention of these frameworks is to facilitate the use of resources in relation to what exists in PHP. Perhaps the attempt to do something better has left it too complex.

Most of the problems I see using the default session have to do with misuse. Ok, it may be a bit difficult to do right, but it is the programmer's obligation to know how to do this. And frameworks will have to choose between facilitating or giving a more powerful and flexible resource. What I see them doing a lot is applying such good practices. That is, they choose what is good for you, even if that is not always the best.

Given the documentation page of a function, you can get an idea of what it looks like complicated to use right, safely. But it does not have much to do when the problem is complex (though it's an exaggeration to call it complex).

  

I wonder if there's anything wrong with the standard PHP session engine?

If it was so problematic I'd already have enough recommendation not to use, someone would have already made a substitute in PHP. It's good to have some information here, but the problem is not in the feature, it's in the little pen between the keyboard and the chair.

    

It depends. Using standard PHP sessions does not present general problems, however may be poor depending on how it is used. The standard save handler uses files, so on every request received , even with you not using the session in some, it will roll a lock on the session files and a subsequent reading of them, this may represent a relevant overhead if you have a really large amount of requests.

Another detail is that, as I said before, making a request generates a lock in your session file (whose default path is something like /var/lib/php/session/sess_$identifier ), so any concurrent requests have to wait for the lock to be released so that to proceed. The lock starts at session_start() and ends at the end of the execution of your script, or at the session_write_close() call, in this way if you have a situation where the client makes multiple ajax requests followed to the server all these requests queue waiting for what arrived before releasing the lock from the session file, and this is really bad. The ideal way to minimize this problem is to always use session_write_close() as close to the start of the session, otherwise competing requests will have to wait for the execution of the script that arrived first, which can mean a crash of operation (read files , access database, process things, etc.).

Another problem that seems to lead several frameworks to avoid using standard php sessions is the fact that session_start() , as invoked, always sends the session cookie to the client. The problem here is related to the one described in the previous paragraph, you want to close the session as soon as possible after opening it, however you might want to do something like write something in the session at the end of your php script and if you have already closed it will need reopen. In this situation you have the problem that you will probably get an error similar to Headers already sent because in HTTP the header is always sent before content, and at a late stage of your script it is likely that you have already finished sending the header and started to send content and the session_start() call will try to send more header (the cookie).

Finally we have the issue already commented on in the response of bigown, which although so abstract that of you to use it in 90% of the conceptual questions of programming (hah is zoeira in, the answer is good;)), explains well the fact that you often want a control greater than that given by a native implementation, or you want access to a different abstraction, or want something more flexible, or you want an implementation whose operation is easier to understand (than knowing what rolls under the cloths, without "magic").