Post-Theory

Some Tools for Tumblr

[post-theories]

[post-theories]

Hi, I was just reading your post entitled "A small tumblr hacking project..." and I am very interested in the feature you were talking about magical post shuffling or randomization. I am trying to implement that feature on a blog, but cannot find anyway to do it. Have you done this, or do you know how? Please let me know, I very much appreciate it! Thank You!

Hi, sorry I didn't write back or answer this sooner.

Turns out this is rather difficult to do.

There was one loophole at the time I wrote that post -- if you changed the date/time when a post was "posted" you could make the posts appear in the order of the changed date/times. I did this via the Tumblr API.  (Although why you could change the date/time a post was "posted" makes no sense ... )  Anyway, Tumblr has since fixed that "bug" so the method no longer applies. And besides it had the limitation that beyond the first page of posts, the change of date/time didn't seem to work.

In the end I was able to implement a post shuffle / random list, but I couldn't do it simply with a Tumblr Theme or simply with the Tumblr API.

I used the API to create a cache of my Tumblr's posts on a remote server. I created a page on my Tumblr that loads the cached posts from the remote server (with Javascript AJAX) with the posts in a shuffled order.

Far from ideal, but it does manage to work.

An example can be seen here: http://lensblr.com/members

If you scroll down a bit, there's a divider in the page 'Older Members – Shuffled Randomly'  Posts after this point have been loaded from my remote server in a shuffled order.

Felix

[post-theories]

Hi there. Today I found out about your Pretty Tag Cloud Maker and I have to say it looks fantastic. Cheers for that and thanks. Just a small problem, once I have pasted the code on the HTML area of the tumblr page, every change I make relating to the tags, like change the name of a tag or add a new one. doesn't seem to synch with the script. I tried to paste the code again but it doesn't work. Am I doing something wrong? (by the way, I ask anonymously because my tumblr is NSFW). Thanks again.

Dear Anon, please read in the "Help" section, FAQ questions 4 and 5.

[post-theories]

it doesn't seem that you can exclude a tag that has a hyphen in it, is there a way to fix this?

To whoever Anon asked, this should be fixed now.

[post-theories]

hi there! is it possible to make the tag cloud widget show specific tags that we want instead of just omitting tags that we don't want?

No, that defeats the purpose!

If you just want to list certain tags on your tumblr, you should just do it manually by adding the links yourself to your page :)

Just add a bunch of links like:

sometag, anothertag, ...

And so forth.

[post-theories]

I've been thinking about social networks and social media sites.

It occurs to me that today, you get way more social SPAM from your "friends" / blogs / twitters / etc you follow, than you ever get Spam in your email Inbox.

And what can we do about this phenomena?

Edit: ivogeorgiev tells me it's not "Spam" but "unwanted content".

I mean what's the difference? Email Spam is "unwanted content" as well, and they've figured out pretty well how to separate the wheat from the chaff on that front.

Surely there is a way to apply the same kind of Spam filtering logic to the "unwanted content" on social sites like Tumblr, Facebook, Twitter etc.  For example Facebook offers some kinds of "filtering" abilities but honestly, putting things on lists, or Facebook's tendency to "help" your Feed by boosting Posts with more "activity" (comments, likes, etc) -- this does not a Social Spam Filter make.

[post-theories]

HI, I'm a web developer and the co-founder of Essence Labs Creative Agency. I just wanted to give you a little idea that popped into my head when reading the post about the tumblr api. You should try making a static page that automatically fetches posts using ajax and the v1 tumblr api, and then have that be placed in a random order. That might work better than the cron job so this way each user gets a different page. Don't know if it will work too well, but its worth a shot! What do you think?

The issue with AJAX and the Tumblr API is the cross-site domain restrictions in browsers.  The main page is at "foo.tumblr.com" and the information is at "api.tumblr.com".  Firefox and Chrome won't allow cross-subdomain AJAX calls like this.

You *can* use JSONP as a workaround for the cross-site scripting issue, but I find it inelegant and ugly.

