That example is in fact wrong.

The write method does not return the response object.

We will need to fix that.

I should mention these changes are quite breaking for me - or I'm doing something very, very wrong.

The entire application I'm migrating (from v2 lol) relies on echo json_encode() or similar stuff. I'll have to write a new Strategy class to handle the fact 99% of the API endpoints do not return anything. This was working fine on v3.

I understand that typing the return on the strategies has been a paint point during migration for a lot of people. I do think it forces user into a better pattern though. You can also easily implement your own strategy to handle your use case as you mentioned.

Yep, I totally understand the reason behind this. However, if this was supported in v3, it should be clearly stated in the migration doc this is no longer acceptable, and ways to overcome it.

Personally I would also include some sort of LegacyStrategy class - it could issue an E_USER_DEPRECATED error and then, drop that class in v5. But I'm completely new to Slim and have no idea on how things go around here, so this is just a random opinion about easier migration steps for users :)

Not to mention this is quite a deep change. I've spent days and days changing a lot of stuff through search-replace and double-check, but in this case it's not feasible to migrate the actual code - there's just way too many echo's around (and god knows what else) to reliable search-replace. Just saying "this is not going to work anymore, rewrite all your functions" is definitely not friendly.

I noticed only now the docs reside in another package. Nonetheless, as there's code suggestions here, I'll leave this open for now. If you want, I can split it into code suggestions and doc suggestions.

Lots of helper functions are actually, gone. I did a migration from Slim 3 to Slim 4 but managed to get everything working. took a couple of weeks but finally managed it. From reading issues raised in the past, I came to understand that this is because the framework wants to abide by psr7 standards.

Here are a few tips.

// writing out
return $response->write('Hello World'); // v3

$response->getBody()->write('Hello World'); // v4
return $response;

// returning json
return $response->withJson(['message' => 'success']); //v3
$response->getBody()->write(json_encode(['message' => 'success'])); // v4
return $response;

// redirects
return $response->withRedirect($this->router->pathFor('users.index')); // v3
return $response->withHeader('Location', $this->router->urlFor('users.index')); //v4

@nixoncode all those helper functions were migrated to Slim-Http which can decorate any PSR-7 implementation.

@l0gicgate Thanks for the heads up.

This is so sad, I did all that and what I just needed to do was

$ composer require slim/http

Switch Type hinting

// from
use Psr\Http\Message\ResponseInterface as Response;
//to
use Slim\Http\Response;

And everything works as just as it was

Thank you! Migration Upgrade needs to mention this somewhere

I should mention am using slim/psr7 as the prs7 implementation and php-di/slim-bridge

While upgrading to 4 wasn't that easy for us because the Upgrade Guide is missing info, I should praise the past versions: I'm actually migrating an ancient application from Slim 1.6 all up to 4 (so we can get PHP 7, look at that), and 1>2 and 2>3 were pretty smooth :)

I think one of the problems is that Slim 4 was a paradigm shift, moving to a move flexible but PSR compliant application which is a fantastic move for the framework however, it does not leave problems. Capturing every BC in this scenario is obviously going to be quite difficult, and a few mising the net is not a bad thing - we are all human!

Also from Slim 3 to Slim 4 the project lead has swapped hands, so patience while new hands get a grip on their direction is needed.

I wouldn't call this an issue, move of a "should have made a note of that". The functionality is still available in the Slim-Http package, so I would vote to close this issue