2

I'm trying to start out with the WooCommerce REST API client library but keep getting this error:

Invalid URL, no WC API found at http://[my-store].com/wc-api/v2/ -- ensure your store URL is correct and pretty permalinks are enabled.

Pretty permalinks are enabled and set to post name, according to this thread. Manually accessing the URL via browser gives the JSON output of some WooCommerce settings, that's why I assume that the store URL is correct. (It's same like the domain, I'm working on.) I also tried to insert new consumer and secret keys but that doesn't help.

A bit of research in the code brought me to the class-wc-api-client.php.

$index = @file_get_contents( $this->api_url );

// check for HTTP 404 response (file_get_contents() returns false when encountering 404)
// this usually means:
// 1) the store URL is not correct (missing sub-directory path, etc)
// 2) pretty permalinks are disabled
if ( false === $index ) {
    throw new WC_API_Client_Exception( sprintf( 'Invalid URL, no WC API found at %s -- ensure your store URL is correct and pretty permalinks are enabled.', $this->api_url ), 404 );

$index indeed equals false, which means that file_get_contents got a 404 response. Creating a /wc-api/v2/ directory within the store's directory didn't help.

I can't find out why file_get_contents gets a 404 response while browsing the page will display a non-empty JSON string. I feel like I'm missing something basic.

Any help is appreciated!

Edit: Found the solution! I encountered this problem again today and did some research on the file_get_contents() returning FALSE on JSON. This thread put me on the right track. Setting allow_url_fopen = On in the PHP.ini solves the case. Might be useful to know if someone else runs into this problem.

Community
  • 1
  • 1
CLN
  • 65
  • 2
  • 7
  • This will sound strange but suddenly it works. I don't know why -- I reverted every change I made for solving this problem. So the system status is exactly the same like when I made the original post. I talked to my hoster and they, too, said they didn't make any changes. I guess this question is resolved. I'll do an edit, when I finally find out something useful about this. – CLN Jul 13 '15 at 09:41

1 Answers1

0

I had a similar issue. My problem was caused by one of the settings in iTheme Security. Under banned users -> Enable HackRepair.com's blacklist feature. If you have the list enabled, then itheme keeps a ist of the allowed user agents in the .htaccess. When you are using php's file_get_contents, there is no user agent, so the script ends up being blocked.

If anyone else is having problems with this, I suggest looking through your .htaccess to see if there is anything suspicious.

Ewart
  • 3
  • 3