Slim 4 Release Feedback

[l0gicgate]

Slim 4 Release See the full release notes.

Before doing anything read the docs I just finished the first draft of the docs for Slim 4 which are available here. I need feedback please: https://www.slimframework.com/docs/v4

Download the 4.0.0 release composer require slim/slim:^4.0

Install a PSR-7 Implementation You will also need to install a PSR-7 implementation and ServerRequestCreator combo. You can use Slim's PSR-7 Implementation or choose one of the ones described on the 4.x branch README: https://github.com/slimphp/Slim/blob/4.x/README.md composer require slim/psr7

You can also use the Slim 4 DDD API Skeleton to create a new project composer create-project slim/slim-skeleton [my-app-name]

If you have any questions don't hesitate to ping me on Slack or ask questions in this thread directly, I'm available to help!

[NicoP-S]

I'm just testing Slim v4. Is it possible to mock the slim environment like it was possible in v3? http://www.slimframework.com/docs/v3/cookbook/environment.html I have found Slim\PSR7\Environment::mock but i dont know how to inject it to my $app? Would like to use my routes from cli.

[odan]

@NicoP-S Yes, it's possible. For inspiration you could take a look at this HttpTestTrait for Slim 4. There are also some test cases: TestCase/Action

[SimonDevelop]

hey ! After making my own skeleton slim 4, I encounter a difficulty. my skeleton uses css/js files as assets for the front, but when I want to load these files with the url /assets/css/main.css I have this error :

Type: Slim\Exception\HttpNotFoundException
Code: 404
Message: Not found.
File: /home/simon/slim-skeleton/vendor/slim/slim/Slim/Middleware/RoutingMiddleware.php
Line: 91

I look at the documentation but I can not find what to do. what to do ?

[RyanNerd]

@SimonDevelop See #2837 as a possible feature making this easier. Right now the advice is:

inject the base path to the class containing the route callback.

[SimonDevelop]

@RyanNerd I manage my routes with controllers, I do not know how to do it. Would you have an example to propose to me if it is not too much to ask you?

For the moment I find this solution that works:

if (PHP_SAPI == 'cli-server') {
    $url  = parse_url($_SERVER['REQUEST_URI']);
    $file = __DIR__ . $url['path'];
    if (is_file($file)) {
        return false;
    }
}

[l0gicgate]

@SimonDevelop serving static files shouldn’t be done via Slim routing. I suggest you configure your webserver to serve them using pattern matching instead of doing that via a php script.

[SimonDevelop]

@l0gicgate ok, but with php server i have to trust via this code no ?

[adriansuter]

@SimonDevelop You are right. The PHP built-in server has no rewrite/redirect support. You could however write a PHP script in a separate file which would only be called and used in your development environment. For an example you could check https://stackoverflow.com/a/38926070

There are things you have to pay attention to. For example, avoid infinite loops to your entry script.

[kwhat]

Just an observation about PSR-7 implementations:

Slim 4 now provides a number of PSR-7 implementations, including two of its own. This is good. The issue I noticed when forward porting my application to version 4 was that the new middleware interface defines the request as the ServerRequestInterface. There is nothing inherently wrong with that, but it does lead to some minor annoyances when using methods defined outside of the PSR-7 interface from within the middleware. There is no runtime error, but there is a bit of static analysis false positives. This is not an issue when using "controllers" as I can just type hint the actual PSR-7 implementation instead of the interface.

There are a lot of factories:

The factories are a nice addition to Slim. Specifically, the AppFactory is a nice way to bootstrap the process. However, there are a lot of other factories and even factory -> factories. The factories that depend on other factories that are then injected and re-injected though the application are not really making things easy to understand. Furthermore, factories like the ResponseFactory don't really seem to provide any additional benefit for the abstraction. Why not just inject the response object like Slim 3 instead of passing around a factory that literally just does a return new Response(...$argv)?

These are just a couple of my observations from my initial upgrade. It is very possible that I am doing something wrong. Thanks for all of the work that went into the new version!

[l0gicgate]

@kwhat

The issue I noticed when forward porting my application to version 4 was that the new middleware interface defines the request as the ServerRequestInterface. There is nothing inherently wrong with that, but it does lead to some minor annoyances when using methods defined outside of the PSR-7 interface from within the middleware

You can change the signature to use your PSR-7 implementation's objects instead of the interface and those methods will be available (you can do the same on route callbacks):

<?php
declare(strict_types=1);

