API documentation is wrong: Setting things to "OFF" does not disable them (CMD_API_DOMAIN)

bloop

Verified User
Joined
Jul 17, 2021
Messages
18
I already solved this but I figured I would make a post about it, since the documentation tells you the wrong thing:


It says:
ssl=ON or OFF
cgi=ON or OFF
php=ON or OFF
but this is wrong. If you transmit "cgi=OFF" in your request, it will turn cgi on. It will turn it off if you omit the cgi paramter completely. Presumably the same is true of the other two as well. So now I accidentally enabled cgi on a bunch of domains without meaning to. Not the end of the world, but I figured I would post here so the documentation can get fixed, or at least someone else may find it helpful.
 
I think you can post this to the support even if your license doesn't include tech support because usually they fix the documentation if it's wrong and if this is a bug in the software, this sounds quite bad because you enable services you never wanted to and thus open potential security holes. Maybe you wait a week or two to see if they react to this thread.
 
I don't actually have a license at all, I just use a hosting provider that gives you directadmin on your server as a management panel
 
It is great to see this API can be used by a normal user so that they can get more attention (maybe?). I had been waiting many years to see the well-documented and pleasant-looking API page. But... still, I can see ugly looking API page. Lack of examples of how you can make it work and some API usage you need to make it work by your powerful instinct (whether to use CMD_API or without the API keyword). Sometimes, you have to try and error to make it work. In conclusion, the API documentation ***k so bad.


my expectation:

1666997128339.png



and what I see:


1666997149579.png




Sorry for the honest expression :)

My suggestion is, they should let the community edit the documentation page and approve it later. Linode did this, which is why they have a well-documented system.
 

Attachments

  • 1666997115142.png
    1666997115142.png
    230.5 KB · Views: 9
Last edited:
My suggestion is, they should let the community edit the documentation
As far as I know they hired @scriptkitty to keep the documentation up to date. If I'm not mistaken.
I mentioned here, but indeed it would be good if docs would be kept up to date, but mistakes have to be reported. Hopefully it will get fixed soon.
 
As far as I know they hired @scriptkitty to keep the documentation up to date. If I'm not mistaken.
I mentioned here, but indeed it would be good if docs would be kept up to date, but mistakes have to be reported. Hopefully it will get fixed soon.

Ohh, that is something new to me. I'm not trying to hurt anyone's feelings. I hope the DA team can let the community contribute to this documentation instead, so @scriptkitty would have less stress as we all work together to make the documentation perfect ^_^
 
Is @scriptkitty still here? Have not seen her here for long time.

Not sure. I sent her a PM in September about a bunch of documentation errors that could use fixing, but never heard back (she hasn't been online since I sent the PM).

It would be handy to know where such things should be reported. Could well prevent the need for tickets being opened which I'm sure is something the whole DirectAdmin team will appreciate.

Eitherway, the errors I reported were:

https://docs.directadmin.com/webservices/php/php-options.html says mod_php is the default, but that's contrary to what CB says:
# ./build opt_help | grep "webserver\|mpm\|php._[mode|release]"
php1_release: 5.3, 5.4, 5.5, 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1, 8.2. Current value: 7.4. Default value: 8.1.
php1_mode: php-fpm, fastcgi, suphp, lsphp, mod_php. Current value: php-fpm. Default value: php-fpm.

And https://docs.directadmin.com/webservices/apache/general.html says ./build php1_mode fastcgi instead of ./build set php1_mode fastcgi
 
Back
Top