I'm using the 'catalogProductAttributeMediaCreate' V2 SOAP service call to create images for products. This worked fine for months but has been failing since a couple of days.
The API call itself returns a successful action. No exception is thrown by Magento and the call returns an image id in the form of a string like '/f/e/ferrari-f12-berlinetta-wallpapers-pictures-backgrounds.jpg_4.jpg'.
But when I check the magento admin backend, no images are shown. When I check the table in mysql I notice that magento hasn't created a record for it. Even though the API call returns a success.
Adding images through the admin backend manually works fine. I've re-installed the entire magento site. But the fauls persists.
When I use the API to remove the image it returns an exception, telling me that the image '/f/e/ferrari-f12-berlinetta-wallpapers-pictures-backgrounds.jpg_4.jpg' does not exist. Which makes sense as it's not present in the database.
So, why does the API returns a successful action and an image ID, when it obviously fails. And where do I start to troubleshoot?
Related
My company uses a systemd service that makes rest api calls to the podio API in a python wrapper on a services server. The process takes in bugsnag bugs, checks that a podio bug item with that external ID already exists, and then creates a new podio bug if no associated podio bug exists and updates any existing item if one does exist. Recently, this check was behaving unpredicatably. It would encounter a request for a given bugsnag ID and for no discernable reason would fail to find a podio bug with a matching external ID on one call, and then successfully find one the next call. The specific API rest call is https://developers.podio.com/doc/items/filter-items-4496747, filtering by external ID.
We haven't been able to recreate the issue on local testing, and reverting the code running on our services server to before a major refactor (the issue started happening around the same time) didn't stop the issue from happening. Was there a change in how the filter request works recently? Even so, that wouldn't explain why we are getting different responses for the same call.
don't know if I'm handing you a Red Herring but, I had to rewrite my Podio.Net code because all the references to integer Podio ItemIds were acting erratically like you described. The issue was that Podio's Id numbering system exceeded the size of an Integer and I had to switch all the calls to Long ItemId values.
I created a django app that uses adsense data and this week it stopped returning the data. In Api explorer, the parameters are validating, but when it goes to the application, nothing is executed.
I basically use the same structure as the example https://github.com/googleads/googleads-adsense-examples/blob/master/v2/python/generate_report.py.
Accounts are listed, but this line result = service.accounts().reports().generateCsv() just stopped working.
if you know how to indicate another way than to test this api or how to debug, can you share it here please?
My app uses LinkedIn authentication along with a couple of other social network logins.
Even though authentication is working fine, all of a sudden LinkedIn stopped returning the formatted profile picture i.e. picture-url. I do however continue to receive the original image i.e. picture-urls -- see below:
In my authentication request, I request r_basicprofile and r_emailaddress and according to this link, I should be receiving both the formatted and the original image.
https://developer.linkedin.com/docs/fields/basic-profile
Up until 10 days ago or so, I was receiving both images. I didn't make any changes to my code but for some reason, the formatted image doesn't show up anymore. Any idea why and how to fix this?
UPDATE:
All of a sudden I started getting both images again -- without making any changes to my code.
I also noticed that the image URL has now changed and I'm seeing all types of parameters in there -- such as image size, something that looks like API version type (alpha in the example below) and possibly a time stamp indicator:
https://media.licdn.com/dms/image/{image-id}/profile-displayphoto-shrink_100_100/0?e=123456789&v=alpha&t={sometypeofid}
I don't remeber seeing any of these parameters in the image URL which is not a URL at all but what seems to be an API call that returns an image.
I don't know if LinkedIn announced such changes that I missed or just decided to make these changes without keeping developers in the loop. I hope it's not the latter and I simply missed the announcement.
I have a problem with cart update by API.
I use Varnish with Phoenix.
Update cart from website frontend is working fine, but if I try to update cart from API with this code, I get an old cached version of data.
Example: If in XYZ customer's cart I have 3 products and he's adding another from web in Android app mobile which uses the API, then the cart is not updated.
The code that I use for fetching cart details is as below:
$quote = Mage::getModel('sales/quote')->loadByCustomer($customerId);
$cartItems = $quote->getAllVisibleItems();
I think that this problem comes from the use of cookie, but I don't have an idea about how to do it. Obviously, if I disable varnish or if I refresh the cache everything works fine.
I am working on Magento 1.9.0.1, Varnish 3.0.7 and Phoenix 4.2.3
Thanks!
In varnish you will have to clear the cache programmatically for your changes to appear on frontend. You can get the code to clear the cache from the controller action which is called when u clear the cache from backend.
Simply call this action after your API functionality is done and it will work as expected. You can also, Check if varnish clears cache based on any event that is fired. You can trigger this event after your functionality is done.
Also, I think u will have to do it only for the first item that user adds in cart. varnish cache system stops caching based on 5 dis-qualifiers - if user is logged in, if item is in wishlist, if item is added to cart, and 2 more. You can find these dis-qualifiers in its model or helper file. So when first item gets added to cart it should stop caching automatically for rest of the items.
Hope this helps!!
Using the Contact API v3 I had a working implementation for uploading a photo to an existing contact.
Since a couple of weeks this fails with 404. The implementation has not been changed when the API servers started to sent back 404s and I don't see any indication what exactly changed and would result now in the 404s.
I'm using HTTP PUT + the photo URL of the contact.
One interesting observation I made was that the contact's self-URL changes which each request (the provided details are still always the same and correct).
Did anyone notice something similar ?
Edit: Link to issue: http://code.google.com/a/google.com/p/apps-api-issues/issues/detail?id=3301&q=contact&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Opened%20Summary
tried different photo formats and sizes, different content types and even photos which had been uploaded previously (when it was still working). Nothing changed the behaviour of returning 404.
w.r.t to change contact ids: the contact ID changes between API invocations. I first thought it could be related to reopened connection( no keep-alive) that contact ids change. However what speaks against this being the cause of the issue is that first retrieving a contact and then editing a contact's address is possible without any issues.
authentication does not seem to be problem as well - otherwise editing a contact's address would not work as well.
PS: I'm using the JSON output format when retrieving the contact.
PS2: s/GET/PUT in step 3 ( I tried to change PUT to GET to see if it still returns 404... which it does).
PS3: am not using any client library but implement the protocol directly (which should not be relevant for the HTTP PUT on the photo link
After hours of investigation I found out that this is particular an issue using OAuth1. Using OAuth2 the exact same photo links which had been returned when requesting a specific contact record using OAuth1 work and return the photo data on HTTP GET. I expect HTTP PUT for photo links using OAuth2 to succeed as well.
Remains open if if there's some kind of workaround for OAuth1.