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!

[mosfetish]

V3 Docs have a "First Application" item. Be good to see that for v4. Seems pretty essential to me. I note the "DDD Skeleton" above but an app setup guide is what I'm after.

[Hill-98]

I found that the middleware in Slim 4 can't call the dependency container using $this as before, now he will throw an error: Using $this when not in object context, can you tell me how to fix it?

[mnapoli]

Hey! Since this is a feedback thread, here is my feedback ^^

On the home page (here https://www.slimframework.com/docs/v4/) there is an example application that is different from the one showed in "Installation" (here https://www.slimframework.com/docs/v4/start/installation.html). The one on the home page worries me a bit: why is there a thing about adding a routing and error middleware? Does this not work by default? (I hope it does, TBH I'm just out of bed and haven't read the whole docs)

To be honest I don't really care about the PSR-7 implementation and having to choose one and install it is a bit of a pain IMO. I understand decoupling from anything that impacts the user (e.g. the container), but I don't understand why decouple from internal dependencies (PSR-7 and the factories, even routing).

In the meantime I discovered the https://github.com/slimphp/Slim-Skeleton repository, and also discovered it is using PHP-DI (cooool!). I have a few comments there on how it is used and how it could be improved, should I post this here or there?

[l0gicgate]

@Hill-98 showing example code would be great. It sounds like you're trying to call $this from a static context.

[l0gicgate]

@mnapoli

On the home page (here https://www.slimframework.com/docs/v4/) there is an example application that is different from the one showed in "Installation" (here https://www.slimframework.com/docs/v4/start/installation.html). The one on the home page worries me a bit: why is there a thing about adding a routing and error middleware? Does this not work by default? (I hope it does, TBH I'm just out of bed and haven't read the whole docs)

RoutingMiddleware is added by default when a user does not manually add it. This is so you can control when routing is being performed. In Slim 3 we had the setting determineRouteBeforeAppMiddleware which dictated when the routing was being done. Now you can precisely decide when it is being done by changing it's order in the middleware queue.

As for ErrorMiddleware, it needs to be added manually since you would want it to be last in the queue (Last In First Out) of middleware so it catches all of the errors from within the middleware pipeline. In Slim 3 we had a lot of feedback on how tightly coupled error handling was to the core of the App component and it generated a lot of issues, hence why it has been extracted from core and now users have more control over it.

To be honest I don't really care about the PSR-7 implementation and having to choose one and install it is a bit of a pain IMO. I understand decoupling from anything that impacts the user (e.g. the container), but I don't understand why decouple from internal dependencies (PSR-7 and the factories, even routing).

As explained in the release notes, modularity was the primary focus for this release so we can give back more control to the end user and let them make their own design decisions, giving more flexibility as to what core components you want to use and enable you to drop in your own easily if need be.

While you may not want to choose your own PSR-7/Container implementation, I think that the additional flexibility is more important. This is why we have the Slim-Skeleton project, you're also more than welcome to create your own skeleton so other users can benefit from your library choices over ours.

In the meantime I discovered the https://github.com/slimphp/Slim-Skeleton repository, and also discovered it is using PHP-DI (cooool!). I have a few comments there on how it is used and how it could be improved, should I post this here or there?

I would suggest creating an issue over there, since we want to keep things as topical as possible

[ghost]

Did you guys change literally everything?? It's impossible to upgrade from a reasonably sized Slim3 app to 4.

[l0gicgate]

@Rutmeister in order to get Slim in a good spot for the future, we had to break a lot of things unfortunately. Obviously it’s going to be a lot of work to upgrade on a large project, I’m not sure I would recommend doing so.

[Hill-98]

@l0gicgate This is my code:

Slim 3:
I use the container provided by Slim and he works very well.

$app = new App();
$container = $app->getContainer();
$container["cache"] = function () {
    $redis = new Redis();
    $redis->pconnect(REDIS_HOST, 6379, 3, REDIS_PREFIX);
    $redis->setOption(REDIS::OPT_PREFIX, REDIS_PREFIX);
    return $redis;
};
$app->add(function (Request $request, Response $response, $next) {
    $cache = $this->get("cache");
    // .....
});
//.....

Slim 4:
I am using a container provided by PHP-DI and the following code does not work.

$container = new Container();
$container->set("cache", function () {
    $redis = new Redis();
    $redis->pconnect(REDIS_HOST, 6379, 3, REDIS_PREFIX);
    $redis->setOption(REDIS::OPT_PREFIX, REDIS_PREFIX);
    return $redis;
});
AppFactory::setContainer($container);
$app = AppFactory::create();
$app->add(function (Request $request, RequestHandler $handler) {
    $cache = $this->get("cache");
    // .....
});
//.....

[jacekkarczmarczyk]

@l0gicgate some frameworks/libs provide an upgrade guide, list of steps you need to do to make your app compatible with new version, something like

Before:

App::useRouter($router)

After

$app = new App();
$app->addRouter($router)

Maybe there could be something like this for Slim too? See for example https://vuejs.org/v2/guide/migration.html or https://github.com/vuetifyjs/vuetify/releases/tag/v2.0.0#user-content-upgrade-guide

[ghost]

@l0gicgate Imma be real with you chief. This ain't it. Mainly because there's no DI-Bridge in my case. Do you know if that's going to be supported for v4 anytime soon? Really can't go without it.

Other thing that might be a bug. When you search using the search bar in the v4 documentation it often links to the v3 docs.

[l0gicgate]

@Rutmeister you don’t need DI bridge. You can use any PSR-11 container implementation you want with Slim 4.

Go look at https://github.com/slimphp/Slim-Skeleton it uses PHP-DI with Slim 4.

Also, the doc search is not broken, the new docs were just released so we had to trigger a recrawl via Agnolia which takes several days to complete. It’ll be fixed shortly.

[l0gicgate]

@jacekkarczmarczyk that’s a good idea. We should do that.

[l0gicgate]

@Hill-98 this is an issue with the MiddlewareDispatcher since it does not use CallableResolver the ContainerInterface never gets bound to the wrapping class:
https://github.com/slimphp/Slim/blob/4.x/Slim/MiddlewareDispatcher.php#L196

A quick solution in the interim:

$app->add((function ($request, $handler) {...})->bindTo($container));

[Hill-98]

@l0gicgate Thank you very much, it's great.

[ghost]

@l0gicgate sorry I think I asked my question wrong. The DI container is working great but I'm having trouble getting the different controller parameters to work like the di-bridge offered in v3.
https://github.com/PHP-DI/Slim-Bridge#controller-parameters

From what I've seen it's not possible yet but perhaps I'm wrong.

[l0gicgate]

@Rutmeister porting DI-Bridge to Slim 4 shouldn’t actually too big of an undertaking. I might make a PR on that repo this week if I have time.

[BusterNeece]

@l0gicgate My goodness, this upgrade is amounting to more work than I expected! I appreciate the changes under the hood that made Slim PSR-agnostic, and I can see how these were overall necessary, but this is requiring a refactor of huge swaths of my codebase.

One big piece of feedback I have is that the name argument provided for Middleware added via $route->add() no longer routes through the CallableResolver at all. Thus, out of the box you can't build in custom resolver functionality like supporting additional function arguments or other things that end up being quite necessary with many middlewares.

I'm looking into how to override the entire MiddlewareDispatcher to allow for this, but I gotta say it's a real pain to even need to.

Update: it turns out you can't just provide a replacement MiddlewareDispatcher out of the box. It's created by Slim\App's constructor and has no getters/setters. You'd have to overwrite the actual Slim\App class itself just to add this relatively minor but very important functionality.

Is there any way we can just get this upstream?

[mnapoli]

Just stumbled upon this:

Could not detect any PSR-17 ResponseFactory implementations. Please install a supported implementation in order to use AppFactory::create(). See https://github.com/slimphp/Slim/blob/4.x/README.md for a list of supported implementations.

I understand why, but this doesn't make any sense to me as a user. The framework doesn't work out of the box. Furthermore, when I opened https://github.com/slimphp/Slim/blob/4.x/README.md I saw way too many choices. Which one should I choose? I mean, having contributed to PSR-15 and PSR-17 I'm still confused here.

Maybe it would be worth pre-installing one implementation so that the core of the framework works?

I understand and respect the choice about the DI container, because Slim can work without a DI container. But I think HTTP is different because the framework can't work without it then.

(side note: please consider this as feedback and not blind criticism of the release, I do appreciate how huge these things are, I just want to contribute to improve it)

[l0gicgate]

@mnapoli when installing via composer, it suggests installing Slim-Psr7.

We could maybe add a note to the README saying: “If unsure, just install Slim-Psr7”

[l0gicgate]

@SlvrEagle23 yea that is one drawback of the new PSR-15 dispatcher. We had to make some tough decisions in that regard.

I’m open to providing the ability to pass in your own MiddlewareDispatcher via the App constructor so you don’t have to extend the app to override it.

[l0gicgate]

@Hill-98 & @SlvrEagle23 see #2779

[esetnik]

After upgrading to v4 something broke related to request uri matching when using nginx as the web server. I am using the configuration from http://www.slimframework.com/docs/v4/start/web-servers.html with a slight modification since my application is mounted in a subdirectory (/api).

    location /api {
        try_files $uri /api/index.php$is_args$args;
    }

    # pass the PHP scripts to FastCGI server listening on socket
    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php:9000;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param SCRIPT_NAME $fastcgi_script_name;
        fastcgi_param SERVER_NAME $host;
        fastcgi_buffers 16 16k; 
        fastcgi_buffer_size 32k;
        fastcgi_param X_REQUEST_ID $request_id;
        fastcgi_hide_header X-Powered-By;
    

It appears that basePath processing has been removed from Slim v4 and is not available in Slim-Psr7 even though it is documented as being available and functional.

Base Path
If your Slim application's front-controller lives in a physical subdirectory beneath your document root directory, you can fetch the HTTP request's physical base path (relative to the document root) with the Uri object's getBasePath() method. This will be an empty string if the Slim application is installed in the document root's top-most directory.

See slimphp/Slim-Psr7#118

[mosfetish]

The framework doesn't work out of the box.

Might be time to go "frameworkless". Slim 4 now appears to be a slightly-opinionated assemblage of components, a template more than a framework, because as you say, a framework is meant to work out of the box.

It leaves new users (and even current users) scratching their heads as to which way to jump. At the very least, the docs should contain tutorials that go deeper than mere hints at possible implementations.

[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.