use Psr\Http\Message\ResponseInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Server\RequestHandlerInterface;
use Slim\Psr7\Request;
use Slim\Psr7\Factory\ResponseFactory;

class MyMiddleware implements MiddlewareInterface
{
    /**
     * @param Request                 $request
     * @param RequestHandlerInterface $handler
     * @return ResponseInterface
     */
    public function process(Request $request, RequestHandlerInterface $handler): ResponseInterface
    {
        $responseFactory = new ResponseFactory();
        return $responseFactory->createResponse(200);
    }
}

The factories that depend on other factories that are then injected and re-injected though the application are not really making things easy to understand

This is unfortunate but necessary. Without a lot of those factories we wouldn't be able to automagically do a lot of stuff which leads to poor UX.

Furthermore, factories like the ResponseFactory don't really seem to provide any additional benefit for the abstraction. Why not just inject the response object like Slim 3 instead of passing around a factory that literally just does a return new Response(...$argv)?

We need those factories internally to abstract away from the PSR-7 implementation since we cannot make assumptions when instantiating each implementation's objects. There's no way around that. Additional flexibility comes at a cost.

[kwhat]

@l0gicgate

You can change the signature to use your PSR-7 implementation's objects instead of the interface and those methods will be available (you can do the same on route callbacks):

This is not possible... You cannot narrow the scope of process() arguments defined in MiddlewareInterface. Updated: I was finally able to come up with a good solution. In PHP 7.2 you can make the scope wider, unfortunately this does not apply to the returned type...

class SlimMiddleware implements MiddlewareInterface
{
   /**
    * @param Request $request
    * @param RequestHandler $handler
    * @return Response
    */
    public function process($request, $handler): ResponseInterface
    {
        return $this->middleware->process($request, $handler);
    }
}

This is unfortunate but necessary. Without a lot of those factories we wouldn't be able to automagically do a lot of stuff which leads to poor UX.

I agree for the most part. With that said, I think that significantly more documentation is necessary to help explain the process. The only way I figured it out was reading all of the code and I doubt many users are as patient as I am. I am slowly working though this process over here. If I come across an obvious way to simplify it, I will create a separate post.

[l0gicgate]

@kwhat with PHP 7.4 and covariant types you should be able to use the example I showed.

I think that significantly more documentation is necessary to help explain the process

We do need better docs to document the process. It's not really something that most people care to know though. I will open an issue on the Slim-Website repo so we can eventually document it.

[kakenbok]

Just wanted to thank you for your exceptional work. It takes a while to get to know all the new roles and players, but once you understand them, all seems to be straightforward and well thought. I would say Slim is now more or less a framework framework or a versatile core you can build a framework around.

