List all PHP-versions for all domains

HHawk79 said:
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
Click to expand...
To get the PHP information the plugin is currently reading the information which is displayed on the System Info page (to be sure which version is installed vs the version that is being set in the custombuild configuration).
On that page the PHP mode is not displayed and for the moment I would not like to base myself on the custombuild configuration file.

If you want to know which PHP mode is used it's maybe better to go the the custombuild plugin and check the "edit options" page to see which mode is selected?

WDYT?
 
How do I download an older version?
This customer's server is running outdated PHP and cannot update because of CentOS 6.x (catch 22).

Also in regards to your last remark; you cannot check PHP-version with Custombuild on CentOS 6.x. So that doesn't help.
 
HHawk79 said:
How do I download an older version?
This customer's server is running outdated PHP and cannot update because of CentOS 6.x (catch 22).

Also in regards to your last remark; you cannot check PHP-version with Custombuild on CentOS 6.x. So that doesn't help.
Click to expand...

Did you try to install the latest version of the plugin on that old server?
The code should be still PHP 5 compatible (in the readme I mention PHP 7 as I want to optimize some code)

Don't know much about how you would be able to see the PHP mode on the older installations.
Maybe if you find all the different versions that are used, you can do some phpinfo() on them supposing the mode is displayed in that information that you get?
 
Now getting an error on a new server with PHP 8.1 as first PHP-version:

Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 77

Any idea? :(
 
I just installed the addon freshly on a server which is using php 8.0 as default (php 1) and it does work, but the same error occurs.

Above these:
Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 136
Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 140
Click to expand...

and a bit lower these:
Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 243
Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 245
Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 247
Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 249
Warning: Undefined array key "php" in /usr/local/directadmin/plugins/phpversionlist/admin/index.html on line 251
Click to expand...

So I did a check and it's abou these lines, this is 136:
Code: 
        if ($data['php'] === 'ON' && !key_exists('php1_select', $data)) {
and 140
Code: 
            if ($data['php'] === 'OFF') {

and the others:
Code: 
                $phpEnabled = ($settings['php'] == 'ON') ? '<span style="color: green">ON</span>' : '<span style="color: red; font-weight: bold">OFF</
span>';
                $firstPhp   = (isset($settings['php1_select'])) ? $settings['php1_select'] : '1';
                $firstPhp   = translateValueToVersion($settings['php'], $firstPhp);
                $secondPhp  = (isset($settings['php2_select'])) ? $settings['php2_select'] : null;
                $secondPhp  = translateValueToVersion($settings['php'], $secondPhp);
                $thirdPhp   = (isset($settings['php3_select'])) ? $settings['php3_select'] : null;
                $thirdPhp   = translateValueToVersion($settings['php'], $thirdPhp);
                $fourthPhp  = (isset($settings['php4_select'])) ? $settings['php4_select'] : null;
                $fourthPhp  = translateValueToVersion($settings['php'], $fourthPhp);

Seems this might not be php 8.x compatible. Looking at line 140 there is only 1 occurence. So maybe php 8.x does not like single quotes 'php' statements, maybe that must be done in another way. I don't know, I'm no coder. ;)

Also maybe some small improvement may be possible, because third and fourth php never show anything and second on some domains show off but for the rest nothing. So I don't know where this is good for. DA changed something and it's not used anymore that way as far as I know.
I took a screenshot for you.
Maybe this can be removed to get space (maybe for something else in the future).

1669942066061.png
 
Last edited:
Found the cause of the problem I posted. It's a domain.com.hotlink.conf which is created by DA if hotlink protection is used by a user.
But since that is created as a .conf file in the same directory as domain.com.conf it's read as domain while it has totally different content.

So if this *.hotlink.conf file is filtered from reading, the php errors are gone. ;)
 
Richard G said:
Found the cause of the problem I posted. It's a domain.com.hotlink.conf which is created by DA if hotlink protection is used by a user.
But since that is created as a .conf file in the same directory as domain.com.conf it's read as domain while it has totally different content.

So if this *.hotlink.conf file is filtered from reading, the php errors are gone. ;)
Click to expand...
Thanks Richard!
Looks like I will able now to reproduce the issue. Expecting to release a new version soon!
 
