!!! TASK: Remove deprecated code

[bwaidelich]

Remove obsolete and deprecated PHP code:

• Cli/Request::getMainRequest() & Cli/Request::isMainRequest()
  • Those were deprecated with 6.0 (via !!!TASK: Remove deprecated Http objects and replace with PSR-7 implementation #1552) and never really served a purpose since
    CLI requests can't be nested
• Neos\Flow\Persistence\Generic\*
  • Before we had doctrine, we had a custom persistence layer that was kept as "generic" persistence when we introduced doctrine ten years ago (via 90cb658). Since 6.0 this custom persistence was deprecated in favor of the corresponding Neos\Flow\Persistence\Doctrine\* classes.
    generic persistence is dead, long live generic persistence! (and thanks to @kdambekalns for spending million of minutes and brain cells on this)
• Neos\Flow\Security\Cryptography\SaltedMd5HashingStrategy
  • md5 is unsafe and the hashing strategy was deprecated with 6.0.
• ObjectAccess::instantiateClass()
  • deprecated with 5.3.16 (via TASK: Use argument unpacking instead of call_user_func_array #1972). With PHP 5.6+ new $className(...$arguments) can be used instead
• HttpRequestHandlerInterface/HttpRequestHandler::getHttpResponse()
  • deprecated with 6.0 (via TASK: Provide comprehensive solution to get base URI #1755) and now gone. If you need the current HTTP Response, use a middleware, as the Response does not exist earlier at all

Related: #2172

[sorenmalling]

Related draft PR #2181

[sorenmalling]

Related draft PR #2181

Draft PR can be closed in favor of this - I don't mind :)

[bwaidelich]

@sorenmalling I'm sorry, I wasn't aware of your pr. will check tomorrow!

[sorenmalling]

I believe it's mostly the same :-)

[sorenmalling]

How did the verdict on removal of Component code go?

[sorenmalling]

Compared to https://github.com/neos/flow-development-collection/pull/2181/files I can see we do not remove ex. PsrSystemLoggerInterface?

[kdambekalns]

There is documentation that needs to be updated (on generic persistence, probably more…)

[bwaidelich]

How did the verdict on removal of Component code go?

How do you mean? That was removed with #2019 (and we still have to smoothen the bumps with #2258)

Compared to #2181 I can see we do not remove ex. PsrSystemLoggerInterface?

Good point, I missed that one when I compared the two (#2181 (comment)).

There is documentation that needs to be updated (on generic persistence, probably more…)

True that..

@sorenmalling @kdambekalns Thanks for your feedback, I'll prepare a follow-up

[sorenmalling]

How do you mean? That was removed with #2019 (and we still have to smoothen the bumps with #2258)

Roger that - got lost in back/forth on keeping or not 👍

[bwaidelich]

Update: The Psr Logger interfaces have been removed with #2134, that's why they don't appear in the diff :)

[bwaidelich]

Looking at the documentation I found a lot of outdated examples and code.
I tried to address those with a separate issue (see #2280)

There is documentation that needs to be updated (on generic persistence, probably more…)

It seems like (apart from the CGL tweaks mentioned above) it's only the generic persistence part that is affected.
I'm a bit puzzled currently. @kdambekalns do you think it would be enough to just remove the part from the docs: https://flowframework.readthedocs.io/en/stable/TheDefinitiveGuide/PartIII/Persistence.html#generic-persistence
?

[bwaidelich]

@kdambekalns could you remove your -1 if you agree with the current version?

[kdambekalns]

Looks good now…

[albe]

D'oh, that was nop StyleCI PR :D

[albe]

We could also strip out the old autoloader instead of #2288, but TBH I never set the FLOW_ONLY_COMPOSER_LOADER=true env var to check if nothing breaks and I guess most didn't. Keeping the flag will at least provide an escape-hatch for another major version in case it causes problems.

[bwaidelich]

We could also strip out the old autoloader

I prefer the way you went with #2288 now since it leave us with the mentioned escape hatch, thanks for that!