bigcommerce-api-php
bigcommerce-api-php copied to clipboard
Use of undefined constant STDIN
I am receiving an error when making a PUT request. The error says:
Use of undefined constant STDIN - assumed 'STDIN'
It occurs in Bigcommerce/Api/Connection.php
on line 369
. I recently updated my application to use the most recent branch of this Bigcommerce API, and am now receiving this error.
I noticed in the past version I was using, this STDIN line did not exist, and the error did not occur. Do you know why this line is necessary and why it would be causing this error? I realize I can just define STDIN manually in my app, but it seems like that shouldn't be necessary.
hmm, can you provide the call you are making so we can reproduce on our end?
I'm calling $brand = Bigcommerce::updateBrand(48, ['name'=>'Del Sol']);
.
My app is using Laravel 4.2. If I place this line before the one above, it works correctly:
define('STDIN',fopen("php://stdin","r"));
This is all taking place via a browser call. Meaning, I have a route that calls this code. So I navigate to http://example.com/test
, and the code runs. If I run the same code using the artisan command line tool, I do not get the error.
It seems like STDIN is not defined when the app is executed via a browser. Not sure if this is a Laravel issue or a Bigcommerce SDK issue, but I am confused as to why the SDK relies on this STDIN constant that may or may not be defined.
STDIN is not available through the browser, only from CLI.
Place this in the __construct()
method:
define('STDIN',fopen("php://stdin","r"));
Thanks for getting back to me. That doesn't really work for me because there are times I create multiple connections, which causes the constant to redefine itself. I will just define the constant in my app for now, but shouldn't the SDK ultimately not rely on that constant so that it can be used in any environment? This worked fine in previous versions.
What about just replacing STDIN with fopen("php://stdin","r")
? So the line would just read:
curl_setopt($this->curl, CURLOPT_INFILE, fopen("php://stdin","r"));
Is there any reason the not to change the line to that instead?
Have same issue with Bigcommerce::updateOrder()
@yingliangzhang
Place define('STDIN',fopen('php://stdin', 'r'));
in the __construct()
method of
Bigcommerce/Api/Connection.php
@mullinsr you should not have to edit the API source-code files for it to work... probably why they don't want to do that...
@Lewis: Thanks for your opinion. If you have a better suggestion, please feel free to post it.
@mullinsr Yes my suggestion is that you remove the line in Bigcommerce/Api/Connection.php
as it seems unnecessary to use that CURL option.
Alternatively you could add a method in the API that defines STDIN, or add it to the location you specified for the entire API as 'php://stdin'.
In any case I am not recommending a single user changes, this in their copy of the API, but that the API repo is updated either internally, or via PR.
Simple really, I hope that helps clarify
Defining STDIN in the Connection construct once will work across the entire library, and will satisfy the fact that there were native BC functions that explicitly used STDIN in some way.
The user was calling these functions from a browser, and STDIN is not available from that environment. Whether or not the library 'depends' on STDIN is unclear. It is very possible that it may not be needed. But ultimately because it is written in the curl functions by bc, and because warnings were being raised, it just made the most sense to me to ensure that STDIN is defined from the start.
But yes, you are right and good advice, most users should avoid modifying these files themselves.
Sent from my iPhone
On Oct 19, 2015, at 5:23 AM, Lewis Cowles [email protected] wrote:
@mullinsr Yes my suggestion is that you remove the line in Bigcommerce/Api/Connection.php as it seems unnecessary to use that CURL option.
Alternatively you could add a method in the API that defines STDIN, or add it to the location you specified for the entire API as 'php://stdin'.
In any case I am not recommending a single user changes, this in their copy of the API, but that the API repo is updated either internally, or via PR.
Simple really, I hope that helps clarify
— Reply to this email directly or view it on GitHub.
Problem located https://github.com/bigcommerce/bigcommerce-api-php/blob/master/src/Bigcommerce/Api/Connection.php#L445, so it is core API :wink: