full explanation:
I'm working on a project to generate twitter links that post over to twitter. My problem is twitter doesn't shorten the text correctly, and asks the user to fix the text. So I'm going to have javascript shorten the text to the maximum allowed without the extra being cut off by the user or twitter.
That's an unknown number because bitly will add characters as the namespace runs out. So it might be 21 today but 22 in a year. You may need to create the bitly links yourself before posting to Twitter.
This page tells you how to retrieve the current maximum length of a t.co URL generated by Twitter in real time, as part of a JSON string returned via a RESTful HTTP interface:
Twitter RESTful API Description
The relevant values shown for the sample request (YMMV) are:
"short_url_length_https": 23
"short_url_length": 22
These values will change (increase) monotonically over time, as Twitter runs out of combinations to represent the number of URLs submitted (and shortened) thus far.
According to this FAQ from Twitter:
https://dev.twitter.com/docs/tco-link-wrapper/faq
"The maximum length of t.co URLs will change over time. Issue a request daily to GET help/configuration and examine the fields short_url_length and short_url_length_https to determine the current maximum length of wrapped URLs. We do not expect these values to change often."
If your users are providing their own large links, Twitter should now shorten these correctly. At the time of your post, there might possibly have been some problem with that, but at the present time I think that this is working correctly.
However, you might want to provide more meaningful-looking shortened URLs, and Twitter supports this with something called Tweet Entities. I have not used these myself, but here is a link describing them:
Tweet Entities
Related
I have an odd problem with my twitter account. Basically I'm generating tweets automatically via a plugin with my WordPress website. That works but the tweets appear twice. I believe this isn't that the plugin is posting twice but want to be sure and just wondered if theres a way I can see technical details about the origin of a tweet?
In the JSON for each tweet there is a source field that shows the utility used to post the tweet. Example from the REST API documentation:
"source":"\u003Ca href=\"http:\/\/itunes.apple.com\/us\/app\/twitter\/id409789998?mt=12\" rel=\"nofollow\"\u003ETwitter for Mac\u003C\/a\u003E"
Also, check the timestamps for each tweet to see how far apart they're being posted. Twitter checks each tweet against the last status posted, and duplication attempts are supposed to be blocked with a 403 error at the statuses/update.json endpoint. Are your duplicated statuses exactly the same? I'd start to check for the problem by comparing each tweet's JSON and seeing if there are any differences.
I've been using the old url api(v1) to get the count of a given url, lately I needed to get also the re-tweets and started searching about that.
this is the exact url I'm using right now:
http://urls.api.twitter.com/1/urls/count.json?url=http://google.com
As I viewed with some reading the v1 api is deprecated but at least it's still working.
I found some questions on the dev page of twitter:
https://dev.twitter.com/discussions/12643
those are a little old questions and have no specific solving to the problem. I mean, the most near solution was using the search api(search/tweets) which could be good but not a exactly replacement for the urls/count method.
Please note that Twitter's search service and, by extension, the
Search API is not meant to be an exhaustive source of Tweets. Not all
Tweets will be indexed or made available via the search interface.
also it has a limit for 100 results at maximum per 'page', even it throws the link to get the next set of objects, thats good but when the search reaches 1 million of results I'll need to get page over page to now how much tweets I got and having to do to much request to the api...
I sought some question over the dev page on twitter suggested using the stream api, I've tried using (statuses/filter) but that don't work very well given a URL as track param(which they said that is the keyword to track).
So, anyone who's been using the old urls/count has found a reliable alternative with the new apiv1.1, especiffically to get the tweets and re-tweets for a given url ?
The official suggestion by Twitter staff is that either the search/tweets endpoint (having just the last 7 days data) or the Streaming API be used (handling yourself the counters, making everything just too complicated for a d*mn counter).
As an extra warning, the old endpoint (http://urls.api.twitter.com/1/urls/count.json?url=YOUR_URL) will stop working on November 20th, and according to this blog post from Twitter there are no plans to replace it with anything in the short term and they are even removing the count from their own buttons.
I'm using Twitter's python API to broadcast tweets. Sometimes it works fine. Sometimes it gives me the error "The text of your tweet is too long" for tweets that I believe should be completely legal.
This website explains that all links within a tweet should basically be counted as 20 characters: https://dev.twitter.com/docs/tco-link-wrapper/faq#How_do_I_calculate_if_a_Tweet_with_a_link_is_going_to_be_over_140_characters_or_not
But still it doesn't work for me. I have a tweet that is 132 characters. It includes the link bit.ly/YmoXqw. (That is a made-up link. But the size and form of the link is the same). And it gives me the error above. By my calculations, even if I count this link as 20 characters, it would still come out to 139 characters which is less than 140. So what's the solution here?
Rather than hard-coding the number, you can query help/configuration and use *short_url_length_https* and *short_url_length*. Twitter's Working with t.co Best Practices guidance recommends caching these values up to 24-hours. Twitter recently announced Upcoming t.co changes where the lengths were increasing. You might be seeing that and potentially running into miscalculations on power tweets due to differences in http and https lengths.
Have gone through https://dev.twitter.com/docs/streaming-apis/parameters
Per documentation it should be able to track URLs such as example.com/foobarbaz but I can't seem it to be tracking such URLs. It just doesn't return me any result when I tweet this URL and track it using Streaming API. Am I missing something?
Pretty late, but I found this by Google so this might help someone...
There are a few answers to this. The main answer being that Twitter treats URLs differently than anything else.
First, make sure you do NOT include the "www".
Twitter currently canonicalizes the domain “www.example.com” to “example.com” before the match is performed, so omit the “www” from URL track terms.
For me, sending the track parameter as "example.com/foobarz" and then tweeting "a test, please ignore: http://example.com/foobarz" worked perfectly.
You can NOT, in general, ask for substrings of URLs:
URLs are considered words for the purposes of matches which means that the entire domain and path must be included in the track query for a Tweet containing an URL to match.
But if you are willing to take every tweet from the whole domain (and a bit more edge cases), Twitter will accommodate:
Finally, to address a common use case where you may want to track all mentions of a particular domain name (i.e., regardless of subdomain or path), you should use “example com” as the track parameter for “example.com” (notice the lack of period between “example” and “com” in the track parameter).
All quotes are from the Twitter docs: https://dev.twitter.com/streaming/overview/request-parameters#track
They have more information, including examples.
Good luck!
Is there any built-in way to get the long, expanded URL from a twitter RSS feed? Right now the feed lists all the urls as http://t.co.... I'd like to do what the Twitter display does and display the long URLs; I'd also like to avoid having to do either an API call or HTTP request for each URL in the feed. Ideally, I'd also like to avoid using the Twitter API directly but if that's the only way, so be it.
Clarification
I'm not interested in doing a separate request for every single t.co link, or calling the Twitter API. I was hoping there was a single request I could make that would include the long URLs in the metadata (or even provide the tweet in full expanded form as it appears on Twitter). Turns out the way to do this is by requesting the JSON version from search.twitter.com rather than the RSS feed, and tacking on include_entities=True.
Rewrite, hopefully this makes it more clear
I'm using http://search.twitter.com/search.rss to get a feed of tweets matching a search term. The feed contains only the shortened t.co urls. Is there a way to modify my request so that the tweets contain the expanded URLs instead?
The goal is to do just one request rather than having to go through the tweets and parse each t.co url separately (especially since for a feed with several dozen t.co urls, that means several dozen separate requests). If necessary, I am willing to use the Twitter API directly to do the search instead of using RSS, but for my purposes using a feed is more ideal.
No, Twitter does not offer a urls entity in its RSS responses, nor does the include_entities option appear to work. You'll have to use a different response format e.g. JSON (with which you can use the include_entities option which includes an entities['urls'][n]['expanded_url'] object), or "unshorten" the URLs yourself after the fact.
There is a way to do this without using the Twitter API directly. You can use one of several resources,
http://expandurl.appspot.com/
API call prototype : http://expandurl.appspot.com/expand?url=
http://longurl.org
API call prototype : http://api.longurl.org/v2/expand?url=
http://unshort.me/
API call prototype: http://api.unshort.me/?r=http://
of course you can also use the Twitter API directly for this as Jordan mentioned by including &include_entities=1 or true as a parameter to some calls.
also try to CURL the URL and see what information you can gleam from that. I think this pretty much exhausts the options.