But more to the point, when you need to load possibly hundreds of posts, the Tumblr API server is just too slow to get the results on the page in a reasonable amount of time.

Experiments from my webserver (which has a super duper fast pipe) shows an average of over 2.0 seconds to load 250 posts from the Tumblr API.  This slows to over 3.5 seconds on my personal computer and home internet line.  This is just too slow.

On the other hand, I can pre-emptively download the information from the API, extract what I need, cache the result in a "static" JavaScript file on my webserver and deliver it to the end client in just 100's of milliseconds.  And so this is how I plan to solve this problem, using the Tumblr static "Pages" to load a specially generated JavaScript file (or JSON or whatever) with the required "shuffled post information" and display it with a tiny amount of JavaScript.

This offers a better end experience to users.

Thoughts?

[post-theories]

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.

[chae9ahm]

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.

[post-theories]

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 could give 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.

[post-theories]

A Small Tumblr Hacking Project, and What I Learned

Recently I'v been working on writing some "back end" code for a Tumblr blog that wants to do some non-standard things using Tags.

I'm all about trying to hack the Tumblr platform: hacking with the Tumblr API & doing unorthodox things in Tumblr themes.

The project is called Lensblr (http://lensblr.com)  I'm not directly involved with creating the site. I'm just writing some devious back-end stuff to create added functionality.

The project caught my attention because navigation & view of the Tumblr is done exclusively through use of the /tagged/foobar pages. There is no view of the "main post feed".  It's an interesting idea towards creating a custom Tumblr website.

Magical Post Tags

One goal of the designer was to automatically add/remove specific tags from posts, based on set criteria.  In this case, the criteria is rather simple:

Based on the number of "notes" a post gets, add/remove tags that "move" the post to/from different pages on the Tumblr.

For example, after a post reaches 50 notes, we want to remove the tag the displays the post on one page, and move it to another page called "Featured Posts"

This is easily implemented using cron job that runs a script to analyze the posts on the blog, and use the Tumblr API to "retag" the posts as needed.

Of course, this kind of tag modification for changing how a site is presented could be extended and extrapolated to do lots of interesting things, based on any number of factors. It's a promising idea.

Magical Post Shuffling and Randomization

A second goal of the designer behind Lensblr was to implement a way so that posts on a particular /tagged/ Page could be randomly shuffled, such that older posts would sometimes reach the first page.

The principle is more equal exposure of content, regardless or whether or not that content was posted 2 months ago or an hour ago.

Not all content is Timely; and most people never make it past the 1st or 2nd page of a blog.

Fortunately, you can modify the Published Date on posts using the Tumblr API.  And when viewing posts through the standard "Posts" interface (mounted at / ), this works rather well. You are able to shuffle posts around so that older and newer posts get equal chance of exposure on the 1st or 2nd page of the blog.

Unfortunately, Tumblr seems to have a bug/limitation with sorting posts by "Time" on the /tagged/foobar pages:

If a post is on page 3 of /tagged/foobar, even modifying the post's Publish Date is not enough to ever bounce it up to page 1.  The post is "stuck" on page 3 forever. (or page 4, 5... etc as more posts are added).

Interestingly, on the individual pages  /tagged/foobar/page/X  the posts *are* sorted chronologically -- but only relative to the other posts on that page.

Based on this, I've concluded that while Tumblr "sorts by Time" it only does so per page; the actual posts that are put on a given page comes from "sorting by Post ID".  It's a bit inconsistent.

So although we had a sound principle and strategy, implemented the code to "shuffle" the posts around -- it just doesn't work within Tumblr's buggy / limited system.

Working within Tumblr's Limitations

Tumblr does not provide Developers with many good means for representing blog Content with different "views" or in different ways. Using Tags seems to be the only practical way to achieve these ends, for now.

Things that are not particularly useful:

The "Static Pages"

While these can contain arbitrary HTML completely separate from the main "Theme" they are rather useless from the perspective of creating / loading dynamic content, or content that changes with high frequency (say once a day).

"Pages" are not accessible through the Tumblr API, so making automatic changes to these Pages with code is not possible.

The Tumblr API

The API is OK if you are developing an application for the desktop or a mobile device. It lets you do *most* things you might want to do to create a "Tumblr Experience" on a mobile device, or say a "Tumblr Posting / Editing" program on the Desktop.

Where the API is not particularly useful is in trying to create dynamically generated content on web pages.

Tumblr only supports OAuth1.0 (they should really upgrade to an OAuth2.0 interface)

Tumblr does not support CORS, a technology that allows controlled "cross-site" AJAX calls.  Without CORS, as a developer you are limited to using rather ugly JSONP callbacks, and then only HTTP "GET" commands.

The available methods in the Tumblr API in many cases do not provide sufficient means to request the specific information you want:  first, there are not enough "filters" to select the data you want, no literally no means to control the "output" received from the API.  For example, if all I want is the list of "Tags" from posts on a blog - I still have to download *all that other data* which has no use for me. That adds up rather quickly to a *lot* of transferred data.

The API needs better methods of "selecting" the types of posts to return, and then needs to implement a way to filter down the data returned to only what you require in order to make the API useful in the context of creating dynamic web pages.

The API Server is just plain slow. Response times I observe are often in the range of 600-800 ms for simple requests (say "grab 50 posts"), and up to 2000-3000 ms for larger requests (say, "grab 200 posts"). Part of the problem is the before-mentioned lack of ability to "filter down" to just the data you need. Another part of the problem is that the API Servers refuse to use HTTP Keep-Alive if you will be requesting multiple pieces of data in quick succession.  The API Server should enable Keep-Alive.

So Why Bother?

Because Tumblr is a great social platform. You bother trying to create custom/specialized Tumblr pages to create a unique "Web Experience" while at the same time being able to take advantage of the social aspects that Tumblr can provide to your Page and your Content.

As a Developer however -- this is all rather frustrating.

Anyway, Tumblr just put up a Job Listing for API Lead. Perhaps that is a sign that things will get better in the near future.

But for now, it's all pretty foobar.

[post-theories]

Using Google WebFonts, and Being too Smart for my own Good

This issue came up on a recent project web project I've been working on.

In the project, I allow users to choose from a subset of fonts provided by the Google WebFonts API to style their Text in a pretty font.

The Problem - International Support

I get a message from a Czech user, requesting support for fonts that display the Czech language properly.  (The Czech script uses various characters found in the "Extended Latin" Unicode blocks)

Luckily, I find on Google Webfonts that you can specifically request fonts with various script subsets.

For example, suppose you want the font "Poiret One" with the Latin-Extended character set, you can request:

fonts.googleapis.com/css?family=Poiret+One&subset=latin,latin-ext

Splendid - sorta.

A naive approach to offering better "international support"

In my naive approach:

I examined the user's text to determine if any characters where outside the "Standard Latin Block" (eg, if any character's ordinal is > 127).

