Thanks! That works really well and makes the code not only maintainable across two branches but also more readable. I totally like this change.
1 Like
Just had another great chat with @bwaidelich and he came up with the idea to keep just the ComponentInterface (marked as deprecated), which would allow existing Components to still pass the compile step. That way, a package could provide both a Component and Middleware version (+according config settings) of it’s functionality, and the enduser decides which is used by just installing either Flow < 7 or Flow 7+. This would avoid having to create a new major version of your package that is only compatible with Flow 7+.
cc @robert
Don’t we just push solving of the actual issue another version for the package creator? It will have to be done, no matter what. Do we really help by doing this, or pushing the legacy further?
We provide an option for package maintainers that costs us nothing and doesn’t force them to maintain two versions.
It “costs us” to keep a deprecated and removed concept in the codebase. Relatively speaking, we move the “cost” on to the core?
How big of an issue is this really?
It’s really just a single interface laying around. Nothing more.
It’s a deprecated concept that is being kept alive 
It’s even marked as deprecated since 6.0 (IIRC)
I will not block it, but do not see it add value either
It’s not kept “alive” though. It will not work in Flow 7. It can not be executed. It just means, if you have a Component laying around anywhere in your code base, it will not throw an exception during the compile step.
Not sure how this would work. If the middleware is already configured in settings yaml in Neos 4.3 the HttpComponent and the Middleware would be active. So imho this would still require two versions which only differ in Settings. Unless there is a solution for that i would consider this even stranger.
Ugh, 5.3 but you are right… we’d need to patch something into that version to e.g. not run a middleware with the same name as a component or s.th. which is… awkward. There goes the “perfect” plan 
No no, the “perfect” plan is not gone - it just arrives in a different shape with a new set of curcumstances 
Hi all,
without any blame whatsoever I have to say that I’m really concerned that we break compatibility in a way that forces package authors to release new major versions (and to maintain yet another branch of their package) the 2nd year in a row.
With the middleware chain packages with HTTP components have to be adjusted manually as we figured above. That’s sad but fine if we communicate it transparently and provide core migrations to detect those cases and provide help.
But IMO we should try to allow developers to create packages that are compatible with Flow 6 and 7 and I’m sure that’s possible somehow. (though I have to admit, I wasn’t even aware that we use middleware and component chain along side since 5.3 and that certainly makes things harder)
If they can release a new feature version that is compatible with Flow 7 and below and keep that compatibility for at least one more year, that’s a big deal IMO
It’s not legacy, 6.3 is supported until August 2023 still and the smoother the transition the better I’d say.
It would be like saying: PHP should remove all the inconsistent functions with the next version
Totally out of context We are releasing a new major version number - if we can not see ourself do it here, then when can we
I’d love to have that, so if you have any glimpse of an idea how, I’ll gladly investigate that approach. I’m a bit out of ideas tbh
I see no way around this and actually not that many packages and projects use custom http components. Offcourse it would be nice to have a compatibility layer or migration but this is really a tough one.
Having tasted psr15 middlewares now i think they are really the way to go as they can affect the incoming request and the returned result which is needed surprisingly often.
Hi all,
trying to get a grip on this one today.
We do agree that we want to make the developer transition as smooth as possible without introducing too much technical dept. right?
I gave the LegacyComponentMiddleware approach a quick shot yesterday and it works quite nicely actually. But it has a couple of caveats:
- We’d have to keep the (now deprecated)
ComponentInterface - We’d have to keep the deprecated
ComponentContext(with a reduced functionality) - It won’t support all the features (like passing parameters between components) and the behavior of
$componentContext->setParameter(ComponentChain::class, 'cancel', true)would be changed - We’d have to introduce some “switch” that disables the
LegacyComponentMiddlewarefor Flow 6.3
All in all it probably makes more sense if we spend our energy in good documentation & detection/migration tools.
One thing we should provide is some good transition guide for package authors. And for this we should think about the different scenarios.
Example 1: HttpOptionsComponent in t3n/graphql
The t3n/graphql package comes with a HttpOptionsComponent that sends a Allow header for OPTION requests.
This might be a good candidate for an exclusive “http options” package that is required by t3n/graphql and has versions compatible for Flow 7 and below (i.e. let composer do the b/c work).
PS: The component currently uses the configured graphql endpoints to see if it’s active but maybe it’s a good idea to generalize that functionality anyways (e.g. use the configured routes to determine the allowed HTTP methods)
Example 2: GraphQLUploadComponent in t3n/graphql-upload
The t3n/graphql-upload package comes with a GraphQLUploadComponent that detects file uploads and modifies the incoming request accordingly.
In this case it probably doesn’t make sense to extract the functionality to a separate package since the component is the central part of this package
1 Like