$app->add( new \My\Middleware\Custom() );
$app->add( new \Slim\Middleware\SessionCookie() );
/** and later **/
So if you write to $_SESSION in your middleware, it ought to be set
and then saved. The session is loaded before \Slim::call() and
saved after \Slim::call().
Why does it throw an exception in the first case?
I run through what I understand. You might already have looked
at Slim's code and got much of this anyway.
calls\Slim::stop(). This is then caught in
\Slim::call(), which writes any output emitted up to
that point into the response object. After all middleware calls are
made, \Slim::run() finalizes the response, and sends
headers, including 'Location' which triggers to redirect in the
The sequence of call methods in middleware objects should not
impede session writing. If you look at the SessionCookie
middleware's call() method, it writes the session after any
enclosed middleware calls. SO the sequence would be something
1. Custom middleware call() is entered.
2. SessionCookie middleware call() is entered. Session is
3. Slim call()
4. SessionCookie writes session to cookie. SessionCookie::call() is
5. Custom middleware call() is exited.
On the face of it, there's nothing that should stop the session
data being written to the cookie. Am I missing something?
I haven't tried your code, but I'm intrigued so I'll see if I
can find time in the next couple of days.
After looking at your code and at Slim, I really can't see a
reason why \Slim\Slim::stop() and the way that
Slim::call() catches the resulting Exception would
prevent the SessionCookie middleware from saving, since the session
saving occurs after any enclosed call() methods. In fact, calling
Slim\Http\Response:redirect() doesn't throw the
exception, so it's conceivable that Slim would
continued running its call method. Either way, any code after the
enclosed call() in any middleware should run.
I wonder if there's something else going on.
You needn't reply to this, as I haven't made any progress toward
resolving the issue.