@kwhat says: "However, there are a lot of other factories and even factory -> factories." ... I would like to have even more factories :-), e.g. to extend the routing capabilities, I would like to have a RouteCollectorProxyFactory :-) I just want to have a "resource()" method available to $app and $routeGroup. Currently, I need to extend RouteCollector and override the entire group method just to create my custom RouteGroup object (which extends RouteCollectorProxy). And I do not set up routes using $app (can't be easily extended) but my custom RouteCollector, which is anyway all okay.

[Ayesh]

Thanks for the amazing work at the project. I once tried v2 a couple years back, and I was pleasantly surprised how much v3 has improved. It looked like a pain to upgrade from v2 to v3, but having used v3 extensively, I totally agree with the changes made in v2 to v3 upgrade.

v4 looks a bit intimidating at first, with core components decoupled. New PHP-DI integration is great, and the fact that you can plug any container, IMO, is a step at right direction. I will work on contributions I can make, but if there's any feedback I would provide, that would be on documentation on how to get started with the now-separate PSR-7 implementations.

It's not very clear on how to upgrade from v3 which bundled Pimple into v4 with Pimple. I understand the appeal of PHP-DI with autowiring support and generally light-weight implementation, but a Pimple bridge or information on how to upgrade using as much as Slim components would make the upgrade quite easier to grasp.

[thepercival]

Thanks for the upgrade to version 4. I am not a tech expert, but version 4 is really straight forward. This version is for me the easiest to understand. The documentation is also getting better per version. Many thanks!

[bednic]

Just hint for someone like me, trying to figure out why 4.4.0 version, by semver (thus composer too) only feature release, has breaking changes. So it has, RoutingMiddleware now use constants instead strings, with totally different keys. It break my app. ✌

[l0gicgate]

@bednic those are an internal BC, those attributes are technically private. The RouteContext object is what should be used to access those objects and it's been available since 4.0, if you were using that instead of directly accessing the attributes you wouldn't have experienced any BC

[bednic]

@l0gicgate Wow, I didn't expect that! You are right, I had old middleware on CORS, but didn't notice new CORS technique in V4. My apology. In that case everything is OK and I'm sorry.

[thepercival]

@bednic those are an internal BC, those attributes are technically private. The RouteContext object is what should be used to access those objects and it's been available since 4.0, if you were using that instead of directly accessing the attributes you wouldn't have experienced any BC

I had the same problem and found the routecontext-solution on the community forum. This is indeed the way to go. In the version 4 docs I could not find anything about this. Also the use of getQueryParams I could not find in the docs. The docs are great but maybe need some extra information. These problems are minor btw. The intuitive structure of slim 4 is great

[bednic]

@thepercival Maybe minor but still breaking. But it doesn't matter, it was my fault. I should read docs more carefuly. I love Slim way too. Make it PSR comliant was great decision, it's like fancy branded building kit.

[l0gicgate]

@thepercival http://www.slimframework.com/docs/v4/cookbook/retrieving-current-route.html it's in the docs

[thepercival]

@thepercival http://www.slimframework.com/docs/v4/cookbook/retrieving-current-route.html it's in the docs

My mistake, I read it thoroughly. I guess I just missed it a few times. Thanks a lot.

[snoopy72]

Catastrophic - to be honest.

We are running a (very) big software on slim v3 and tested the update to v4. what a desaster.

we know (we also handle hugh code masses and nervous customers daily) that software is always difficult ... but this version change is the worst upgrade we have seen for long time:

• there is basically no documentation for developers running apps already
• no list of functions, that have been removed ... with alternatives, how to do it in v4
• short pieces of code pulled out of context which make is really hard to get help or examples
• "small" changes where obviously nobody thought about consequences for existing projects (f.eg. routing > setArgument doe not take arrays any more / routing > case sensitivity of method-types "get" etc. / ...)

we are a team of senior developers (each of us with 35+ years of developing experience .. we know ASM code, where most of the current developers have to google for understanding what ASM is standing for). When slim wants to keep developers and bigger projects on their side, these type of upgrades will brake the neck - because those upgrades costs projects like our one several days of figuring out, WHAT has changed and HOW do solve the caused problems. Moving the app to symfony or laravel would be easier and prevent us, having the next upgrade the same problems.

The v4 upgrade is a big pain in our nexk (to be polite) and as you can imagine, we are heavily discussing framework alternatives now. chosen this "slim" framework, we hoped to avoid exactly these "we set everything upside-down" mentality. Some changes may make sense and bring slim toward standards ... but you loose your existing projects and supporters ... and with them experienced develoeprs making advertisement for this framework. Maybe you think about it in a quiet minute ...

[bednic]

@snoopy72 and your constructive feedback is what? I see only hate with some threats. But where is your useful advice? Where is some PR with fixes, which helps with backward compatibility, changes in documentations, something that helps. How you, senior developer, as you say, are helping these guys, which in their spare time, created a tool, you use for free?! So calm down and help. In other way it's just hateful speech of desperate man and I recommend others to ignore your comment.

[snoopy72]

@bednic we help a lot of people with our software and systems - also for free. and that costs enough time and resources. doing basic work (like documentation, upgrade notices etc) should be done by the developers of those changes (in best case during the sources-changes).

we opened tickets for problems:

3006 which made hugh problems in our app and has directly been closed, although the slim team seems to be responsible

3007 which had an easy solution - which is nowhere documentated or (better) could be found i a list "removed functions in slim v4" (and where the solution makes sense ! but without info it is pure frustration)

there is a "documentation" for upgrading (http://www.slimframework.com/docs/v4/start/upgrade.html) which is pointing to some changes ... fine, but only some. running a hugh app is something quite different and that the slim developers should be aware of. removing or renaming functions, classes etc without (nearly) any form of documenation is producing a very hugh amount of work for all developers using this software. and we as seniors cannot help in every corner (may sound arrogant, but that is reality when you teach junior developers AND run free software AND help in other projects already AND have to earn money AND have to run a business).

one of our/my biggest issues with slim is this blind behaviour and bad documentation. nearly all developers hate documentation - ok, we all know that. but keeping an eye on backward compatibility is not the job of (foreign) users of the software. should we ask OUR free using customers for finding errors after an upgrade ? no, because that has nothing to do with customer service (i think you will agree) and normal customers would only shake heads doing that. but we are only able to deliver the level of service and quality we get ... or (like in this case) we have to spend a lot of time into changing our software (several thousand routes and even more files). the slim team should be aware of that, because senior developers like us are teaching and helping juniors a lot ... removing slim from our supported frameworks (which IS a form of support / advertising / marketing / ... !!) would not help this project much, right ? but instead of some slim developers says "sorry, we see your point and understand your anger. we made some mistakes - what is your idea for furture upgrades ?" ... they are crying around, wondering about our level of frustration and jelling around ... if you ask for feedback, then deal also with the open critical ones ! ... ignoring those (of course clearly critical) comments is the best way to loose customers / users / developers - believe me, i do the job some days longer ...

[bednic]

@snoopy72 I'm trying to be objective. I see what is bothering you and from your point of view, you are right. But... From dev team point of view, they make huge step, tag this release as major, to show others to be careful, and did their best to update documentation of major changes, good enough? Maybe, maybe not. Anyway before upgrading you must expect some complications, incompatibilities etc. The example issue #3006 didn't just point to unnecessary changes, but it point in your mistake too. As senior you should prefer constants before strings. So if you did this right, you could just change string in constant from 'get' to 'GET' and voila, it works.

Anyway, objectively boths sides could make decisions which leads to problems. It's not optimal to demand case sensitivity of http method name as parameter and is bad practice using plain string in code if neccessary. To solve them, you need to cooperate. Cooperations is about to communication and finding solutions/compromises. Good communication is about to showing respect to the other side and make constructive proposals. But in the issue the problem was your attitude, that's all. And in your comment here, it's again, your language, your frenziness. Just let your anger go, no one is pushing you to upgrade right tomorrow, am I right? Just try to be kind and nice and maybe they will help you. It's open-source here, no one, who pays you, give a shit, what you are using, we did this to help each other, for free, and that deserve respect, always.

In my opinion on issue #3006 there shouldn't exist something like 'get' or 'GET', based on https://tools.ietf.org/html/rfc2616 (which says GET is right form) and fact that Slim is PSR compliant (PSR follows most of HTTP RFC's), all these strings should be replaced by RequestMethodInterface::METHOD_GET this could prevent all of misunderstandings.

Maybe you could try new way in other cases, like in case of setArgument, maybe it is not bad idea to accept others scalars, like an array. Now it's all on you, would you try change your manner?

[snoopy72]

@bednic Thanks for your long answer. I see, that you read my text and understand the reason for our anger about slim.

The ticket #3006 is a good example. in case of using a constant (which is not the case here, bause it is an array of strings) i could accept "GET" - but usings strings in php it is non-case-sensitive. Pointing blindy out to fast-route is also no solution or option, because those mapping is done in slim within the map function.

Of course we see the amount of work behind this framework. As i wrote: we are also running a hugh piece of software ... but: i always teach my juniors also to listen critical voices - even more than to positive ones. for one negative voice there are at least ten not articulated critical customers. answers like "ignore that comment" or "better help us" are not only a sign of being unable to accept criticism, but also (mostly) killing that source of feedback. when a customer is jelling around here, he/she has a reason for the frustration and in most cases we could learn from that feedback and make OUR software better .. what helps all others. funny side-effect: often we get reactions for those changes like "oh, i waited soo long for that feature" ... but nobody asked for it or pointed us to it.

Back to #3006: due to my explained reasons (f.eg my original comment), we cannot simply change all get to GET - it also makes code more unreadable when const and string are all in uppercase. we use several thousand routes (which you may think that should optimizable, but that are already placeholders and variable syntax ones) - quickly change everything is really some work. you may be right to say, that this is our problem, but our team was not able to find the reason for that change (why to make this string case-sensitive). one simple line in the slim source solved that problem and everything works like before - not in fastroute, im slim !

With ticket #3005: setArguments makes sense, no doubt. but that is not the reason for our frustration. the lack of documentation ist highly frustrating. and as i also already wrote: developers (may) hate writing documentation; i can understand that quite well, because i dont like that work as well very much. but running/deploying/publishing a framework which should (?) be used for other projects, documentation is the beginning and the end. nobody (especially not developers with their own project) will read tickets or long dialogs for figure out the solution or problem, right ?

One word to your wishes of "manner": this should be a technical discussion for developers - professionals or hobby developers ? clear (sometimes rough sounding) words or easy-peazy-soft-washing ? Of course criticism and frustration does (in most times) not come in friendly words. they shows the "service delivery" side (here slim ?) the end of tolerance from the point of view of the customers. i always tell my youngsters here not to read the harsh words, but the meaning behind them: unsatisfied customer = negative imagage of our product = bad advertising. i love to overtake frustrated users (listen carefully and you have a unpayable feedback) ... because they have reasons and wants to communicate them. otherwise they would had just turned round and had gone ... like we: we decided finally to change to symfony. hard work to do, but a professional and stable framework with hugh community, also free and with LTS. it is a long way for slim and a cliffy learning-curve. wish you the best and less users like us with criticism ... but maybe (?) you loose very valuable (but of course unattractive) feedback.

[tuupola]

Regarding #3006. While request methods such as get, Get and gEt are technically valid they are not the same as GET. The RFC states the request method names are case-sensitive.

[snoopy72]

@tuupola right, but defined as array of STRINGS it is unimportant. you can map those valid strings to RFC conform names in the slim "map" function (one job of a framework ?!). In consequence you should not accept strings but only defined values like GET, POST, etc.

we're obvioulsy not allone with that problem: https://www.yourhelpcenter.de/2020/09/slim4-405-method-not-allowed/ instead of making slim better (with reading all sorts of typing) you are argueing around with users ... but see my last comments.

[tuupola]

The methods get, Get and gEt do conform to the RFC, they just are not the same as GET. This is quite usual source of confusion among developers. RFC also does not limit which are allowed request methods. Even FOO and foo are technically valid.

[speauty]

how to user repositoy at middleware in slim4?

[plasid]

I have been using Slim3 for many years, today I decided to take the leap and start migrating some of my apps to Slim4...OMG what a shock, I realised off-the-bat that this is not just a major release, its a new framework. Regardless, I gave it a shot, installed, went through the tutorials, installed the skeleton app studied the directory structure, design patterns etc. - it will take me days if not 2 weeks to refactor my app to work with Slim4.

No disrespect, but what was your reasoning for this complexity apart from decoupling and making things more agnostic? What you have created here is a framework that is far from "slim" or micro in the sense of installation and ease of use, its now on par with Zend and Symfony's complexity, exactly what I hated about those frameworks.

If there were no skeleton app and tutorials for Slim4, hardly any dev would be able to make sense of it... One needs to install so many 3rd party packages to do the work you expected the framework to do, or at minimum expect routing, request/response (plus error handling) and configuration to be baked in.

Based on this new architecture, one can ignore Slim and just string all these packages together and create your own "framework" - I fail to see how Slim4 is giving me any jump start on projects, or making daily dev any easier, with Slim3 it was an absolute breeze.

IMO:

1. Do not abstract for the sake of abstraction.
2. YAGNI
3. If its not broken, do not fix it.
4. K.I.S.S

[l0gicgate]

@TradeSharer I think you're looking at it from the wrong perspective. Upgrading a Slim 3 project to Slim 4 has very little upside. Unfortunately we had to break a lot of things and it made upgrading large projects more difficult but it put Slim core in a better spot in the long run.

No disrespect, but what was your reasoning for this complexity apart from decoupling and making things more agnostic?

The tight coupling between the routing, error handling and the PSR-7 implementation were causing a lot of issues that were unsolvable keeping the existing internals the way they were.

What you have created here is a framework that is far from "slim" or micro in the sense of installation and ease of use, its now on par with Zend and Symfony's complexity, exactly what I hated about those frameworks.

You're just wrong. If anything, we made Slim even slimmer as everything being decoupled removed 1000s of line of code from the core and extracted them in their own packages that are now interoperable with other libraries. Symfony and Laravel railroad you into using their own packages which can be very frustrating and feel like throwing the kitchen sink at small problems. With Slim you can easily use PSR compatible packages and even swap in your own routing library if you don't like FastRoute. It gives a ton of flexibility to the end user and to me that's a positive.

Based on this new architecture, one can ignore Slim and just string all these packages together and create your own "framework"

Then do it. You're going to waste a bunch of time doing work that's already done for you.

I fail to see how Slim4 is giving me any jump start on projects, or making daily dev any easier, with Slim3 it was an absolute breeze.

I've developed both personal/work projects since 2018 with Slim 4 and I would never go back to Slim 3 again. Your opinion is purely subjective. Nobody is forcing you to use Slim 4.