Out ERP integration partner has run in to a nasty issue.
When trying to do a simple API request ex. https://domain.com/api/combinations/2
The webservice / api fails and respond in a wird way
<?xml version=“1.0” encoding=“UTF-8”?> <thirtybees xmlns:xlink=“http://www.w3.org/1999/xlink”> <errors> <error> <code> <![CDATA]> </code> <message> <![CDATA[Wrong argument ($type) in Shop::getSharedShops() method]]> </message> </error> </errors> </thirtybees>
i am able to replicate this on a 100% clean TB install, trying to verify if the issue persist in the upcomming 1.0.4 ( it persists in 1.0.4 )
Created a github issue for this to https://github.com/thirtybees/thirtybees/issues/434
Hope we can get it sortet out, since it’s one of the last pussle bricks before we are able to go in to the air with the new shop we build in TB
The webservice also fails on my shops with my carrier(sendcloud) This is the reason i cant move with my mainwebshop, i use more webservices: Sendcloud, Channable, and i am afraid also the beslist, bol.com api will not work.
I hope this will be solved. NB The webservices work fine on Prestashop 184.108.40.206
Baarssen - can you please share what API calls fail for you? then we get more information, and i think thats the key to fix the issue.
And what reply is returned for that API call, to figure out if there is a pattern.
I found 2 places that might cause this issue.
I never experienced ws before so I am not sure.
But it seems that classes/Combination.php should be modified on 2 lines:
->join(Shop::addSqlRestriction('attribute', 'a'))should be
->join(Shop::addSqlRestriction('product_attribute', 'a'))should be
Can you please test and let me know if its ok.
im actually digging thrue thos parts right now to and i think it’s about the same i have found so fare that might be the issue hehe, ill test it out in a bit just going thrue last parts to be sure i have not missed any thing.
Damn, you guys are fast! Awesome, thanks!
Yep confirmed that is the issue, i get the response that i should now.
It’s quite funny 10 min before your post i just send a note to Michael about i thought the issue could be in getWsProductOptionValues and then you posted after that, and yep true enough it was the issue, going to check out TB git and PS git to see if the mistake is made other places.
For me this doesnt solve it, on the sendclouds side it gives a 500 error which doesnt tell us anything.
I tried to manual execute some api calls which sendcloud is using and that gives some result what seems ok to me, however no parcels are imported into my sendcloud backoffice.
For now i just keep it on PS 220.127.116.11 because that works fine since i started with sendcloud last year may or june.
Baarseen i am wondering if there system generates the 500 error insted of your server, since they might check for <prestashop xmlns:xlink=“http://www.w3.org/1999/xlink”> and not <thirtybees xmlns:xlink=“http://www.w3.org/1999/xlink”>
But what you need is to ask them to tell you what api call they do when it replys with a 500 error, with out that information it’s impossible to look in to.
I’ll ask them
Would be great to have that feedback. I am not too familiar with Sendcloud. Do you know if they provide test accounts? Or just create shipments without getting charged if not actually sent, like with MyParcel?
It seems it only accepts prestashop. He will make a pull request about it
Im glad that we figured it out!
Bith fixes, the initial issue and the issue with Sendcloud is added to the TB Git repo.
Make sure to add both changes if you got issues with webservices.