If so, I disabled the fonts having only "Latin" support, and only enabled fonts supporting "Latin Extended"

For supported fonts, I request the font from Google using the "subset=latin,latin-ext"  call, as above.

But that didn't quite work...

... Because it turns out (I suppose unsurprisingly) that many of the fonts Google has classified as supporting "Latin Extended" do not support many of the characters required to display Czech properly (and doubtless many other languages as well)

Now, I don't know who at Google determines how / why a font gets classified as supporting the "Latin Extended" block, what characters must be supported, etc.

But -- their classification system is quite simply broken. In more ways than this - as you will see.

Designing a "Smart" Approach

I decided that I could do better. I really didn't want to offer fonts if they would be unable to display the user's language properly. And since Google's "classification" was not thorough enough, I decided to do it myself.

I downloaded the relevant TrueType Font files from Google for the fonts supported in my app.

I wrote a small Python program utilizing the TTX/FontTools package to examine the TrueType files. It was relatively simple to search the 'cmap' table within the TTF File to see if the Font contained a Glyph for a given Unicode ordinal. I dumped the list of the supported Glyph Ordinals of the font into a Python set object, let's call it fontCharSet

I took the text the user was trying to render, and dumped the Unicode ordinals of the text into another Python set object, let's call this userCharSet

Now, determining if a font supported the user's language was as simple as calling one line of Python code:

