So, in writing my theme, I wanted a way to put a “Reblog” and “Like” link on each post on the main page of the blog without users having to “click-through” to the “/post” page, and use Tumblr’s silly <iframe> in the upper right corner.
Interesting. I discovered a similar thing, but at the end, ended up including the iframe for each single post, setting opacity: 0, and aligning/scaling it so that it matches my button positions. Does the desired effect, only until I realized I cannot highlight my heart button when the post is liked, because I don’t and can’t know if the post is liked. After some research, I found out that there IS a way to do it, only I don’t know how.
Edit: no, there seems to be no way. At least nobody has done it.
Right. The “reblog” is easy. The “Like” button is tricky — not to “make it work” but to show whether or not the Post is already “Liked” or not.
Reading the contents of Tumblr’s own iframe to determine, say, which image they are using couldgive the result, but most browsers today prohibit inspecting the embedded iframe’s HTML with JavaScript for security reasons. Similarly, you cannot load the iframe’s content with AJAX because of security restrictions. Perhaps with JSONP? I don’t know, haven’t tried to hack it out further. And then yes, any “solution” would still be an ugly hack, likely to break whenever Tumblr’s whimsy programmers decided to mix things up a bit.
What really needs to happen is to just incorporate these functions into the Tumblr Theme Engine. It would probably be like, a few hours work for some Tumblr employee to implement this.
I also thought about scanning the notes of every post to check if you have liked it. Terribly inefficient, but it should happen fast enough for posts with 0-20 notes. It would have to be disabled for posts with more than 100 notes (or at least scan only the first 100 ones). Also, it would put a lot of queries on the Tumblr servers.
Yes, this is not a very robust technique. And Tumblr doesn’t look kindly on “page scraping” in general. Nor is there a way in the Tumblr API to fetch more than the most recent 50 notes for a post — at all!
But who cares, if they don’t want this they better improve their support - I have never heard a story of a theme designer who got in touch with the tumblr programmers.
Oh — well I have at least tried to get in touch with the Tumblr folks, on several occaisons.
And at least on the Tumblr API Google Group, there is one Tumblr Employee (John Bunting) who monitors the discussion in the group and is able to provide some feedback. However, he seems fairly powerless in the overall Tumblr structure to get any *real* changes made, although he has been helpful in fixing some bugs, etc. (The Tumblr Theme Google Group seems to be completely unmoderated by any Tumblr employees).
I’ve also sent emails to the Tumblr staff a several times about bugs in the API and Theme engine, and requests for features, etc. I usually get what looks to be a “real response from a real human” back — but nobody ever follows through to fix any of the problems I mention.
On the whole, Tumblr seriously needs to improve their support for developers. This is means listening to feedback, answering questions, fixing bugs and problems quickly and promptly.
For now - it’s really a giant headache.
Part 3 in my series on “Tumblr Theme Limitations”
AKA, Why Tumblr’s Theme Template System is Incredibly Lame,
and Hacks You Can Use to Get Around Its Limitations & Lameness
Introduction
In my previous Article, I pondered whether or not URL’s supplied by Tumblr’s Theme Templater were in general safe to include directly in JavaScript strings: i.e., that they had at least been properly Escaped for inclusion inside a Double (or single) quoted String.
I decided that, No: Tumblr is lame. So I should not assume that:
- URL’s have been properly escaped for inclusion in Strings
- URL’s have been properly URL Encoded to replace URL-unsafe characters
But at least there is the {JS…} Variable Transform, which does seem to function properly — so far as I can tell. And it’s useful too — we’ll get to that more in this article.
The Question
This led me to wonder if in general, URL’s supplied by Tumblr’s Theme Templater were even safe to include directly in your HTML — e.g.
<a href="{SomeURLVariable}"> ...
The Question: Answered
The Answer is NO: You cannot assume that Every URL that Tumblr passes you is Safe to include in your HTML.
Case Study: {LinkURL}
{LinkURL} is the “Click-through Link” rendered in Photo Posts. I also discussed this very same variable last time
Let us suppose that somebody enters a rather naughty “Click-through” URL:
http: //naughty.urls/break” onclick=”javascript: alert(‘Tumblr is lame!’); return false;
Now, you being the good Theme Developer you are, write your Theme Code like this:
<a href="{LinkURL}"><img .... ></a>
Looks fine, right? Wrong. This is what actually gets rendered on the page:
<a href=”http://naughty.urls/break” onclick=”javascript: alert(‘Tumblr is lame’)”><img …. ></a>
Well - you can guess what happens when someone clicks that Image!
Go see for yourself on this page. Really, go try it. There are two examples. One contains a “naughty” URL, and the other a “nice” URL which just happens to include a “ character in it.
The (hacky) JavaScript Solution
Since I’ve already established that the {JS…} Variable Transformation seems to function properly, I’m going to solve this problem with some hacky JavaScript. Once again.
For the sake of brevity, let’s just assume that {LinkURL} exists — I already showed you how to handle those cases when it does not.
And here’s the basic code:
{block:Photo}
<script>
document.write('<a href="' + encodeURI( {JSLinkURL} ) + '">');
</script>
<img src="{PhotoURL-500}">
</a>
...
{/block:Photo}
Wrapping {JSLinkURL} with the encodeURI JavaScript function makes sure that the link is actually safe to include inside the href=”…”.
You can see now, on this new page, the results. The “naughty” URL no longer does anything bad, and the “nice” URL works properly.
If {LinkURL} is broken, then what else is Broken?
Honestly, I don’t know yet. I haven’t tried to test every single type of {URL} Variable on Tumblr’s Theme Templater.
Here are things I know think are OK:
-
In {block:ContentSource} Blocks, the {SourceURL} seems to be OK.
-
URLs to pages in your own blog [eg, {Permalink} ] all seem to be OK.
Things I have observed to be broken in the same way as {LinkURL}:
-
Links to a User’s own “Pages”:
Inside the {block:HasPages} and then {block:Pages}, the {URL} variable is not properly escaped / URL encoded
What could happen is a user sets up one of their pages with a URL like:
htp://my-blog.tumblr.com/”About Me”
That will break, if you try to include the {URL} directly in your HTML.
As I find more bugs, I will update this post to let you know!
In Part 1, I discussed an approach to handling Tumblr Theme Variables that do not have corresponding {block:Foobar} Variables to wrap code to only render when the variable {Foobar} exists.
I used the {PlayCount} variable (rendered in Audio and Video blocks) as my example. In the end, I came up with the following solution:
<script>
if ( "{PlayCount}" ) {
document.write("<span>played {PlayCount} times!</span>");
}
</script>
… which works fine (in this case), even though it is an ugly solution.
But Sometimes Things are More Complicated
Now I would like to talk about the {LinkURL} variable, which is rendered inside of Photo posts. This is the so-called “Click-through URL” for a Photo.
Now, Tumblr has the absolute strangest feature for this variable: a corresponding {LinkOpenTag} and {LinkCloseTag}, which renders an HTML anchor tag (<a href=”…… “>) for the {LinkURL} only if it exists.
Well, that might be fine for some people. But what if I want to modify that <a> tag? Add a class name to it? A title attribute? Etc.
Basically - I find {LinkOpenTag} and {LinkCloseTag} completely bizarre and completely out of place with the rest of the Tumblr Theme Template system.
And again - we have the same problem: There is no {block:LinkURL} variable to tell you when {LinkURL} exists.
Trying to Solve the Same Problem the Same Way
So, of course I tried to use the same approach as before:
<script>
if ( "{LinkURL}" ) {
document.write('<a class="foo" href="{LinkURL}"> .. </a>');
}
</script>
And yes, this probably works 99% of the time.
But I don’t really trust a URL can be inserted directly into a Javascript chunk in this way. A URL could possibly break the Javascript String in this example, if it has not been escaped properly.
Does Tumblr escape the {LinkURL} properly? I don’t know — but seeing how many other things they manage to mess up, I’m just going to guess and say No, just to be on the safe side. Maybe it’s escaped fine for HTML, but not JavaScript. Who knows.
So…Tumblr’s Variable Transformations to the Rescue!
Wait - again you ask? I thought you dismissed that in Part 1.
I did dismiss it.
I showed how {JSPlayCount} does not do what the Tumblr Documentation says it should - namely return a Javascript-safe string representation of {PlayCount} wrapped in quotes. [verbatim from the documention]
Instead it renders nothing, and not wrapped in quotes. Fine.
But it Gets Weirder.
But I really want to make sure my {LinkURL} is safe to include in my script.
So I tried playing around with {JSLinkURL}. Now, I figured it would behave like {PlayCount} — namely that if it didn’t exist, then {JSLinkURL} should render nothing.
So I had a stroke of genius:
<script>
if ( [ {JSLinkURL} ].length) {
document.write('.....');
}
</script>
Notice the brackets create a list. Now, an empty list [] is a valid JavaScript expression, so if {JSLinkURL} does not render anything at all, this yields:
if ( [ ].length ) { .... }
Which is valid Javascript, and will return False, if {LinkURL} does not exist.
Problem Solved — Right?
Oh, wrong, wrong again.
I thought it was working.
And then I came upon some curious posts, which for some reason or other, have no {LinkURL}but where {JSLinkURL} actually does render an empty JavaScript string “” !
But then again, it is Tumblr. Sometimes it works, sometimes it doesn’t.
In these weird cases, where there really is no LinkURL, but {JSLinkURL} renders an empty string, you end up with this:
if ( [ '' ].length ) { ... }
Which unfortunately, returns True in Javascript. @#$!
So, revising the code a little:
if ( [ {JSLinkUrl} ].length && [ {JSLinkUrl} ][0] ) {
....
}
This works in both cases. If {JSLinkUrl} renders nothing, it yields:
if ( [].length && [][0] ) { ... }
Which is fine because JavaScript has short-circuit evaluation with the && operator.
If {JSLinkURL} renders an empty string, it yields:
if ( [ '' ].length && [ '' ][0] ) { ... }
Which is also fine, because although [ ” ].length is True, [ ” ][0] is False in Javascript, since ” evaluates to False.
Putting it all Together:
<script>
if ( [ {JSLinkUrl} ].length && [ {JSLinkUrl} ][0] ) {
document.write('<a class="foo" title="bar" href="' +
encodeURI( {JSLinkUrl} ) + '"> ... </a>');
}
</script>
Edit 2/24/2012:
Using what I uncovered in Part 3, I now recommend wrapping {JSLinkURL} with encodeURI because this variable is not properly escaped / URL encoded!
This is a fairly robust way to emulate a {block:LinkURL}, while ensuring that:
- The JavaScript raises no errors
- The LinkURL you insert is safe to insert directly into the JavaScript code.
It’s ugly. It’s a hack. But it works.
Sometimes it seems like Tumblr actually had developers in mind when they created their Theme Template system.
Other times — well, a lot of things are simply a f**ing cludge.
Let me give you an example I recently encountered, and how I solved it (in an awful, hacky way.)
For some theme Variables, Tumblr was nice enough to include a {block:Foobar} variable to let you know whether or not some piece of data {Foobar} exists or not.
eg, The Post Title: {Title} and the corresponding {block:Title}:
Anything wrapped with {block:Title} … {/block:Title} is only rendered IF {Title} exists.
That’s super nice. I like that.
And it sure would be nice if a bunch of over Variables also had those “if this exists” wrapper blocks.
Here’s the specific case I’m talking about. I was working on the HTML to render Video posts. One of the neato variables in the Video block is {PlayCount}.
OK, cool. I would like my theme to show how many plays a video got.
So, I very naively wrote something like this:
<span>played {PlayCount} times!</span>
And no matter how many times I played that damn video, {PlayCount} never rendered anything.
Well, it turns out that {PlayCount} only exists if a video was uploaded to Tumblr, not if you embed a video from say YouTube.
OK, fair enough Tumblr - I understand you can’t count the number of plays of an embedded video.
But then, you should at least let us know that you can’t tell us the {PlayCount}, with a nice {block:HasPlayCount} or something. Otherwise my theme / blog looks stupid.
Steps Toward a (hacky) Solution:
-
Let’s try some Javascript.
Also, I happen to know that Tumblr is so cool, that it has variable transformations.
So I know that I can “Prefix any theme variable with JS to output a Javascript string (wrapped in quotes)“ [straight from the docs]
Oh, cool. So, if {PlayCount} doesn’t exist, then {JSPlayCount} should yield an empty Javascript string: ”” Right?
<script>
if ({JSPlayCount}) {
document.write(“<span>played {PlayCount} times!</span>”);
}
</script>There we go! Perfect!
-
Wrong.
It turns out that if a Variable like {PlayCount} doesn’t exist, then {JSPlayCount} doesn’t exist either - at all. And no, it does not get wrapped in quotes. You do not get an empty string. You get nothing.
So you get a Javascript error with the statement:
if ()
…because you need something inside that if() statement.
-
OK, fine. I know {PlayCount} should be a number, so it’s probably safe NOT to use the JS Variable Transform:
<script>
if (“{PlayCount}”) {
document.write(“<span>played {PlayCount} times!</span>”);
}
</script>And that works just fine. It’s ugly, but it works, and does not generate Javascript errors.
But wait, There’s More!
… continued in Part 2!
So, in writing my theme, I wanted a way to put a “Reblog” and “Like” link on each post on the main page of the blog without users having to “click-through” to the “/post” page, and use Tumblr’s silly <iframe> in the upper right corner.
Well. I investigated the contents of that <iframe> on the Post page, and found it was pretty simple, as long as you had a little value called “rk=xxxxxxxx” (or the “reblog key”)
<iframe src=”http://assets.tumblr.com/iframe.html?10&src=http%3A%2F%2Fblog.post-theory.com%2Fpost%2F18132446503l&pid=18132446503&rk=xA660hqO&lang=en_US …
Naturally, this value is not included in the {Posts} blocks by Tumblr’s theme template engine.
Easy, I thought: I’ll just secretly load the “Post” page for each post in the background with an AJAX call, and steal the “rk=xxxxxxx” value from the src attribute of the <iframe> !
Well, that was working just fine! Super-duper!
And then I read that there is an undocumented Theme operator: {ReblogURL}
Seriously? Undocumented features! Super cool! Lame. C’mon Tumblr. Really? Features should be documented. How long would it take you to just fix your documentation?
{ReblogURL} looks something like this:
Where the big integer is the PostID, and those 8 alpha-num characters at the end are the same as that elusive “rk=xxxxxxxx” reblog key.
Oh well, so much for all my cool background AJAX calls :P