Oops, I just replied to your other similar thread. This one is better though as it has screenshots. So I'll move my response to this post and delete the other thread.

comes with obselet php version

It's not obsolete in Debian! It's maintained with security updates, for at least the next 4 years. It's also worth noting that Joomla 4 is supported on PHP 7.4 and it's likely that will be the case for some time. I know it's not the "recommended" version for Joomla (which incidentally is 8.0 - the version immediately after 7.4), but it should work fine and unless you have significant traffic to your site, I would imagine that it would be near impossible to tell from the end user perspective.

Would be cool to provide a definitive guide for this [updating PHP] process.

Ultimately I agree but I tried that. I'm not 100% sure which thread now (because there are so many). I spent ages going through the process start to finish and documenting as I went and it "just worked" for me. But even then, many users reported that it didn't work for them!? I could try again I guess, but it's pretty frustrating when I spent a ton of time on it and it ended up feeling like a complete waste of time and just created more work for myself...

What I do hope to do is create a script that will allow users to do this easily. But that's not as easy as I had hoped (and we always have tons of competing priorities and I never have as many spare cycles as I'd like). Plus Debian 12/Bookworm will be out soonish (which will be the basis of TurnKey v18.x) and that will have PHP 8.2 (with all the advantages of an officially Debian supported version of PHP).

No doubt the issue will occur again later in the lifetime of v18.x (once PHP 8.2 gets a bit dated) although hopefully won't be quite as bad (the timing of the Debian 11/Bullseye freeze meant that it didn't get PHP 8.0 as it possibly should have - which would have made this issue less significant, PHP 8.2 is much earlier in the PHP lifecycle than 7.4 was when Bullseye was released).

1-once php version is updated and enable, why in the webmin admin still shows 7.4,

Unlike many other apps, PHP config is in version specific locations. So you need to tell Webmin where to find the new version. Also the location is dependent on the usage context. E.g. the location for PHP 8.1 when run under mod_php (Apache) is: /etc/php/8.1/apache2/php.ini.

So you can either just edit that file directly via the CLI - nano is pre-installed which should be pretty self explanatory. E.g.:

nano /etc/php/8.1/apache2/php.ini

And/or you can update the Webmin config to point to the correct file. I don't have Webmin handy right now, but if I recall correctly, on the Webmin PHP page, there should be a cog icon (near the "PHP" heading, or perhaps in the top right corner, sorry I don't recall exactly). Once that is clicked you should be able to edit/add the config file location that it uses.

2- i went to check those error on the php.ini corresponding to 8.1 and cant find the some settings on it for example

PHP Upload Size bigger than POST size.

That error message is because upload_max_filesize (size of individual file uploads) is larger than post_max_size (total size of individual post) - in the php.ini. At the very least, post_max_size should be the same as post_max_size, but generally much bigger. E.g. if you have a form that allows uploading 3 files, then the upload_max_filesize should be the maximum individual file size and the post_max_size should be 3 times upload_max_filesize at least (probably a little higher to account for other non-file data being posted).

While you're at it, it might also be worth bumping memory_limit - that is the maximum memory that PHP is allowed to use. How big you make that will depend on the resources that your server has available, so I can't be prescriptive about that.

Other settings that are worth being aware of (may not need any adjustment at this point) is max_execution_time and max_input_time. As their names suggest, they relate to time rather than memory limits (so are essentially more CPU bound). I've personally never touched max_input_time, but it's not uncommon to need to bump max_execution_time, especially on servers with limited CPU and/or PHP apps that are fairly resource intensive.

3- is there any way to provide the container with latest php V out of the box?

We could, but we don't think the tradeoff is worth it. If you use the default PHP provided by Debian, you get automatic PHP security updates. If you use the third party PHP, then you lose that and need to manually maintain PHP (i.e. keep an eye out for PHP security issues and update when required). So we only include newer PHP versions when software explicitly requires it.

Having said that, creating a way to automate third party PHP updates is also something that I'd like to look at, but I'm not sure when I might get to that (it'll likely be after I've made it easier to update PHP).

Hopefully that's of some value to you?!