Like I said, I was writing a wordpress plugin. I wanted to automatically highlight code posted within <pre> tags. And no, I didn’t want <code> tags b/c those aren’t part of the native wordpress editor toolbar – the goal was to be able to embed highlighted code while just being completely lazy and staying the “Visual” tab.
This got boring really quickly, especially once I saw that someone had already done something similar, except weak and pointless. If I’m going to upload “code snippets,” why don’t I just run them through enscript while I’m at it and paste the damn output?
Anyway, then I thought “Hey, this flickr plugin I’m using kinda sucks and isn’t very good about letting me pick which size of photo I want to embed.” It’s a global setting. FAIL.
So then I thought “If Crowley’s drunken ramblings about some sort of open standard for embedding media had any actual substance, I could easily improve this.”
They did. He was talking about oEmbed.
I’m gonna cut this story short because I’m fucking burned, but here’s what I posted on Cal Henderson’s website’s discussion:
I’m messing around with oembed on flickr – not seeing a way to specify which size of the image I want to embed. I tried some combinations of changing the URL and maxwidth/maxheight settings in the request, but to no avail. I tried: www.flickr.com/services/oem… www.flickr.com/services/oem… www.flickr.com/services/oem… All three return the same thing: [ the xml output of this request ] Are we not there yet? I was thinking of making a flickr oembed wordpress plugin. It’ll still work, but will be limited to the one size. Is there a way to work this? Would it be possible to set up server side logic @flickr which actually checks the /sizes/foo part of the URL and returns the appropriate URL/size info? I haven’t thought about it long (and it’s late) but that seems to be in line with the standard – would only have to change the url GET var in the request, putting all the logic on the providers side and just spitting out the right image. Cheers. Mike.
Um…. http://www.flickr.com/services/oembed/?url=http://flickr.com/photos/mikepanchenko/617998417/&maxwidth=300&maxheight=2000 and http://www.flickr.com/services/oembed/?url=http://flickr.com/photos/mikepanchenko/617998417/&maxwidth=3000&maxheight=200
both give me the 240×180 photo while if I make the maxwidth less than 240 or height less than 180, I get the thumb at 100×75 or square at 75×75. And if I go smaller than those dimensions, it doesn’t return a photo.
I don’t know why it never returns the large (1024×768) or original (2592×1944), but it seems to return all the sizes relevant for a blog.
Well I assumed it would work downward with the constraints, didn’t even check that.
You bring up a good point about the sizes needed for the purposes of a blog, but what if I want to link to the larger image w/o actually sending the user off to flickr? I suppose then flickr isn’t entirely happy with me, but if I’m uploading stuff that’s huge, I’m probably on a paid account anyway, and should be permitted to do this.
I would like it if it at least gave you the larger sizes when the url pointed at sizes/o or sizes/l, as you’re sort of implying that you want them. (I don’t think my logic here actually makes sense though, since asking for a large maxwidth and maxheight also implies you want a larger size photo).
On a different note, do you know why oembed specifies the provider has to use http and can’t use https? That seemed semi-arbitrary to me.
Right – I actually think that doing that in the URL would be the best way, for flickr anyway, since maxwidth/maxheight have their own purpose – to make sure you don’t end up with something that doesn’t fit your target design.
I haven’t looked at the http stuff, but I’m guessing it’s just a logistics thing – serving content to other sites via SSL is taxing.