zEitEr said:
Code: 
egrep php[1,2,3,4]_select= /usr/local/directadmin/data/users/*/domains/*.conf

where php1_select corresponds to the primary PHP version installed on the server, and php2_select/php3_select/php4_select correspond to the secondary PHP versions per custombuild options:

Code: 
[root@server ~]# /usr/local/directadmin/custombuild/build options | grep PHP
PHP (default): 5.6 as suphp
PHP (additional): 5.3 as suphp
PHP (additional, 3rd): 7.2 as suphp
PHP (additional, 4th): 7.3 as suphp
[root@server ~]#

So, let's say you have PHP 7.2 installed under PHP 3rd, so run

Code: 
egrep php3_select=1 /usr/local/directadmin/data/users/*/domains/*.conf

to list config files for domains with PHP 7.2.
Click to expand...
In case anyone's using the above method instead of plugin - it's always php1_select in my case (php version for domain) and =[1,2,3,4] are php versions installed in DA.

I found, that some .conf files do not list PHP versions, and those domains are using system default version. Can check with:

Code: 
egrep -L php1_select /usr/local/directadmin/data/users/*/domains/*.conf
 
ericc said:
In case anyone's using the above method instead of plugin - it's always php1_select in my case (php version for domain) and =[1,2,3,4] are php versions installed in DA.
Click to expand...

Yes, directadmin developers changed a method of using additional PHP versions a while ago. And my reply might be bit outdated already.
 
@wavoe I encountered an error on a freshly installed directadmin version.

I used the method described to install the package and this error occurs:
phpversionlist successfully downloaded
Error unpacking /usr/local/directadmin/plugins/phpversionlist/plugin.tar.gz : Error restoring file /usr/local/directadmin/plugins/phpversionlist/plugin.tar.gz : gzip: stdin: unexpected end of file /bin/tar: Child returned status 1 /bin/tar: Error is not recoverable: exiting now : tar returned error code 2

No install.sh script was found. Script not executed.
Error with install script
Click to expand...

Now that is odd, because when I just download it with wget, there is no error when extracting the file.
Also when I select to only download the file from the plugins section (and not install afterwards) the same tar error is displaying.

Tried manually with curl:
Code: 
curl -s https://wavoe.bitbucket.io/phpversionlist/phpversionlist.tar.gz | tar zxv
not a single issue downloading and unpacking the file.

When checking the file system, in the plugins directory only the plugin.conf (23 bytes or kb) and plugin.tar.gz (0 bytes) are present.

So something goes wrong, but I don't know why.
 
Richard G said:
@wavoe I encountered an error on a freshly installed directadmin version.
Click to expand...
I experience the same issue indeed after deleting the plugin and trying to install it again via the bitbucket.io url.
I don't see any details on how it's being downloaded sadly.
And I also see now that the plugin is apparently not able to update itself anymore?

When installing it via a manual download / file upload afterwards it's working well.
I also did a try by putting the tar.gz file on another (own) domain. This is working as well.

Without more details from DA itself it will be hard to find the cause of the issue.
Looks like something related with bitbucket.io/cdn network maybe/..?
 
wavoe said:
When installing it via a manual download / file upload afterwards it's working well.
Click to expand...
I don't know if it's a DA issue, since I also installed the Letsencrypt Domains plugin from @Erulezz which was installed without any issues.
As was the configserver mailqueue.
No clue on how DA downloads it, mostly likely via wget or curl I guess, but those went fine.

I don't know if maybe unpacking and repacking could help fixing it.

Exactly how can I install it manually? Just unpack and place all files in the plugin directory? Is that all?
Or should I do something else?
 
@wavoe I think I found the cause of the problem. For some reason it's not working with/from bitbucket.io.

I downloaded the tar.gz to the newly installed server on a newly created domain and used the add https://etc. from there and worked without an issue.
Now to be sure if that is the cause, I doublechecked and used my own domain on a totally different server, put the tar.gz in the public_html and used again the same installation procedure and again working perfectly.

So I don't know exactly what is going wrong with bitbucket, but using another url seems to work fine.
 
rimsha said:
To list all domains with PHP version 7.2 installed, you need to access the server hosting your domains. The steps may vary depending on your server environment:

  1. cPanel: Log in to your cPanel account, select the PHP version as 7.2, and search for .php or .php7 files in your domain's document root directory.
  2. Direct server access: Connect to your server via SSH, navigate to the document root directory, and use the command find. -type f -name "*.php" to locate PHP files associated with your domains.
For shared hosting, contact your provider for assistance.
Click to expand...
Please stop giving copy&paste answers, Cpanel ? really ?
 
@wavoe is this still supported?

In DA now I get a message that phpversionlist should be updated:

PHP version list1.8.0Upgrade Required

However... when downloading it's still says version 1.8.0, next to the bug that for some reason the bitbucket.io causes some error.
Just wondering as to why this "upgrade required" suddenly seems to appear while imho no new version is present or required.

Or anybody else having the same?
 
You must log in or register to reply here.
Back
Top