After update to SVN client_add is broken?

Discussion in 'Developers' Forum' started by zabersoft, Sep 7, 2010.

  1. zabersoft

    zabersoft New Member

    Solved: After update to SVN client_add is broken?


    I updated to the latest SVN to solve the old problem with sites_web_domain_add - But now my client_add function is no longer working. The user gets created, but none of the values I send in $params gets saved (i.e. user name company name etc. etc. are all empty)

    These are the params I am sending, and how I call client_add:

            $params = array(    'server_id' => 1,
    'company_name' => $add_company,
    'contact_name' => $add_fullname,
    'username' => $add_username,
    'password' => $add_password,
    'language' =>'en',
    'usertheme' =>'default',
    'street' =>$add_address,
    'zip' =>$add_zip,
    'city' =>$add_city,
    'state' =>'non-US',
    'country' =>'DK',
    'telephone' =>$add_phone,
    'mobile' =>'',
    'fax' =>'',
    'email' =>$add_email,
    'internet' =>'',
    'icq' =>'',
    'notes' =>'CVR Nummer:'.$add_cvr,  
    'template_master' => '1',
    'template_additional' =>'',
    'default_mailserver' =>'1',
    'limit_maildomain' =>'1',
    'limit_mailbox' =>'-1',
    'limit_mailalias' =>'-1',
    'limit_mailforward' =>'-1',
    'limit_mailcatchall' =>'-1',
    'limit_mailrouting' => '-1',
    'limit_mailfilter' =>'-1',
    'limit_fetchmail' =>'-1',
    'limit_mailquota' =>'-1',
    'limit_spamfilter_wblist' =>'-1',
    'limit_spamfilter_user' =>'-1',
    'limit_spamfilter_policy' =>'-1',
    'default_webserver' =>'1',
    'limit_web_domain' =>'-1',
    'web_php_options' =>'mod',
    'limit_web_aliasdomain' =>'-1',
    'limit_web_subdomain' =>'-1',
    'limit_ftp_user' =>'-1',
    'limit_shell_user' =>'-1',
    'ssh_chroot' =>'no',
    'default_dnsserver' =>'1',
    'limit_dns_zone' =>'-1',
    'limit_dns_record' =>'-1',
    'limit_client' =>'0',
    'default_dbserver' =>'1',
    'limit_database' =>'-1',
    'limit_cron' =>'0',
    'limit_cron_type' =>'',
    'limit_cron_frequency' =>'-1',
    'limit_traffic_quota' =>'-1');

    $client_id $client->client_add($session_id$reseller_id$params);
    I've checked in client.tform.php to see if you have made any changes to the table definitions but I see no change from stock - So I am thinking some underlying change was made that I need to be aware of - or that it is simply broken in the latest SVN - Any info on this would be cool

    As usual - Thanks for all the great feedback!
    Last edited: Sep 9, 2010
  2. zabersoft

    zabersoft New Member

    And no - before you ask - my variables I am using to set the values in $params are not empty ;)

    Update: Another thing - I checked out the remote users in the backend and saw that suddenly client functions and a few other things were unchecked for my remote user. So i enabled those and hit save - but the problem persists. I didn't suspect this in the first place as I remember the remote functions throwing errors if my remote user doesn't have the appropriate rights. So I don't think this is relevant - but I thought I might as well mention that I had checked this ...
    Last edited: Sep 7, 2010
  3. zabersoft

    zabersoft New Member


    Ok well I guess I need to start debugging the code - doesn't look like anyone has an easy answer. Where do you think I should start looking for the most likely suspect that would cause an insertion into the client table with null values?

    I bet it's going to be something really simple.... ;)
  4. zabersoft

    zabersoft New Member

    Debugging underway

    Ok so this is what I have found so far ... It is certainly strange, and I can't quite tell how updating to the latest SVN would result in this weirdness - but this is what I am seeing:

    A print_r($params) right before I call the SOAP function client_add like so:

    $client_id = $client->client_add($session_id, $reseller_id, $params);

    Looks all fine and dandy - that is, the array is filled out nicely.

    I then assume that the parameters are sent directly to the client_add function in - However, a print_r($params) in this function, like so:

        public function client_add($session_id$reseller_id$params)

    error_log(print_r($params)); //my debug code

    if (!$this->checkPerm($session_id'client_add'))
    $this->server->fault('permission_denied','You do not have the permissions to access this function.');
    $affected_rows $this->klientadd('../client/form/client.tform.php',$reseller_id$params);

    Results in it returning "1" - that is, a truncated array/messed up variable. Now my question is: Is anything happening before client_add? As far as I can see in the code the SOAP server is invoked and the remoting class is loaded - so logically speaking nothing should be happening to the $params array between my call to the function and the function executing. Please correct me if I am wrong here.

    I just did a check and the $reseller_id and $session_id variables are passed through to client_add just fine.

    Certainly strange, no?
  5. till

    till Super Moderator Staff Member ISPConfig Developer

    Thats correct.

    Anyone else has this problem with the current SVN version?
  6. zabersoft

    zabersoft New Member

    Ok so thinking logically about this:

    1) My code worked perfectly before the SVN update
    2) I did an SVN update using - reconfigured services
    3) Suddenly my code stops working

    - I then do the debug steps above which reveal that an array can no longer be passed through to client_add via. SOAP. Other variables go through fine.

    So - my instincts tell me that something during the update process changed something in the way PHP handles SOAP requests. Does ISPConfig change PHP settings when services are reconfigured? I have started thinking in system fundamentals here - but I'm not sure where to begin to look ...

    Just to confirm that the problem lies with passing an array to SOAP I tried adding a variable to the client_add function and passing a hardcoded string - like so:

    $client_id = $client->client_add($session_id, $reseller_id, $params, "testing other var");

    and client_add looks like so:

            public function client_add($session_id$reseller_id$params$testvar)
                    if (!
    $this->server->fault('permission_denied','You do not have the permissions to access this function.');

    error_log("In client_add testvar: ".$testvar." AND printr params ".print_r($params)." AND noprintr ".$params." AND session ".$session_id." AND reseller ".$reseller_id);

    $affected_rows $this->klientadd('../client/form/client.tform.php',$reseller_id$params);


    this outputs the following in my php debug log:

    [08-Sep-2010 13:40:27] In client_add testvar: testing other var AND printr params 1 AND noprintr Array AND session 37207531d0a1f7847b63dad2bad934a3 AND reseller 11

    So you can see - Strings and integers go through fine - PHP sees $params as being an array, but a print_r just returns "1" - Which I personally have never seen happen before in any other context
    Last edited: Sep 8, 2010
  7. zabersoft

    zabersoft New Member

    The plot thickens...

    Ok so now the plot thickens somewhat. I got bogged down in looking at my client_add function so I ignored trying to see if the other functions were working - so I just did a quick test where I call the defunct client_add function (which, as mentioned, fails filling in any DB fields) and then subsequently calling sites_web_domain_add - here $params seems to go through just fine!!

    The DB for web domains looks just peachy. So the $params array is being picked up by ISPConf just fine.

    This seriously confuses the heck out of me - because that now indicates that the problem is at my end. Something which I was sure I had ruled out.

    :confused: :(

    I guess I will go back to basics and make some stripped down test scripts - as I am using a pretty monolithic infrastructure right now that I've built over the last few weeks - that will maybe shed some light on the issue.
  8. zabersoft

    zabersoft New Member

    Problem tracked down!

    Alright - I've found the issue - this seems to be at least partially an ISPConf bug. Here's the rundown:

    1) The reason I was seeing that strange output from my $params array in my debug attempts is simply due to the fact that the function error_log doesn't like print_r so it truncates the output. So in fact my array values were making it through just fine to client_add - and not being mangled by SOAP as I was thinking.

    2) So now I traced how far $params survived - and of course what was happening was that this part of klientadd() was clearing the $params array:

            //* load the client template
    if(isset($params['template_master']) and $params['template_master'])
    $template=$app->db->queryOneRecord("SELECT * FROM client_template WHERE template_id=".intval($params['template_master']));
    So now my question is: Why is $params['template_master'] set while $template is empty? What is this template stuff? How do I clear this $params['template_master'] variable which is causing this code to run and emptying out my $params array?

    Whew man... I'm very glad I finally tracked this down :)

    Update: BTW As of PHP 4.3.0, there is an optional second parameter to the print_r function which is a boolean dictating whether the output from print_r is actually output (default) - which breaks error_log - or returned as a string.

    The code can be therefore slightly altered to something more like:

    $aArray = array('one''two''three''four');
    Last edited: Sep 9, 2010
  9. till

    till Super Moderator Staff Member ISPConfig Developer

    try to change:

    if(isset($params['template_master']) and $params['template_master'])


    if(isset($params['template_master']) and $params['template_master'] > 0)

    See ISPConfig > Clients
  10. zabersoft

    zabersoft New Member

    Excellent - thanks for the feedback. I understand what client templates is all about now ;)

    I implemented your tweak and it works.
  11. zabersoft

    zabersoft New Member


    Hi till,

    I just thought I'd let you know that I gave you bad information. I thought I had implemented your fix as described above originally - but as I was setting up our system on a fresh server today I noticed that I had in fact not.

    On a virgin fresh debian / ISPConfig 3 installation (SVN checkout) I see that you have added this fix to the SVN. However the problem is still present.

    They way I had fixed it before, was commenting out the client template code entirely (the whole if(isset($params['template_master'] ... statement)

    I thought I had applied your fix before - but something must have gone awry and I was still running with my old "hack"

    So, FYI this is still not fixed in the SVN.

Share This Page