Remove PHP selection using CMD_API_DOMAIN?

kristian

kristian

Verified User
Joined
Nov 4, 2005
Messages
490
Location
Norway
I'm looking for a way to remove the PHP selection for a domain entirely, so that it defaults/falls back to the first available version as defined in options.conf. It looks like CMD_API_DOMAIN is the API endpoint to use for this. I have some domains with this combination of settings (from CMD_API_ADDITIONAL_DOMAINS):

Code: 
["has_php_selector"] => string(2) "no"
["php"] => string(3) "OFF"
["php1_select"] => string(1) "3"

Based on the information provided on https://www.directadmin.com/features.php?id=1738 it seems that it should be possible to provide at least php2_select with the value 0 for off, but the same can't be passed for php1_select. The error I get when trying that is Error setting PHP versions: php1_select and php2_select must be 0-3.

I could remove the php1_select line directly from /usr/local/directadmin/data/users/<user>/domains/<domain>.conf, but I really want to do this with the API if it's possible. Any ideas?

(Edit/addition: Removing the selection is desirable even with php=on, and has_php_selector=yes, to let a domain use the default PHP version without it being specifically selected.)
 
Last edited:
php1_select=1
should be fine.

for detail how it work.

php1_select= php1_release

as you can see
php1_release equal to 1
php2_release equal to 2
... etc..

because "php1_release" is default for all domains / system / plugins / ..etc.., it should be fine.
 
Well, yes. But when a domain has PHP off, and no php selector, wouldn't it make more sense to not have it select a version specifically? Without a selector, there are also no phpX_ver values returned from CMD_API_ADDITIONAL_DOMAINS, so it doesn't really look like it's meant to work. That said, it does work changing the selection to 1 (using CMD_API_DOMAIN) even when the domain has no php or php selector.
 
Sounds reasonable. But this is not what we can change by ourselves, I guess. So, if the question is about changing a list of required parameters for CMD_API_*, then you'd better try your luck by opening a ticket with DirectAdmin support. Since they are about to change DirectAdmin commands, and possibly API, your request might have more chances to be satisfied.
 
If I were to go the route of just setting it to 1, is there any other place I can get the available PHP versions, or at least the default version, than in the result returned by CMD_API_ADDITIONAL_DOMAINS? I've been using the phpX_ver values from there to determine which versions is available for selection for the domain, but when they're missing, it gets a bit difficult. I use the actual version number to notify the client by email that we've changed the PHP version from X to Y for example. Saying it's been set to 1 isn't so useful for them.
 
As admin/reseller/user you might check this one /CMD_API_SYSTEM_INFO?json=yes
An access to the page might be blocked for end-users via package settings.
 
It is so very close to be exactly what I would need! It returns the full versions, but I can deal with that. What's strange though is that it returns 7.4 twice, and 8.1 not at all:

JSON: 
                "php":
                {
                        "name": "php",
                        "version": "7.4.32"
                },
                "php2":
                {
                        "name": "php2",
                        "version": "8.0.24"
                },
                "php3":
                {
                        "name": "php3",
                        "version": "7.4.32"
                },

This seems strange, considering options.conf has this:

Code: 
# grep ^php._rel /usr/local/directadmin/custombuild/options.conf
php1_release=8.1
php2_release=8.0
php3_release=7.4
php4_release=no

However I noticed that the default php binary /usr/local/bin/php is a symlink to /usr/local/php74/bin/php74 and not 8.1. Webapps (e.g. phpMyAdmin) are using 8.1 though, so why the cli binary symlink hasn't been updated is possibly a bug somewhere? A bit strange perhaps that CMD_API_SYSTEM_INFO returns 7.4.32 for php though. I wonder where it gets that information from..
 
I guess ./build php should fix the symlink.

Seems the CMD_API_SYSTEM_INFO gets a PHP version from a call to /usr/local/bin/php
 
I suspect what I did was reorder the PHP versions in options.conf, and then ran a ./build rewrite_confs which took care of the webapps PHP version. Doing a full recompile of all installed PHP versions seems like a massive overkill to change a few symlinks. Could perhaps this symlink logic also be performed when doing rewrite_confs? (@smtalk ?)

I'm rebuilding PHP on one of my servers now, so we'll see what CMD_API_SYSTEM_INFO returns afterwards. There must be some additional logic besides using the CLI versions found, since the others are obviously mapped to 2 and 3 somehow.
 
One ./build php and almost 30 minutes later, this is the result from CMD_API_SYSTEM_INFO:

JSON: 
                "php":
                {
                        "name": "php",
                        "version": "8.1.11"
                },
                "php2":
                {
                        "name": "php2",
                        "version": "8.0.24"
                },
                "php3":
                {
                        "name": "php3",
                        "version": "7.4.32"
                },

I also found these, that explains a little bit about how this works:

https://directadmin.com/features.php?id=1059 - it does indeed use the symlink for the first version, but this can also be disabled in directadmin.conf, making it not so reliable in a generic script.

https://www.directadmin.com/features.php?id=2173 - 2nd version was added, however it doesn't go into details on how it determines that something is the 2nd, 3rd or 4th version, and how it fetches those versions.
 
You must log in or register to reply here.
Back
Top