List all PHP-versions for all domains

I presume you also set php2_release=no so that is where it's coming from then it seems. Might be wise indeed to put the choice in these domains backup to 1 indeed.
And instantly the benefit of such tool is shown. :)
 
At one time I had php 8 (2) and 7.4 (1) installed. The 2 no domains were set to php 8
Then uninstalled php 8. So it must fall back to position 1 if you remove all other positions.
Makes sense. Did you verify that the "no" domains in fact used your default 7.4 version? If so, I can update the script to catch it.
 
Did you verify that the "no" domains in fact used your default 7.4 version?
I assumed since it was only php_1 even installed it was. I can verify it for you if you want me to use a certain cmd related to the script I can.
 
I assumed since it was only php_1 even installed it was. I can verify it for you if you want me to use a certain cmd related to the script I can.
I'm not sure what the logic is when you rebuild php and a selected option goes away. It would make sense that the user configs are rewritten, and fall back to the default version, but I can't remember if the rewrite is part of the php build. Best way to test I guess is to check the config. :) I'll test on a dev server and see what happens.
 
Maybe I don't know how to uninstall something with CustomBuild properly, but I performed these steps:

* Change options.conf to have php4_release=7.3 (was previously no)
* ./build update_versions
* Switched to 7.3 for a domain, and verified that it was now using 7.3
* Changed php4_release back to no in options.conf
* ./build remove_items (only way I could find to uninstall 7.3)

At this point, interestingly enough, the php-fpm processes are still running for 7.3, connected to the user of my domain, but accessing the website returns a "503 Service Unavailable", since I guess all the 7.3 binaries are now gone.

A ./build rewrite_confs did not fix the PHP selection for my domain, it still has php1_select=4 in the .conf file. When looking at the selection dropdown inside DA, it says 7.4 (my current php1_release in options.conf), even though that's not the case.

I don't know if I've missed something obvious here, but it doesn't seem like there's any automatic or semi-automatic way of giving an existing PHP version to a domain when their current one has been removed?

This is getting a little off topic, but as far as my script goes, I'll leave it as is for now, at least until there is some clarification on how this should be dealt with. :)
 
The only difference you have which is interesting.

I only had 2 php versions installed not 4. Since you have more than one at all times php selector is always on.

So try
php1_release=whatever you have now
php2_release=7.3
php3_release=no
php4_release=no

I think the difference in my scenario is once I set php2_release=no you wont have PHP version selector avalable. So maybe the system knows and falls back to php1_release=

In short start with only 2 php versions installed the go down to only one. then see what happens.

As far as off topic I am ok either way.
 
* ./build remove_items (only way I could find to uninstall 7.3)
You can also use:
./build remove_php 7.3
but normally the ./build remove_items might be better I think.

it still has php1_select=4 in the .conf file. When looking at the selection dropdown inside DA, it says 7.4 (my current php1_release in options.conf), even though that's not the case.
Correct, and IMHO this is a bug. See my other topic about this.
Because no selection is automatically put to php1, without changing the php1 setting, but suppose you create a new php version in a year, then this specific user is suddenly set to a new php version which he might not want to use or website is not working on, because this setting is not removed (or changed).

Indeed has nothing to do with your list script, but for php settings this might cause odd issues for DA customers in the future.
 

I tried the plugin, but I am just getting a blank page (with DA header and footer section; middle is empty). It's not showing anything.
Does this plugin still work?

//edit1
Weird on my own server, it does work. Not on the customer's server. Though he/she is still using the old interface skin. Maybe that's the issue?

//edit2
Changed the skin on the customer's server to Evolution, but still shows up blank. Any ideas what to try next?
 
Uhmz... I *think* the issue is that this server is still on PHP 5.3 on CLI. I think that might be causing issues.
Will see if I can force the script to use a newer PHP version from somewhere else.
 
This plugin indeed need "PHP 5.6 and up"
if it is still not working, try delete 'shell_exec' function from the list of disable_functions in your global php.ini (maybe the plugin custom php.ini is not picked up)
 
Thanks. But the issue seems indeed to be PHP 5.3. Old server. :S
'shell_exec' is not being listed in the php.ini (global) so that's not blocking it. Guess I will check it the old way. Thank you nevertheless.
 
We have Almalinux 8.xserver which has 5.6 as second php or is that too new :)

Are you sure?! I thought that wasn't possible? I *think* I tried once, but if I recall correctly, it wouldn't install PHP 5.x versions...
But maybe I am mistaken? My brain is not working as it should as of late. ;-)
 
Not sure about Almalinux but on Debian 11 PHP 5.6 is still working, PHP 5.3->5.5 are not compatible with current OpenSSL versions anymore.
 
This can maybe help for you: PHP version list plugin: download it here. Project page: here

I still use this script every now and then. Excellent work! Though I am missing one function.
Would it also be possible to display the PHP type being used? E.g. php-fpm, fastcgi, suphp, lsphp and mod_php.

Especially the last one is important to me, so I can check which sites are still running on the very outdated mod_php.

Thanks in advance!

Regards
 
Back
Top