Move and consolidate PHP Versions screen to and with Website Options: PHP script execution mode screen

[calport]

Missing FPM as an option

If you have multiple versions of PHP installed on your system and FPM has been configured for some versions of PHP but not for the other versions / all versions of PHP, then Virtualmin behaves the way you have described. For example, some websites / virtual servers will offer FPM as an option if the currently selected version of PHP has been configured to use FPM while other websites / virtual servers will not offer FPM as an option under Virtualmin -> Server Configuration -> Website Options: P…

It would help avoid confusion if Virtualmin → Server Configuration → PHP Versions could be moved to and consolidated with Virtualmin → Server Configuration → Website Options: PHP script execution mode such that users would see option buttons for…

FCGId 5.4 (run as virtual server owner)
FCGId 7.0 (run as virtual server owner)
FPM 7.0 (run as virtual server owner)
FCGId 7.3 (run as virtual server owner)
FPM 7.3 (run as virtual server owner)

… on a system in which PHP 5.4 is installed without FPM and 7.0 and 7.3 are installed with FPM.

[Joe]

Agreed.

PHP configuration is absolute chaos, and is spread across several pages in the UI, making it far more confusing and time-consuming than it should be. I’ve talked about it with @Ilia and @Jamie in the past, we just haven’t come to a consensus about how to consolidate without limiting functionality (some things apply to per-domain configs, some things apply to system-wide decisions, and some things have security or compatibility considerations…“PHP” is a lot of problems to be solved in a lot of areas in the system). But, it does need to happen. It’s definitely a big source if friction.

[Jamie]

We could certainly consolidate PHP Versions and Website Options onto a single “PHP” page. And make the common case where only a single version is used for the domain easier, as likely not many people select different per-directory versions.

[Ilia]

@Jamie

… as likely not many people select different per-directory versions.

I think it’s true, as it’s hard to imagine a case where it could actually be needed.

… but we still going to have a link to PHP Configuration, which cannot be a part of Website Options.

What do we do with that?

[calport]

Food for thought - under Website Option screen, keep just:

• Default website for IP address?
• Webserver access log file
• Webserver error log file
• Redirect all requests to SSL site?

Move everything else to the PHP Configuration screen. So on this screen we have:
From Website Options screen

• PHP script execution mode (with enhancements for PHP versions described in the original message of this topic)
• Maximum PHP script run time
• PHP information

From PHP Versions screen

• Options listed under the enhanced PHP script execution mode

From PHP Configuration screen

• Everything which is already there

The end result is a consolidated PHP configuration screen which

• Lists available PHP versions, their modules and execution modes, for a user to select
• Specify PHP run time limit
• Manage PHP Configuration for the currently selected PHP version and execution mode:
  ** PHP Variables
  ** Directory Settings
  ** Database Settings
  ** Session Options
  ** Safe Mode Options
  ** Resource Limits
  ** Error Logging
  ** Other Settings
  ** Edit Configuration Manually

The PHP Versions menu option and screen could be done away with altogether. This would make things very clear to users.

[Jamie]

Yeah, that’s what I was thinking too. Split out all the PHP settings from the Website Options page to a new “PHP Options” page, which will also include the version.

[RJM_Web_Design]

It’s hard to think of a sensible case, but there are senseless cases out there.

One example I’m familiar with was a guy who ran a billing system on his site that required PHP 7-point-something, but the rest of the site wouldn’t work right with anything more than PHP five-point-something. As I recall there was a lot of mysql -> mysqli rewriting needed, as well, which I did for him.

I agree that it’s an unusual case. But it’s by no means unheard of. Ideally, it would be solved by making the changes needed to make the “old” part of the site run on the newer PHP. But especially in the shared hosting world, things are seldom ideal.

Richard