Solved: After update to SVN client_add is broken? Hi, 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: PHP: $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', 'limit_web_quota'=>'-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 3.0.2.2 - 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!
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 ...
Hmm 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....
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 remoting.inc.php - However, a print_r($params) in this function, like so: PHP: 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.'); return false; } $affected_rows = $this->klientadd('../client/form/client.tform.php',$reseller_id, $params); return $affected_rows; } 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?
Ok so thinking logically about this: 1) My code worked perfectly before the SVN update 2) I did an SVN update using ispconfig_update.sh - 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 ... Update: 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: PHP: public function client_add($session_id, $reseller_id, $params, $testvar) { if (!$this->checkPerm($session_id, 'client_add')) { $this->server->fault('permission_denied','You do not have the permissions to access this function.'); return false; } 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); return $affected_rows; } 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
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. 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.
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: PHP: //* 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'])); $params=array_merge($params,$template); } 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: PHP: $aArray = array('one', 'two', 'three', 'four'); error_log(print_r($aArray, true));
try to change: if(isset($params['template_master']) and $params['template_master']) to: if(isset($params['template_master']) and $params['template_master'] > 0) See ISPConfig > Clients
Excellent - thanks for the feedback. I understand what client templates is all about now I implemented your tweak and it works.
Whoops 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.