Is this the Like/Unlike expected behavior?
297 views
Skip to first unread message
Camila V.
Jun 26, 2012, 8:13:16 PM6/26/12
to tumbl...@googlegroups.com
I've decided to have some fun and grabbed the like/unlike methods from API v2 to put one like/unlike button on every post, outside the permalink page. I've succeded on getting this button working, but...
I may be really blind, but I've found no quick method on the docs to verify if the user seeing the page already liked one post. This custom button should be a like/unlike toggle as the original button from the permalink's iframe, so, you can imagine that if the user refresh the page it's going back to the default state without the "already liked" check - a "like" button in my case.
Please, consider the following situations:
Situation 01: The user likes the same post multiple times, without unliking it between the actions.
Result: The post is going to appear on his "like feed" once, but his "total likes" counter is going to rise to the skies.
Aware of this weird behavior I've added an "always unlike" button to check if I could revert it.
Situation 02: The user unlikes the same post multiple times, without liking it bewteen the actions.
Result: The post disappears from the feed, but only one like is removed from the total counter. The ghost likes remains for what seems, forever. He can like & unlike the post again and even empty his likes' feed, unliking everything (see attachment).
I may be really blind, but I've found no quick method on the docs to verify if the user seeing the page already liked one post. This custom button should be a like/unlike toggle as the original button from the permalink's iframe, so, you can imagine that if the user refresh the page it's going back to the default state without the "already liked" check - a "like" button in my case.
Please, consider the following situations:
Situation 01: The user likes the same post multiple times, without unliking it between the actions.
Result: The post is going to appear on his "like feed" once, but his "total likes" counter is going to rise to the skies.
Aware of this weird behavior I've added an "always unlike" button to check if I could revert it.
Situation 02: The user unlikes the same post multiple times, without liking it bewteen the actions.
Result: The post disappears from the feed, but only one like is removed from the total counter. The ghost likes remains for what seems, forever. He can like & unlike the post again and even empty his likes' feed, unliking everything (see attachment).
I've tried other patterns, but unless a liked post is unliked before being liked again it's going to generate a ghost like on the user statistics, and once it's added to the counter it can't be subtracted. Is this the expected behavior?
Is there a light and quick way to check if a post was already liked by the user (keep in mind that I'm not building an app, just using some methods)? Are you planning to include a checking method the API, or at least, modify the "like" method to not allow duplicates?
Oh, by the way I'm not really sure because my tumblr is being really lazy when it comes to update it's notes counter, but I think this like bug is messing with the notes also. I've been using {noteCountWithLabel} variable, which returns as " notes" when there is a ghost like, it's not even "0 notes" as it should or "X notes" where X is the value before the duplicated like. It's like if it's returning an empty or undefined value.
I've managed to force a bugged notes counter to display the right values again, but I'm not sure of how, I was unable to understand the action/reaction pattern.
P.S.: I'm a hobbist without formal training, guided only by by observational skills and logical thinking. And English isn't my mother tongue (sorry, my writing skills are awful!). If in doubt, talk with me like if I was a retard, hah.
Is there a light and quick way to check if a post was already liked by the user (keep in mind that I'm not building an app, just using some methods)? Are you planning to include a checking method the API, or at least, modify the "like" method to not allow duplicates?
Oh, by the way I'm not really sure because my tumblr is being really lazy when it comes to update it's notes counter, but I think this like bug is messing with the notes also. I've been using {noteCountWithLabel} variable, which returns as " notes" when there is a ghost like, it's not even "0 notes" as it should or "X notes" where X is the value before the duplicated like. It's like if it's returning an empty or undefined value.
I've managed to force a bugged notes counter to display the right values again, but I'm not sure of how, I was unable to understand the action/reaction pattern.
P.S.: I'm a hobbist without formal training, guided only by by observational skills and logical thinking. And English isn't my mother tongue (sorry, my writing skills are awful!). If in doubt, talk with me like if I was a retard, hah.
Weebs
Jun 27, 2012, 8:45:59 AM6/27/12
to tumbl...@googlegroups.com
There's no way to check. One thing you could do is maintain a log somewhere of all the post ids the user liked.
Camila V.
Jun 27, 2012, 11:56:58 AM6/27/12
to tumbl...@googlegroups.com
Yeah, I've already thought about that, but I would like to avoid this if possible. Not only it would go too far (remember, it's not an app I'm building, I've been using no external pages/programs so far) but the check wouldn't be so simple. Am I right to assume that to retrieve the visitor ID (actually, there isn't even an available "unique ID" param yet, is it?) - the name in this case - I would need his OAuth?
Isn't it a bit crazy to require such thing just to, in the end, be able to place a simple button without provoking bugs to the viewer? Specially when I'm not interested in the visitior informations but knowing who he is.
To avoid the info request I could instead create a cookie using javascript, but it's really far from reliable.
What really bothers me isn't even to be unable to realize this check (it's more a cosmetic thing), but the fact that I'm able to bug the user's dashboard using the like method.
I guess that the best solution to this bug doesn't depends upon me at the moment. With a server-side check of "already" liked before adding +1 to the user counter the bug would be gone.
Isn't it a bit crazy to require such thing just to, in the end, be able to place a simple button without provoking bugs to the viewer? Specially when I'm not interested in the visitior informations but knowing who he is.
To avoid the info request I could instead create a cookie using javascript, but it's really far from reliable.
What really bothers me isn't even to be unable to realize this check (it's more a cosmetic thing), but the fact that I'm able to bug the user's dashboard using the like method.
I guess that the best solution to this bug doesn't depends upon me at the moment. With a server-side check of "already" liked before adding +1 to the user counter the bug would be gone.
Later, of course, a method to check if the user already liked the XXXXXXXX post in question would be welcomed, extending the current like/unliked methods' functionality.
John Bunting
Jun 27, 2012, 12:23:03 PM6/27/12
to tumbl...@googlegroups.com
There is a new field on Post objects that I implemented called "liked". This field indicates whether the currently fully oauthed user liked the post or not. You must be fully oauthed though or this will not work or the field will not even appear.
I know this is one of our "hidden features" that isn't documented, we're working on that. This was a very recent change that we made :)
--
John Bunting
Simplicity is a prerequisite for reliability
--Edsger W. Dijkstra
Felix Bonkoski
Jun 27, 2012, 12:38:29 PM6/27/12
to tumbl...@googlegroups.com
On Wed, Jun 27, 2012 at 11:23 AM, John Bunting <jo...@tumblr.com> wrote:
There is a new field on Post objects that I implemented called "liked". This field indicates whether the currently fully oauthed user liked the post or not. You must be fully oauthed though or this will not work or the field will not even appear.I know this is one of our "hidden features" that isn't documented, we're working on that. This was a very recent change that we made :)
Cool. I'll add that to my ever-growing list of "The Tumblr API: The Missing Manual" :P
--
Felix
Camila V.
Jun 27, 2012, 5:23:40 PM6/27/12
to tumbl...@googlegroups.com
Hey, those are sweet news! I'm curious to see all those hidden features, hahaha! Even if I'm not planning to do user authentication it won't keep me of checking out these features, they sound like fun and surely are surely helpful.
--
Still, going back to the initial concern, I think the current /like behavior is really a bit bugged, isn't it? I can totally see a malicious person inserting a code to make a visitor auto-like every post a hundred times, and the visitor wouldn't be even aware of this until he checked his dashboard. It's a piece of cake to be done and so far I've found no way to remove the fake likes from the user's counter. It's not a serious exploit but can be used to cause a big nuisance.
I'm going to check what /user/likes is returning later, when I have more time and clean up my code - too many tests' leftovers!
- Likes vs Notes
Kinda related but unrelated: Yes, I think I've confirmed that the ghost likes really mess with the notes count too. I've liked a test post a couple of times to trigger the bug of notes theme variable returning empty and had a look using the /post method. Look what I've got:
Well, in this case it's more like what I haven't got. There is no variable "note_count" at all, and I'm using "true" for "note_info". When this happens the {noteCount} theme variable returns 0 (even if the post actually has some notes and {noteCountWithLabel) returns empty.
Even the legit likes given to clean (with no ghost-likes) posts are kinda messed up when it comes to notes. Sometimes the value only updates after a reblog, I could wait 30min or 1h, the old value persists. Often the notes info events (bla bla liked this, bla bla reblogged this), if counted, doesn't match the note_count.
--
Still, going back to the initial concern, I think the current /like behavior is really a bit bugged, isn't it? I can totally see a malicious person inserting a code to make a visitor auto-like every post a hundred times, and the visitor wouldn't be even aware of this until he checked his dashboard. It's a piece of cake to be done and so far I've found no way to remove the fake likes from the user's counter. It's not a serious exploit but can be used to cause a big nuisance.
I'm going to check what /user/likes is returning later, when I have more time and clean up my code - too many tests' leftovers!
- Likes vs Notes
Kinda related but unrelated: Yes, I think I've confirmed that the ghost likes really mess with the notes count too. I've liked a test post a couple of times to trigger the bug of notes theme variable returning empty and had a look using the /post method. Look what I've got:
{"meta":{ (... bla bla all user stuff~~) },"posts":
[{"blog_name":"vielmond",
"id":26021566251,
"post_url":"http:\/\/vielmond.tumblr.com\/post\/26021566251\/aaaaaaaand-its-back",
"slug":"aaaaaaaand-its-back",
"type":"text",
"date":"2012-06-27 20:41:50 GMT",
"timestamp":1340829710,
"format":"html",
"reblog_key":"rX8cceFv",
"tags":[],
"highlighted":[],
"title":"Aaaaaaaand it's back!",
"body":"<p>Because ghost-likes are fun, that’s why!<\/p>"
}],
"total_posts":1}
}
Well, in this case it's more like what I haven't got. There is no variable "note_count" at all, and I'm using "true" for "note_info". When this happens the {noteCount} theme variable returns 0 (even if the post actually has some notes and {noteCountWithLabel) returns empty.
Even the legit likes given to clean (with no ghost-likes) posts are kinda messed up when it comes to notes. Sometimes the value only updates after a reblog, I could wait 30min or 1h, the old value persists. Often the notes info events (bla bla liked this, bla bla reblogged this), if counted, doesn't match the note_count.
Reply all
Reply to author
Forward
0 new messages