fontSupported = userCharSet.issubset(fontCharSet)

Wow, that was easy. With just about 100 fonts to check, the process of validating the user's text against the supported fonts for my application took less than a millisecond.

(See appendix for code example) 

Now I had a great way to only show fonts to users if those fonts could properly display their language. And then I could retrieve those fonts with the extra needed characters, by specifying the subset when calling the WebFonts API.

I easily extended this include support for Cyrillic and Greek text as well, by separating the user's Text into the relevant Unicode blocks to determine which subsets to request from Google.

And now, when a user visits my page, only fonts I was certain could display their language were presented as options.

Awesome. Great.  ... Or so I thought.

It turns out that "subset classification" of fonts that Google offers is not just for your information -- it is also limiting.

Take the WebFont "PT Sans Narrow" -- a nice sans-serif font with narrow characters, and slightly tall Capital letters. It has good support for Latin, Latin-extended, and Cyrillic.

Running my "language checker" code revealed this font could correctly display all the characters in my Czech user's Text, and so this font was duly added to his list of "Supported Fonts"

Except it isn't supported - not really, not by Google.

If you examine the PT Sans Narrow Font Specimen on Google WebFonts you will see that "Latin Extended" is not listed as one of the supported character sets. Although, in fact, the font supports much of the Latin-Extended set -- enough at least to render my Czech user's text.

And requesting the font with

fonts.googleapis.com/css?family=PT+Sans+Narrow&subset=latin,latin-ext

Does not return any characters in the Latin-Extended block at all. At all. Not even the characters that do exist. You just get plain Latin. Sorry.

And it turns out that there are a bunch of fonts like this on Google WebFonts. Too many to list.

Fonts that, by examining the actual font file for Glyphs, you find are able to support a given user's language needs, but which you cannot retreive from Google with the additional characters needed.

The bottom line is - if it doesn't say "Yes this font supports Latin-Extended" then you can't retrieve those characters from Google WebFonts, even if they do exist.

Ugh.

Once again - too smart for my own damn good.

I have filed a bug report with the Google WebFonts project on Google Code for some of the fonts I have noted behave in this way. Although I do not suspect it will do much good, looking at the "Issue tracking" page for the project. (It seems there is little activity, and virtually no response to any issues reported). And there seems to be no "Support" page or link anywhere on the WebFonts page or the WebFonts API page.

Sigh. Technology sucks.

EDIT - March 15, 12:00 AM GMT

To my amazement, by complaining on the Google Font Directory Discussion group I actually got some feedback from a guy at Google who seems to be in charge of issues like this.

Basically, this is what I learned from him:

If a font is not listed as supporting a script subset on the WebFonts directory (e.g. "latin-ext") then it is not possible to retrieve those extra characters by using "subset=latin-ext", even if the font in question does indeed contain characters in the Latin-Extended blocks.

He cited one of the primary reasons for this limitation is that some fonts support too many Glyphs in the Latin-Extended block, and thus the resulting file size for the font would be too big. Gee Google, thanks for shafting people who don't use an ASCII Alphabet.

He was willing to "fix" the Encoding information for a few fonts that I complained about in particular, but again not those whose resulting file size would be too big.

Appendix: Python Code Sample:  (requires the TTX/fonttools library)

from fontTools import ttLib fontfile = 'PT_Sans-Narrow-Web-Regular.ttf' font = ttLib.TTFont(fontfile) cmaptable = font['cmap'].getcmap(3, 1) # platform id (3,1) = "Windows" fontCharSet = set(cmaptable.cmap) # set with Unicode ordinals for Glyphs in the font usertextfile = 'text-sample.txt' F = open(usertextfile, 'rb') with F: unicodeText = F.read().decode('utf-8') # create set of Unicode ordinals in the text # (use ord(c) > 32 to skip control characters) userCharSet = set([ord(c) for c in unicodeText if ord(c) > 32]) fontSupported = userCharSet.issubset(fontCharSet)

