Warning error: curl_setopt() expects parameter 2 to be long

ejohnson
Regular Participant

Warning error: curl_setopt() expects parameter 2 to be long

I recently moved my website to a different server and the following Warning/Error showed up:


 


warning: curl_setopt() expects parameter 2 to be long, string given in /files/cc/cc_class.php on line 861.


 


Now the code on line 861 is from the Constant Contacts cc_class.php file, which remains untouched except for the login, password, and apikey variables.


 


The function that is being called is the function doServerCall($request, $paraeter='', $type="GET") and it's getting to the last SWITCH case, where line 816 is:


 


curl_setopt ($ch, CURLOPT_GET, 1);


 


Any idea how I can get rid of this warning? I'm going to have to look further on the old server and see if maybe I was just suppressing warnings from being displayed.


 


I searched the forum but couldn't find anything on this.


 


Thanks for any help. If you need any more information, let me know.


 


The Old Server was running:


PHP Version 5.2.6

cURL support: enabled

cURL Information: libcurl/7.18.2 OpenSSL/0.9.7l zlib/1,2,3 lilidn/1.9


 


The New Server is running:


PHP Version 5.3.1

cURL support: enabled

cURL Information: 7.19.7

Age: 3 Features:

AsynchDNS: No

Debug: No

GSS-Negotiate: Yes

IDN: No

IPv6: Yes

Largefile: Yes

NTLM: Yes

SPNEGO: No

SSL: Yes

SSPI: No

krb4: No

libz: Yes

CharConv: No

Protocols: tftp, ftp, telnet, dict, ldap, http, file, https, ftps

Host: universal-apple-darwin10.0

SSL Version: OpenSSL/0.9.8l

ZLib Version: 1.2.3

8 REPLIES 8
ejohnson
Regular Participant

Actually, I'm getting some other problems as well.


 


When I try to unsubscribe an e-mail (using $ccOBJ->removeSubscriber($email_address)), it works, but it's takes like 5 minutes to perform the action and the following warnings and cURL errors occur:


 


Warnings:


 


* warning: curl_setopt() expects parameter 2 to be long, string given in /files/cc/cc_class.php on line 861.


* warning: curl_setopt() expects parameter 2 to be long, string given in /files/cc/cc_class.php on line 861.


* warning: date() : It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EDT/-4.0/DST' instead in /files/cc/cc_class.php on line 573.


* warning: date() : It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/New_York' for 'EDT/-4.0/DST' instead in /files/cc/cc_class.php on line 573.


 


cURL Debug Messages:


 


SSL read: error:00000000:lib(0):func(0):reason(0), errno 54


 


^ Same thing occurs for the Edit Subscriber function: $ccOBJ->editSubscriber(), except it's not actually updating the database.


 

ejohnson
Regular Participant

So, I downloaded the latest cc_class.php file, moving from version 1.0 to version 2.0.0. This fixed the warning: curl_setopt() problem.


I then had to put the following at the top of the page:


 


ini_set('date.timezone', 'America/Toronto');


 


This fixed the warning: date() problem.


However, it still takes like 5 minutes to perform an update or delete a subscriber. I still get the following:


 


SSL read: error:00000000:lib(0):func(0):reason(0), errno 54


 


I need some suggestions please?

David_J
Employee

There have been a few reports of a PUT statement hanging for an extended period of time on certain server configurations. Typically, this issue has been resolved by others by making a small modification to the cURL options in your cc_class.php file.


 


Original line:

curl_setopt($ch, CURLOPT_PUT, 1);

 

Update to:

curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT");


 


However, this should not be impacting the DELETE operation, which is what you would use for Opting-out a Contact. However, if by delete you are performing an http PUT and removing all of the <ContactList> nodes to remove a subscriber from certain lists, then this would explain why that operation is hanging as well.


 


I hope this helps. If this does not resolve the issue you are experiencing please let us know.

David J

ejohnson
Regular Participant

Hi David, thanks for the answer.


 


