PHP – Is It Right to Store User Permissions in PHP Sessions?

There is no single proper approach to your problems even within MVC pattern so simple answer to your questions does not exist.

1 Error handling

If you are using the PDO you can change error handling by setting PDO::ATTR_ERRMODE so you don't have to use exceptions but regardless of the way errors are returned it is a programmers responsibility to handle them properly. If your method is returning false if the user doesn't exists then the controller should check what value was returned. There is no such thing as "controller assumes" it only means that the programmer assumed and didn't check returned value.

There are different errors which should be handled in different way some of them may require only showing error message some of them may be critical (like no db connection). You can use messages, views or additional controller to handle errors.

2 The proper way to show a view

Code from your example would be usually handled by the layout (header, footer, different element placement) and by the controller (using different views depending on the request). It is not good idea to use 'include' directly rather wrap it in the method. You can also create view class which would be responsible for handling views. view != .phtml

3 Managing user rights

In MVC pattern used for web applications there is usually additional "front controller" and permission checking will be handled there. You have to check for permission with each request and each request will require access to specific controller/method if you implement proper ACL it should resolve all your problems with user rights.

I think the most common simple solution is where you set a timer on the client end that shows a message after a certain portion of the normal timeout window has passed then forcibly logs them out right before the session would expire anyway if they take no action.

Local storage and auto-save introduce some issues with transactions and what saved really means. I have been on quite a few projects where this has turned out to be more trouble than it is worth when the user base does not understand the mechanics behind it.

Never logging out can be done where regulations permit, but it leads you into mistakes where you do not correctly handle what happens if someone is logged out unexpectedly, and all the state business becomes a little intensive to maintain if there is very much to track on an "active" user.