I just noticed that my application can not remove a like on a media object. My code for liking / unliking is identical except I add the parameter _method=DELETE to the unlike case (both use POST). The documentation states that this is supported, and it's pretty common for RESTful API given the lack of support in most browsers for DELETE. I've tried in from the Apigee console too, and the same problem seems to exist, however DELETE does seen to work. I'd attach screenshot from the Apigee console, but apparently I need more points or something.
Yes, this is really supported, but it has been broken since February 3rd. It has now been fixed!
Related
That's a quite puzzling problem. I've multiple MediaWiki installations. In this specific case: Version 1.34.
Now I can login to all of these MediaWikis. Everything works fine.
Now I can access all of these MediaWikis via API --- EXCEPT ONE. The strange thing is: All of them are configured almost identical. I even copied the configuration from one wiki where everything was working to the second wiki.
To be more precise. If I send ...
/wikiA/api.php?action=query&meta=tokens&format=json&type=login
... I get a very reasonable answer, e.g.:
{"batchcomplete":"","query":{"tokens":{"logintoken":"37ec2e690eeb48a10ac66b2ccbca2b576000f9f4+\\"}}}
If I send ...
/wikiB/api.php?action=query&meta=tokens&format=json&type=login
... I get the following answer, e.g.:
{"error":{"code":"readapidenied","info":"You need read permission to use this module.","*":"See http://xxx.xxx.xxx.xxx/wikiB/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes."}}
This can be reproduced using any web browser.
Q: What could be the reason that on this wikiB I even can't access the normal login module? It can't be the configuration. It's almost completely identical. It can't be the source code. I ran a diff on the PHP files and found no significant differences. What could be wrong here? It seems it must be something with the database. But how do I approach this? Does anyone have an idea? I would appreciate it very much if you could help!
I analyzed the data base: No difference. I did more research using google: And found a bug report.
It's a bug in MediaWiki. They provided an official software release with THAT kind of bug.
It turnes out there is a 1.34.0 version and a 1.34.1 version. My WikiA has 1.34.1 while WikiB had 1.34.0. After copying this one single file includes/api/ApiQuery.php from WikiA to WikiB and everything worked fine.
https://gerrit.wikimedia.org/r/c/mediawiki/core/+/580097/
Paging in rest API is not working
/maxrest/rest/mbo/ticket?_maxitems=20&_rsstart=31
Modifying value of rsstart is giving same result
Not sure if you're still having this issue but I'll post an answer anyway for people looking in the future.
The naming of the parameters is "supposed to be" case sensitive. That being said I've run into Maximo instances where it seems to not matter, and other instances where it will only work with proper syntax.
I presume that you are building your own paging logic since I don't believe it is not natively supported by the REST API.
The url you should be using is:
/maxrest/rest/mbo/ticket?_maxItems=20&_rsStart=31
I got problem with my company internal extension. They don't want to publish it, as it does gather data on external server. So I need to host it myself... but would like not to lose ability of autoupdate.
As far as I read I need to use update_url in manifest, but nothing more is said in Opera documentation...
"update_url": "http://path/to/updateInfo.xml", - as it is said in documentation page
Ok... and what should I put in that xml? Will it autoupdate or just notify users about new updates? Where do I put rest of updated files?
I tried to concat Opera itself about this question, but they don't give any contact information except something like if you have problem, ask on stackoverflow... so here I am.
If it does not work, I was thinking about really BAD method, using unsafe-eval and keeping newest version in local storage... but would rather like to avoid that.
In general the behavior is the same as for Chrome. You can base on this document: https://developer.chrome.com/extensions/autoupdate
Graph API is not returning image("picture" attribute) for objects corresponding to community pages, which used to be returned earlier. For example this https://graph.facebook.com/178790412179919 does not have picture attribute whereas the corresponding page has an image.
Also the FQL query done on the "albums" connection for some objects does not have a "cover_pid" attribute for an album corresponding to type "profile", which again used to work earlier.
Does anybody know if anything has changed in Graph API corresponding to this in last couple of weeks (I am fairly confident it used to work earlier in the expected way). I looked through Facebook API release notes but could not find any changes corresponding to this. Please let me know if this not appropriate post for this forum.
https://developers.facebook.com/docs/reference/api/page/
picture is a connection, not an attribute. So ...
https://graph.facebook.com/178790412179919/picture
And as the docs say: Returns a HTTP 302 with the URL of the user's profile picture.
Kinda goofy? Yes, but it works exactly as the docs say it does. I suspect they implemented it this way so it could easily be used in an <IMG> tag.
UPDATE:
It still works via FQL. In your case:
https://api.facebook.com/method/fql.query?query=SELECT+page_id%2C+pic+FROM+page+WHERE+page_id+%3D+178790412179919&format=json
I can confirm that this PREVIOUSLY worked, but NO LONGER works. Facebook have removed the picture connection from Community Pages.
I suspect the reason is that most of these images are pulled from Wikipedia, and there was a licensing / attribution issue.
Unfortunately, Facebook is no longer a reliable source of images for entities (e.g. bands).
I would like to be able to generate custom bit.lys (http://bit.ly/thecakeisalie type things) through their API. This does not appear to be possible, but I thought I'd check; does anyone happen to know otherwise?
This unfortunately had to be removed for our free users due to on-going abuse. All of the custom bitlinks on bit.ly are created in the same key space, so allowing for automated creation there quickly leads to there being no sane options availble for anybody else.
That being said, we have recently added the ability for our paid customers to create custom bitlinks if they are using a custom domain. In this case, our customers get their own key space so creating custom bitlinks en-mass isn't a problem.
It was removed from the API. I like many others were trying to do this and bit.ly's support email replied saying it has been removed. Similar experiences on their ApiDocumentation wiki here.