Making this change actually did solve the DELETE opteration. I came across this thread earlier today ( http://developer.constantcontact.com/node/1041#comment-2179 ), which basically describes my issues that I'm encountering. Accept the page wasn't completely timing out, it was eventually completing the operation, but would take > 5minutes. The slowness is fixed now, but as reported in the other thread, editing the subscribers does not work anymore.


 


Any ideas what's going on with that issue?


*Edit


After some further testing, the only operation that works is the Sign-up page. The Edit and Remove Subscriber page no longer has a "timeout" issue, but rather completes and returns a 400 Error code.

ejohnson
Regular Participant

Well, to fix my Unsubscribe, I had to change the php code provided from: $ccContactOBJ->removeSubscriber($email_address) to $ccContactOBJ->deleteSubscriber($email_address). Not totally sure why the removeSubscriber function does not work.

ejohnson
Regular Participant

Well, I decided to install the RESTclient suggested to debug XML and to see if I could find why the EditSubscriber function is throwing a 400 error.


 


Here i my XML generated:


 


<?xml version="1.0"?>

<entry xmlns="http://www.w3.org/2005/Atom">

<title>TitleNode</title>

<updated>2010-05-14T12:27:22+01:00</updated>

<author><name>CTCT Samples</name></author>

<id>http://api.constantcontact.com/ws/customers/my_username_here/contacts/1</id>

<summary type="text">Customer document</summary>

<content type="application/vnd.ctct+xml">

<Contact xmlns="http://ws.constantcontact.com/ns/1.0/">

<EmailAddress>eric@mydomain.com</EmailAddress>

Customer document

<FirstName>Eric</FirstName>

<LastName>J</LastName>

<MiddleName></MiddleName>

<CompanyName></CompanyName>

<JobTitle></JobTitle>

<OptInSource>ACTION_BY_CONTACT</OptInSource>

<HomePhone>111-111-1111</HomePhone>

<WorkPhone></WorkPhone>

<Addr1>111 Test Court</Addr1>

<Addr2></Addr2>

<Addr3></Addr3>

<City>NF</City>

<StateCode>ON</StateCode>

<StateName></StateName>

<CountryCode>ca</CountryCode

><PostalCode>L2G 3V3</PostalCode>

<SubPostalCode></SubPostalCode>

<Note></Note>

<EmailType>HTML</EmailType>

<ContactLists>

<ContactList id="http://api.constantcontact.com/ws/customers/my_username_here/lists/3"/>

</ContactLists>

</Contact>

</content>

</entry>

 


If I followed the instructions correctly and should be using PUT for the HTTP Method in the RESTclient, then the problem appears to be:


 


HTTP/1.1 415 Unsupported Media Type


 


This is such a pain since the script works on another server running older PHP and cURL.

David_J
Employee

I have tested your XML and was able to use it to create a new contact without any modifications other than changing the usename to my own. If you are using the REST Client and are recieving the error 'HTTP/1.1 415 Unsupported Media Type', this may be due to the content-type you are using to POST your XML. In this situation, the body tab of your 'HTTP Response' section would also read "Error 415: Content type: 'text/plain; charset=UTF-8' is not accepted by this collection. Accepted type(s) are: 'application/atom+xml;type=entry'."


 


If this is the case, on the 'body' tab of the REST Client 'HTTP Request' section, you can see the default content-type is 'text/plain' - try adjusting this to 'application/atom+xml' and make your request again. This should create the contact eric@mydomain.com in the contact list and has an id of '3'.

David J

ejohnson
Regular Participant

David, thanks for the reply. I didn't think the problem was with the XML, since the exact same XML works on the old server ( http://cavespring.ca/newsletter/update ). However, on the new server ( http://209.159.189.58/newsletter/update ) I can't figure out a fix for the 400 error. Obviously, a setting with the new version of php and cURL must be playing a factor.


 


Did any one on the Constant Contact team ever find a solution to the exact same problem that three people had here: http://developer.constantcontact.com/node/1041 No solution was ever posted and the thread is fairly recent, so maybe this is an on-going problem?


 


Thanks for any help.

Developer Portal

View API documentation, code samples, get your API key.

Visit Page