I'm currently using the php client for docusign (https://github.com/docusign/docusign-php-client) and everytime I call DocuSign\eSign\Api\EnvelopesApi::getDocument I get a message like
[INFO] Written ##### byte to /tmp/######. Please move the file to a proper folder or delete the temp file after processing.
This is apparently triggered by this line (https://github.com/docusign/docusign-php-client/blob/master/src/ObjectSerializer.php#L260)
error_log("[INFO] Written $byte_written byte to $filename. Please move the file to a proper folder or delete the temp file after processing.\n", 3, Configuration::getDefaultConfiguration()->getDebugFile());
I tried pretty much everything I could think of, using #, setting error_reporting to 0, setting the debugfile to php://stderr, to /dev/null, all to no avail.
I'm using this method in the context of a custom Symfony command if that's of any use.
The SDK is outputting that text as an informational message to the system log. I understand your desire to not see it. I have filed an issue against the SDK about this.
In the meantime, I suggest that you git fork the SDK and comment out that line.
Related
I have a vBulletin 3.8 forum.
When we click Edit button of any post (so the Quick Edit form should displayed), I get this error on the browser's console:
XML Parsing Error: xml processing instruction not at start of external entity
Location: http://www.xxxxx.xx/ajax.php?do=quickedit&p=438
Row number 2, Column 1:
... the Quick Edit form is not appearing the the progress bar displayed permanently.
I have try to disable hooks/ plugins, but the problem still appears.
I have this row on config.php: ini_set("display_errors", false); so I don't think it is a fatal error/ warning by PHP which brokes the xml normal syntax.
I have informed that this appear starts after the move of the site to another server. Does it say something to you?
Any general idea about this error?
EDIT:
Well, I found the reason of this issue, but I don't know how to fix it. Exact the same site on a localhost testing board works perfectly, but on the live server ANY html page/ ajax call etc, has a useless empty line as line #1.
For normal html pages, there is no reason for the browser to return an error, but when we're talking about an ajax call, this empty line at the top of the response, breaks the xml parsing from the browser. So it seems it is a server/ PHP/ Apache setting that applies this empty line. Any idea how to fix it? https://imgur.com/a/4neb0
It might be late for you but any new comers with php/nginx/apache can get an understanding of why.
Answer is simple: When moving the code, you might not be using git/rsync/scp but let me guess, you used zip (and probably Windows/Linux involved).
How to discover it was a two-day journey with many things tried:
We have the same error, we were also moving our servers. We tried:
We thought the server software version was a problem.
We thought the cloud provider OS image was a problem.
We used docker to avoid these problems, but the empty line problem persists.
We thought the code ?> ending was a problem, I went through all of them. But it wasn't.
I finally asked my colleague: How did you get the code? From Git? He said he downloaded from ZIP and then uploaded to server.
I removed code on the server (which extracted from a zip) and used git to download a fresh copy from our github.
Magic, problem solved. The empty line gone.
So I think the problem is with the zipping progress might have changed some file empty lines. Always use git.
I am starting to use xdebug in combination with qcachegrind and first tests work well. The log file gets recorded and I can open it with qcachegrind. But now I have the issue that I dot't get detailed information for every function. For php::exec_curl I only get the information
"There is no source
available for the following function: php::curl_exec. This is because
its source file cannot be found: php:internal. Add the folder of this
file to the source folder list. This list can be found in the
configuration dialog.
I am using MAMP (/Applications/MAMP/bin/php/php5.6.2/bin/php) on OSX. My first try was to add simply the whole MAMP folder to the source list, but that did not work.
Now I wanted to ask if anybody maybe already had the same challenge and knows how to solve it?
exec_curl is an internal PHP function, meaning that it's been implemented in C and QCacheGrind doesn't have access to it's source nor to any trace of what that function did. For XDebug/PHP/QCacheGrind this function is just a black box, that takes some parameters and returns some input.
Why would you need to see the source? Frankly, you shouldn't care about what happens inside. All internal functions have been tested and proven to work.
I have this code on my route.php
Route::get('/download', function()
{
return Response::download('file.xml');
});
On my local computer it downloads the xml file with options to save or view. Which is what i want, But after uploading to my server it shows the content of the xml file on the browser. Please how can I fix this? is there a configuration on the control panel that accounts for this?
I am using blue host. And if its a PDF file shows 'Unable to stream pdf: headers already sent' but everything works well on my local system.Also will not work with csv
Please how can I fix this?
Still will not work with csv file with headers
array('Content-Type'=>'text/csv','Content-Disposition'=>'attachment; filename="filename.csv"')
Here's a guess based on the error Unable to stream pdf: headers already sent message mentioned.
Your host might have different PHP error reporting settings than your local dev environment.
You potentially could be getting a NOTICE or similar error level being output before the XML file on your hosting (Perhaps due to a permissions issue where PHP can't read the file).
Check your error logs on your production server (app/storage/logs) to see what you can see there.
The problem was white space on the file. I simply removed the the space at the start of the file
I have uploaded my PHP project created using Eclipse-PDT to the siteground server.
After completing the upload, i tried to run the php pages and it throws an error saying "Expected End of statement".
Then i logged in to the CPANEL and found that all the line breaks are removed from the script. since i have used "single line comments" in my php script ,its throwing error(next line will also append to the previous line)
can anybody help to solve this issue? i have a lot of php pages ,so its not possible to remove all single line comments from all the pages.
Maybe its caused by different file encoding?
Check which format is used in your editor.
I am using the official Microsoft example and this example as the basis for my code to upload a file from Silverlight to a PHP script.
I am calling **HttpWebRequest.BeginGetRequestStream()**, writing the file over a file stream, and then calling **HttpWebRequest.BeginGetResponse()** to get the response. When I call HttpWebResponse.EndGetResponse() I get the following exception every single time:
{System.Security.SecurityException ---> System.Security.SecurityException: Security error.
at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.Browser.BrowserHttpWebRequest.<>c__DisplayClass5.<EndGetResponse>b__4(Object sendState)
at System.Net.Browser.AsyncHelper.<>c__DisplayClass2.<BeginOnUI>b__0(Object sendState)
--- End of inner exception stack trace ---
at System.Net.Browser.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.Browser.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at FileUpload.FileUploadProcess.GetReponseCallback(IAsyncResult AsyncResult)}
I have both clientaccesspolicy.xml and crossdomain.xml files in the base directory that allow access. I ran Fiddler and have seen it download the clientaccesspolicy.xml file so it is hitting it correctly.
The PHP file is running on Apache2 and just does a fread on php://input to read the data as the examples show. It is not receiving any data which leads me to believe that the SecurityException is forcing it to abort the write.
Has anybody seen this issue before and can point me in the right direction of a solution?
Have you checked to make sure the webserver/php application has write access to the directory you plan on storing the uploaded file to?
This could be causing it to abort prematurely.