Twitter and Facebook Have Not Killed Their RSS Feeds, Completely

Yesterday there was a fuss about alarming news that Facebook and Twitter had both killed off their RSS feeds (“completely”).

This led to much hand-wringing, name-calling and gnashing-of-teeth.

Except that they haven’t (“completely”).

It is accurate that the links to feeds are gone from their HTML pages and the META tags in the head sections of the pages.

The feeds themselves are still there and still working. My site UVFood aggregates restaurant news from Facebook and Twitter and is getting its feeds from both just fine.

To get an RSS feed for a Facebook page, use this URL:

changing ‘XXX’ to the page’s id and ‘atom10’ to ‘rss’ if you prefer ‘rss’.

To get an RSS feed for a Twitter user, use this URL:

changing ‘XXX’ to the Twitter user’s id.

Now, back to something useful.

Getting Around Same-Origin Policy in Web Browsers


Web browsers enforce a security policy called “Same Origin Policy” in order to protect their users from attacks by malicious web sites. The “Same Origin” policy requires that any attempt by Javascript on a web page to access a web site must go to the same web site that the web page came from.

This protects the user from attacks where a page contains malicious code that would attempt to access another site that the user is currently logged in to and do things as that user that the user most likely wouldn’t want to do, for instance, use Facebook or Gmail to spam other users.

This is a good thing, but occasionally it gets in the way of developers who are trying to do something useful and not malicious. In my case, I’m writing a small Javascript-based app to run in a browser. The app needs to make asynchronous page fetches from web servers running on devices in my house in order to control them. The app utilizes Phonegap to allow it to run as a native iOS app, albeit browser-based. Phonegap disables Same Origin Policy in Mobile Safari (only for Phonegap apps), but I want to write it and debug it on a browser under MacOS X, which is a much more convenient environment to work in.

Thankfully, browsers often provide a way to allow developers to turn off Same Origin Policy temporarily. Unfortunately, different browsers do it different ways.

Google Chrome can be started with an option to turn off the Same Origin Policy. Unfortunately this disables it for the entire browser, until you restart it. I wish there were a way to do this for just one web page or tab.

(or wherever Chrome is stored on your computer)

Apple’s Safari offers a similar mechanism:

Firefox has a nicer solution. Any Javascript application can request that Same Origin Policy be relaxed for it. The browser will confirm with the user.

These days I do most of my web development using Google’s Chrome, but Firefox’s solution to my problem will bring me back to it, at least for this project.

I’m developing under MacOS X so whatever difficulty there may be disabling Same Origin Policy in Internet Explorer doesn’t matter to me. I also don’t have any information on disabling it in Opera.

Nutrition Labels for WordPress

I’ve just released a plugin for WordPress, wp-nutrition-label. It provides a WordPress shortcode which generates an HTML FDA-style nutrition label. For instance,

Nutrition Facts Serving Size 1/2 cup Servings 2
Amount Per Serving
Calories 87 Calories from Fat 27
% Daily Value*
Total Fat 3g 4%
Saturated Fat 1g 5%
Trans Fat 0g
Cholesterol 0mg 0%
Sodium 250mg 10%
Total Carbohydrate 10g 3%
Dietary Fiber 0g 0%
Sugars 0g
Protein 5g 10%
* Percent Daily Values are based on a 2,000 calorie diet. Your daily values may be higher or lower depending on your calorie needs. wp-nutrition-label

The label is styled to scale but doesn’t yet scale well. Some elements of it work well but the “Nutrition Facts” text sometimes scales poorly. I’m looking at ways to improve the way that the label scales.

I’m also working on adding more nutrients (vitamins and minerals) to the label but haven’t quite decided on how to do it yet.

This is the first piece of software I have publicly released in a very long time. It’s quite likely the first piece of GPL’d software I’ve ever written – most of the software that I have publicly released (MIT’s PC/IP, in particular) was written pre-GPL. It’s ironic that it’s written in PHP, one of the my least favorite programming languages ever, though as much as I dislike PHP I have a great deal of respect for WordPress.

How to Quote a Shortcode in WordPress

WordPress offers a handy mechanism called a “shortcode”, which is a kind of macro. Shortcodes are supplied by WordPress itself and by plugins that extend WordPress’ functionality.

You use a shortcode by simply writing it in your post or page enclosed in square brackets, ie:

When you’re writing a post about a shortcode in a plugin you’ve written and are using in your web site, you’ll run into a problem where you will want to show examples of the use of the shortcode, but the examples trigger it.

You can quote the shortcode by doubling up on the opening and closing square brackets, ie:

I didn’t know this and didn’t need it until recently and was agonizing about it until I found how to do it.

Eating My Own Dog Food

For a while I’ve been advising people who need simple web sites to use WordPress. Not just people who want to blog, but people who need a very simple site with just a few pages. The reason I’ve been suggesting they use WordPress is that it’s easy to update pages (WordPress has a built-in WYSIWYG editor and automatic menu building), simple to extend and change the appearance of, and easy to maintain. Because you can keep drafts of your work in WordPress itself and it runs on the server, it also doesn’t matter where you work on it from, so you don’t have to worry about business computer versus home computer.

A downside is the prominent security issues WordPress has had of late (though the folks behind WordPress are prompt in fixing issues and clear about letting people know they need updated software). I want to be clear that I am in no way suggesting being lax about installing security updates, but it is true that a WordPress install that’s basically read-only – no user commenting and no remote posting enabled – is much less likely to suffer a break-in than a common blog would be.

I haven’t touched my web site in years. I started a blog at and until now hadn’t posted to that in almost a year.

My site consisted of several poorly laid out pages that were quite out of date, written using Perl’s HTML::Mason package. I quite like HTML::Mason but it was overkill for what I was doing, and I’d like to get mod_perl out of my web server.

So I’m going to eat my own dog food and move my site to WordPress. In fact, I’ve just remapped things so that the blog is now the site, and I’ve switched to using WordPress 3’s standard theme, TwentyTen, with some tweaks. Because I’m also trying to get over not-invented here syndrome. (If you subscribed to the blog at the old address you don’t need to change anything; it should just keept working.)

I’ll move over pages from the old site as I have time to rewrite and update them.

Mmmm, dog food. Not as bad as it sounds!