[post-theories]

Thoughts on Internationalization

I added a bit more support code for international users of my "Tumblr Pretty Tag Cloud". There is still quite some work to do however!

I never really though about "internationalization" when I set off writing the code. Honestly, I gave no second thought to non-English speakers -- and the various scripts (i.e., the different "alphabets" we use to write "letters" or "words" etc)  and the various character encodings (the "computer representations" of those scripts) that come with that. I am aware of all these things - but I did not really plan for it, at all.

In my head, it is so easy to assume "everyone on the internet uses English". Part of this I think has to do with where I live and grew up (e.g., not a major cosmopolitan city, where you find people from different countries and with different languages), and part also because (for the time being, perhaps?) English is the lingua-franca of programming and the Web -- and I am never really exposed to "Non-English" websites.

And yet now I find that the good majority of people using my tool are non-English-speaking users. It should not surprise me, I guess - but it still does. Users from Peru, Chile, Brazil, Norway, Czech Republic, Germany, Korea, Japan, Russia - you name it.

Still, I think it is good, that my first real "public software release" has ushered me so quickly into the rest of the world, and forced me to confront some of the challenges of writing "internationally aware" software.

A few technical points that made all of this much easier than it could have been:

I have been using a Python webstack to develop my server-side code. (because PHP is so yucky). One of the best things I have found in Python is that it is quite easy to write internationally "aware" code. It is simple to maintain all of your strings / text data as Unicode strings -- they act exactly the same as a standard Ascii strings, coerce to a conventional string object as needed (eg, suppose you have a unicode string x = u'1' and want to test x == '1'), and are easy to encode to various encodings (although the simplest thing -- and the default --- is to always work with utf-8). I didn't have to modify a single line of code to "make it work" with characters outside the ascii (or Latin) range.

It pays to have a good JSON library that encodes your Unicode strings properly for use in Javascript. Don't try to cobble one together yourself or use some half-assed implementation someone else threw together in an afternoon. The JSON library in the Python Standard Library does a perfect job  -- although it turned out to be quite slow. So I am using a C-implemented Python library jsonlib with excellent results.

It's a big help if your Web host (or you!) has your HTTP server configured properly to set HTTP character-encoding headers. If not, you will struggle to remember to set them yourself manually and correctly each time you return data to the client. Configure your server! Don't make ugly code. My particular webstack runs on a Python-based WSGI server called CherryPy. It does a spectacular job of properly & automatically interpreting character data in HTTP requests (and returning you nice Unicode string objects), as well as automatically encoding data & setting headers for your HTTP responses.  Again - not something you should try to cobble together yourself! Someone else has done all this nitty-gritty hard work already. Use their work and benefit from it. Keep your code consistent: pick a standard and stick with it. I always work with Unicode strings in my code, and always send output as UTF-8. The HTTP server can handle re-encoding if necessary.

Well, those are just some thoughts.

Felix

[post-theories]

Tumblr "Pretty" Tag Clouds

I'm putting up a beta preview of my new Pretty Tag Cloud maker for Tumblr.

Design your own Pretty Tag Cloud: choose your fonts, colors, etc.

Then Save it, share a link, embed it on your Tumblr Theme or in a Tumblr Post.

w00t !

[post-theories]

Tumblr Themes: Don't Trust a URL is "HTML Safe"

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!

[post-theories]

Tumblr Theme Limitations: When a "Block" Doesn't Exist, Part 2

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.

[post-theories]

Tumblr Theme Limitations: When a "Block" Doesn't Exist, Part 1

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!

[post-theories]

Undocumented Features are (not)Cool

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:

http://www.tumblr.com/reblog/18132446503/xA660hqO

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

[post-theories]

Tumblr Tag Cloud Javascript

Hello!

I have decided to go ahead a release my Tumblr Tag Cloud Javascript widget.

This is just a version 1.0, so you can expect a few bugs and whatnot.

Feel free to use it on your own Tumblr!

Thanks, ~ Felix