like in the title, is it possible to create an article using current Linkedin API?
I am not interested in sharing an article but posting a new one. I found some questions regarding that from last year and based on answers it wasn’t possible back then. Is it still a case? I couldn’t find this in Linkedin documentation.
Also additional question, did the limit for the amount of characters inside a post (it is possible to create a post via API) change recently? Currently it is set to 1300 characters but I am pretty sure that a few weeks ago we were able to create a longer post.
Related
I am developing a project that is using the WP REST API. After some tests, I realized that it's not retrieving all the categories based on what I am trying to GET. In precise, there are supposed to be 21 results but only 10 come up. Is there some kind of restriction that I am not seeing? Any settings that I'll have to change.
Here is what I am trying:
https://example.com/wp-json/wp/v2/categories?parent=97
I saw this post here, but some of the answers relied on using the WordPress JSON API, which is a plugin that is no longer available due to security concerns.
TIA
I had to look at the documentation more closely. In terse, The default result shows a count of 10. Specifying the per page would change that. So:
https://example.com/wp-json/wp/v2/categories?parent=97&per_page=X
(Change X to the respective number)
Easily seen in the JSON result from this:
https://www.linkedin.com/countserv/count/share?url=https://www.linkedin.com
Which currently returns:
IN.Tags.Share.handleCount(
{
"count":0,
"fCnt":"0",
"fCntPlusOne":"1",
"url":"https:\/\/www.linkedin.com"
});
Apparently it affects most of the LinkedIn Share buttons/counters out there on the web, including WordPress and other blogs. This has been "broken" since late last week (13 Jan 2018).
I opened a ticket with LinkedIn support. Response was to post here, as this is where the LinkedIn Developers support resides. Hoping for a response that says "Oops, we'll fix this." Or, if deliberately crippled, an announcement that says so. (Twitter made a similar move a few years ago. It was unpopular among developers, but we've moved on.)
Further to Chris Hemedingers response, this feature has now been entirely deprecated
Deprecating the inShare Counter
As you can see they have deprecated this saying:
The share count on its own doesn’t fully reflect the impact that a piece of content delivers, and we encourage publishers and other content creators to leverage the inShare plugin as a way to drive conversation and engage with members on LinkedIn.
They then link to the Documentation saying:
Share on LinkedIn plugin will no longer return share count.
This is massively inconvenient for my company as we have just finished construction of a suite of tools powered by this.
The share count service is back in operation, working as it was before. The outage was deliberate (apparently) but temporary.
As far as I know this is an undocumented API, but it's integral to the "LinkedIn Share" buttons that are used in countless websites/blogs around the world. As such, LinkedIn has no contract/obligation to keep that service running...so consumers of the service in non-LinkedIn components should beware.
Thank you for the update! That was quite frustrating to track this down. I had to research the code, request from the API itself with multiple URLs, submitted a ticket to LinkedIn... and ultimately found myself here and read this. Just a recommendation, I think it would be better to return some kind of error code than a 0. Many people actually display the count on their sites.
I want to publish my questions and their responses asked here (on Stack Overflow) to my blog (or Linkedin, etc.) automatically.
I host my blog on blogger.com.
Is that possible?
I can give you at least half an answer. If you can get the information from Stackoverflow, then you can easily write a program to write posts using the Blogger API. The structure of your program would need to be something like
Get info from Stackoverflow.
Authenticate with Blogger using one of the authentication methods.
Create the HTML for the post body based on the Stackoverflow info.
Combine that with meta data tags to create the post entry (atom format).
Create a new post using the string you created in the last step.
If you run into problems with any of those steps, other than the first one, I'm sure I could help you further. Just ask here on Stackoverflow and tag it with 'blogger' and I'll try to answer.
I am working on a little mobile app for facebook and have been studying the Facebook Api's for weeks now.
My problem I need help with is comments, I have my app retrieving them via post_id/comments?access_token=**&limit=10 but the problem with this way is that the comments are being sent oldest first, so if i wanted to get the newest comments and there were 200 comments i'd have to call the api because of pagination 19 times to get the most recent. Is there any way of telling the graph api to send the newest comments first? I really want to avoid having to get all the comments at once just to sort them myself - sometimes there are over 2000 comments.
I did a little experimenting with fql last night and found I was able to specify ORDER BY time in the query and also LIMIT and less than time to do my own kind of pagination. The problem with this way is that the person name (who had made the comment) isn't returned, only an id for that person. Please correct me if im wrong but that would then mean having to make a call to the api to find out the name of the commenter for each comment made on a post - again sometimes over 2000. I think this is not a solution for mobile.
I just want my app to show comments newest first. Please can any one of any advice?
Regards
http://developers.facebook.com/docs/reference/rest/fql.multiquery/
I am working on a project that requires reliable access to historic feed entries which are not necessarily available in the current feed of the website. I have found several ways to access such data, but none of them give me all the characteristics I need.
Look at this as a brainstorm. I will tell you how much I have found and you can contribute if you have any other ideas.
Google AJAX Feed API - will limit you to 250 items
Unofficial Google Reader API - Perfect but unofficial and therefore unreliable (and perhaps quasi-illegal?). Also, the authentication seems to be tricky.
Spinn3r - Costs a lot of money
Spidering the internet archive at the site of the feed - Lots of complexity, spotty coverage, only useful as a last resort
Yahoo! Feed API or Yahoo! Search BOSS - The first looks more like an aggregator, meaning I'd need a different registration for each feed and the second should give more access to Yahoo's data but I can find no mention of feeds.
(thanks to Lou Franco) Bloglines Sync API - Besides the problem of needing an account and being designed more as an aggregator, it does not have a way to add feeds to the account. So no retrieval of arbitrary feeds. You need to manually add them through the reader first.
Other search engines/blog search/whatever?
This is a really irritating problem as we are talking about semantic information that was once out there, is still (usually) valid, yet is difficult to access reliably, freely and without limits. Anybody know any alternative sources for feed entry goodness?
Bloglines has an API to sync accounts
http://www.bloglines.com/services/api/sync
You have to make an account, subscribe to the feed you want to download, but then then you can download based on Date, which can be way in the past. Not sure of the terms.
The best answer I've found so far, is this: Google reader's unofficial API turns out to have a public access point for their feeds, which means there is no authentication needed. Use is as follows:
http://www.google.com/reader/public/atom/feed/{your feed uri here}?n=1000
replace the text in the squigglies (including the squigglies themselves) with the feed URI you're interested in. More information about the precise arguments can be found here:
http://blog.martindoms.com/2009/10/16/using-the-google-reader-api-part-2/
but remember to use the /public/ url if you don't want to mess with authentication