You can't do this sadly it's a b/c break because in the framework package the request object isn't stored by reference in the input object (deliberately). We tried this before and it ended up breaking extensions who were mixing editing $_POST directly and using JInput :(

Shit. Should we then not change the 4 branch to use the fw input classes? For example here https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/CMS/Application/CMSApplication.php#L119.

Can we also not just keep that code part in 3.8? Can you point me to the code line which makes the difference between the CMS and fw? Perhaps I will find a way to solve it.

So in the framework https://github.com/joomla-framework/input/blob/master/src/Input.php#L104 we set the line equal, in the CMS it's by reference https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/input/input.php#L94 (this means if you modify $_POST or $_GET directly it will be changed in the Input class as well in the CMS, and that's not the case in the framework). There was a long discussion about this at #3617 (comment) and we decided that we couldn't directly alias the input package

You're also now using the framework filter class rather than the CMS one which technically could also add in minor b/c breaks (although that's more theoretical)

You're also now using the framework filter class rather than the CMS one which technically could also add in minor b/c breaks (although that's more theoretical)

It's not theoretical. The Framework Filter package doesn't have awareness of stripping USC characters.

The other problem with just straight using the Framework code is the security shield stuff for file uploads doesn't exist there right now either.

So long and short, the state that we're in as far as code use in the 4.0 branch is the best we can do, and considering the minor potentially breaking changes between the CMS and Framework, I don't think I want to try and force much more into 3.x. If this PR becomes nothing but namespacing the classes and backporting the deprecation notices, IMO it's fine to merge.

I'm using the filter class from the CMS https://github.com/joomla/joomla-cms/pull/16939/files#diff-64f8299bd9f5d30f497015027a7af01aR13.

I was looking at the same location already and both are using the same code $this->data = &$_REQUEST;. I don't see a difference here between the core and the fw, I must miss here something.

Ahh ok so two things

1. Apparently I reverted that break ages ago joomla-framework/input#15 (only in the framework v1 branch - so it's still going to be an issue in Joomla 4 potentially).
2. I totally missed the replacement input class https://github.com/joomla/joomla-cms/pull/16939/files#diff-ac6f076de1d9da99309b4a8f36711239R30 I saw the file deleted and for some reason totally missed the new one and thought you'd just aliased directly to the framework.

I think we're probably ok then?

Question is then how what do we want in Joomla 4? I guess there we can decide. I mean would it make sense to have it differently in the core than the fw in 4?

On a read this looks fine. We should probably move getArrayRecursive to the Framework package at some point. The other big thing we need to look at during 4.x is moving the upload shield code into the Framework too, which should be painless as long as it's all decoupled from CMS logic (component params for example).