Recently, Picasa started serving its RSS feeds over https. From what I can tell, this has caused quite a view “clients” to fail. Digital photo frames seem to be affected, and so is my Flickr widget. Fortunately, there’s a quick fix.

I’ve run a few tests, and it seems that simply removing the “s” from “https” fixes the issue. Every feed I tried could be called up over regular old http as well, and all of them worked with my widget.

So if the RSS link in Picasaweb gives you an https feed URL like this one:

https://picasaweb.google.com/data/feed/base/user/roy.tanck/albumid/5053904170293136801?alt=rss&kind=photo&hl=en_US

You should change it to this before entering it into the form that generates the widget:

http://picasaweb.google.com/data/feed/base/user/roy.tanck/albumid/5053904170293136801?alt=rss&kind=photo&hl=en_US

As always, the preview will show you whether the feed works.

Just a quick post in case anyone else ever runs into this and manages to find their way to my blog.

I just came across this in a client project I’m working on. I was using a TextField in Flash CS5, and needed to know the width of the actual text inside it for positioning purposes. What I found was that in about 50% of cases, the textWidth property would return zero instead of the strings length in pixels. I tried using autoSize on the TextField and found that it would shorten half of its instances to a single character or less, causing the rest of the line to be invisible.

At first I thought there was something wrong with the font file, but the same happened with Verdana. So I started randomly changing settings, and it turns out that the “anti-alias for readability” setting was causing this. As soon as I changed that setting to “anti-alias for readability” the textfields were being autosized properly, and reported their actual lengths through the textWidth property.

I didn’t really investigate this any further once I found out this workaround. In fact, I needed to use “anti-alias for animation” anyway in my project. Please feel free to comment if this has happened to you, and/or you have more details about this strange little bug.

When I first started using WPMU, the now-integrated multisite version of WordPress, I found it strange that there were no built-in tools to aggregate content onto the main blog. It seemed to me that that was something plenty of people would want to do. Sure, there were plugins and hacks, but none of them were as polished as I’d like them to be.

Fortunately, things have changed. WordPress 3.0 now has multisite capabilities built right into it, and Bjorn Wijers, a friend of mine and one of Holland’s top WordPress developers, has created a really cool plugin to handle content aggregation. Called bbAggregate, this plugin doesn’t just collect posts from blogs to be displayed on the home page, it allows you to display aggregated content on any of your network’s blogs. And to do this it introduces the concept of streams.

Streams

Once installed, bbAggregate will allow you to create and manage so-called “streams” of content. If there are multiple bloggers in your network who write about cats, you could set up a stream called “cats”. Post authors would ten be able to add posts they write to the “cats” stream. At the same time, they can choose to show the “cats” stream on their blog. If others blog about dogs, setting up a “dogs” and a “pets” stream makes sense. It may help to think of streams as a type of category, but there’s a little more to it than that.

Control

Unlike with (site-wide) categories, bbAggregate offers fine-grained control over what is shown in a stream. You can exclude blogs, limit the number of posts per blog and set up pagination. There’s no per-post control over what is in the stream (other than by editing that post, if you have the right privileges), but the plugin makes it very easy to exclude blogs that don’t play nice.

Room for improvement

This is a brand new plugin. Considering how complex the underlying code must be, the currently released version is very mature. However, there are a few things I think could be improved. The main one is that in order to display a stream, some theme editing is required. This is a well-documented and easy process, but I’d love to see a more seamless integration in future versions. I’m pretty sure this can be done, and it would greatly improve the project’s change of being widely adopted.

If you’re looking for a flexible way to cross-aggregate posts on your multisite WordPress install, I’d highly recommended checking out bbAggregate.

Don’t get me wrong. I hate nag screens as much as anyone, but after playing the free version of iBubble Shooter for quite some time I’m can’t really blame them for trying to get me to upgrade. The game is based on the classic bust-a-move principle, in which you shoot bubbles from the bottom of the screen trying to group them together based on color. It’s pretty good, certainly the best touch screen translation of the concept that I’ve played. At € 0.80 it’s a steal. But that was even more true for the original free version.

What Absolutist, who made the game, probably shouldn’t have done was create a free version that allowed you to fully play the game. Up until a few days ago, there was very little reason to buy the ‘pro’ version. Other than being able to save your game and return to it later, it offered very little over the free one. The nag screens in the new version fix that, but it feels like Absolutist has taken something away from me. They’ve made my experience worse.

I guess this is a good case study for iPhone app developers. If you’re planning to make money off of your app, you should probably limit the free/demo version right off the bat. You can always remove or relax limits, but adding them later won’t earn you any points with users. And if your app is as good as this one, I’d recommend pricing the pro version a little higher.

For a project I’m working on, I needed to create a split menu, where the top level navigation was in a horizontal menu in the header, with all underlying content listed elsewhere on the page. This turned out to be a little harder than I had anticipated, but I managed to get it working. Here’s how I did it. Feel free to add suggestions in the comments if you see room for improvement.

The horizontal menu

For the main menu (shown in red in the image above), I wanted to use WordPress 3.0′s new ‘Menus’ feature. By doing so, my client has full control over the menu’s content. Setting it up is very easy to do, so I won’t bother explaining it here.

WordPress automatically adds CSS classes to the menu for selected items, so highlighting the current selection is very easy.

#mainmenu li.current-menu-item,
#mainmenu li.current-page-ancestor,
#mainmenu li.current-post-ancestor,
#mainmenu li.current-category-ancestor { background-color: #00f; }

The sub menu

The main issue with the secondary menu (light blue in the image) was figuring out what to display. It’s easy enough in WordPress to feed the current page’s ID number to the wp_list_pages function and get its children, but in this case, that’s not what I wanted. I needed to display the menu from the selected main menu item on down, even if the current page was nested four levels deep. So instead of using the current page’s ID, I needed to figure out the selected top level page, and use that page’s ID.

function rt_getTopPageID( $page_ID ){
	$ancestors = get_post_ancestors($page_ID);
	if( !empty($ancestors) ){
		foreach( $ancestors as $ancestor ){
			$anc = get_post_ancestors($ancestor);
			if( empty($anc) ){ return $ancestor; }
		}
	}
	return $page_ID;
}

I added this function to my theme’s functions.php file. What it does is move up the page hierarchy step my step until it reaches the top page. It returns that page’s ID for use with wp_list_pages. I’m aware that this may be slow, but it’s the most efficient way I could find to get the top page.

On the sidebar, I used something like this to display the sub menu:

global $wp_query;
$page_ID = $wp_query->post->ID;
$toppage = rt_getTopPageID( $page_ID );
wp_list_pages( 'title_li=&child_of='.$toppage );

What this does is get the current page’s ID from the page query, and feed it to my rt_getTopPageID function. The returned ID is then used to call the correct menu.

Categories

I then needed to do the same for categories. I ended up creating a sidebar widget that, depending on the context, displayed the right menu. The widget is very specific to my project, but here’s the function it uses to get the top category.

function rt_getTopCategoryID( $cat_ID ){
	$pathStr = get_category_parents( $cat_ID, false, '[#]', false );
	$pathArr = explode( '[#]', $pathStr );
	$cat = get_term_by( 'name', $pathArr[0], 'category' );
	return $cat->term_id;
}

This function uses a shortcut to get to the top level category. The get_category_parents function returns a string with the full hierarchy, which we can then split. The first item in the resulting array is the top category’s name. Using get_term_by, we can then get that category’s ID. I’m assuming that this is lighter and quicker than trying to move up the hierarchy like I did with the pages.

The widget then uses this function to get the category structure. On category overview pages, I use this code.

$cat_ID = get_query_var('cat');
$topCat = rt_getTopCategoryID( $cat_ID );
wp_list_categories( 'title_li=&child_of='.$topCat );

On single post pages, This is what I currently use, but I’ll be the first to admit this needs work. Posts can be in many categories, which can result in all sorts of weirdness. Some editorial restraint will be in order for my client, but the principle works.

global $post;
$categories = get_the_category($post->ID);
$topCat = rt_getTopCategoryID( $categories[0]->term_id );
wp_list_categories( 'title_li=&child_of='.$topCat );

That’s it. My widget now shows the correct menu on single page, post and category pages. There’s probably some room left for improvement, so don’t be shy and comment away.

As some of you may know, Twitter is fading out support for “basic authentication”. This basically means that app developers (like myself) can’t just send a user’s login information to Twitter’s server when we want to send a tweet or change a setting. Instead the application needs to be “authorized” by the user using a process called oAuth.

For Snapatar, this meant I needed to make a lot of changes. OAuth is far from trivial to implement, and I was lucky to find a library that handles most of the complicated stuff. With it, I was able to get oAuth working on snapatar.com, and beat the August 16 deadline.

Unfortunately, I messed up when I put the new version live. I forgot to update a setting in Twitter’s app registration system, causing the oAuth process to fail. But that has been fixed now, and you’re welcome to give the new authentication process a try. Currently, there’s absolutely no error handling, so you may run into an occasional poorly formatted error message if something failed. Most of the time however, it should just work.

I’ve been promising a new version of WP-Cumulus for a long time. I’ve tried working with more experienced PHP developers, but it’s been hard to find a really good one who’s able to devote time to the project. I still think a plugin like this should be a team effort, but for now I’m going to kick things back into motion again myself.

What’s ready at this point is a much cleaner rewrite of the plugin files, with the display logic in a neat little class that port authors will hopefully be able to reuse. I’ve also got a Flash movie that uses a user-defined system font, as a result is much smaller, and supports unicode tags.

Burning bridges

I’ve decided to bump the required WordPress version to 2.8 or 2.9. There’s so much code in the current version that’s there only to support older versions and adds nothing. Running older WP versions is a bad idea anyway, and I want to use the new widget and option page APIs.

Another thing I consider a bad idea in hindsight is the “compatibility mode”. It way helpful for debugging WP-Cumulus on blogs with poor markup, but I’m going to trust that SWFObject 2.2 does a better job and once again skip all the extra code required.

Lastly, to support unicode, your blog’s visitors will need Flash Player 10.

Security

Now that I have the main two parts (plugin and Flash movie), I need to hook the two up to each other. The basic idea behind how WP-Cumulus works has always been that WordPress supplied the tags through its wp_tag_cloud function. It was easy and convenient to simply pass that function’s output through to the movie using the “flashvars” interface.

However, as some experts have found, the technique of passing URLs through flashvars, while extremely common among Flash programmers, poses a security risk. Versions 1.22 and 1.23 pathed the biggest holes, but there’s still a very eloborate social XSS that could pose a risk to Cumulus users. Another issue is that some themes alter the output of wp_tag_cloud through an API hook. This is fine for the html tag cloud, but for WP-Cumulus it means my Flash movie doesn’t get the data as it expects it.

This means I’ll have to rethink the flow of data, and as a result, the movie’s technical interface is going to be radically different. I’m thinking along the lines of having the movie request its content from a fixed, relative url, and using JSON instead of XML. I know this also affects the authors of ports to other systems, but my primary concern is the WordPress community.

ASAP

There are lots of things that still need to be done. Like i18n, the data interface and better alternate (“no-flash”) content. I’m really committed to getting a completely rewritten version of the plugin out there as soon as possible, but I also want to make sure it’s stable. Think weeks, at least. There’s not a single line of code in the new version that I copied from 1.23, so it’ll need extensive testing.

I used to be a real nitpicker when it came to preparing images for the web. I’d laugh at people using large images in web pages, showing them in a smaller format by setting the width and height properties.

In the days before broadband was everywhere it was bad karma to do this, because a large image file would take a long time to download. You needed to prepare the image at the size you were going to be displaying it. Nowadays, things are a little different.

A client asked me recently to propose a new layout for a page that had a fixed grid. Unfortunately, their CMS could was limited to a couple of image sizes that were a complete mismatch with said grid. So I used CSS scaling to get them to fit. Unfortunately, the client wasn’t convinced this was a feasible technique to use. That’s why I did a few quick tests to see if using scaled images in a web page would slow down rendering.

A quick test

I created a page with 150 random images on it. Fifty of them were 24bit PNGs, another fiftly were JPEG and the rest were 8 bit GIFs. Next, I created a copy of that page and set the CSS size properties for the images to a lower number, scaling all images to 61.5%. I then used Google’s Speed Tracer extension for Chrome and Yahoo’s YSlow for Firefox to see if there would be any difference in page load and render times.

No difference whatsoever

The results were pretty clear. Even with 150 images on the page, there was absolutely no difference in page rendering times in Chrome. Both pages finished rendering in around 4:10 seconds. In Firefox, the results were much more erratic, but both pages averaged at around 6.5 second. In both cases I didn’t worry about caching, since I was interested in differences in rendering speed, not download speed.

So there you have it. It may still not be 100% good karma, but to overcome design obstacles, using client side scaling isn’t as bad as it used to be. If you need a few images to fit that you can’t prepare or resize on the server, you won’t have to worry about it slowing down your page. However, actually scaling an image usually makes the file smaller, so if you can you still should.

There’s been a lot of controversy over Apple’s decision to ban Flash (and Java for that matter) from the iPhone since the day it was released. Now, with the iPad about to hit retail, there’s been more debate on whether this was a technical decision or not, and whether it’s a severe limitation for the devices, or a blessing. Being both a Flash developer, an iPhone OS user an open source advocate, I thought I’d weigh in on the conversation.

Before I get started though, let me point out that I’m not a fan of Flash. I think it’s a real shame that there’s no open, official standard that lets web designers do the things Flash can. Adobe has the web in an awkward stranglehold right now, and I’d love to see that change. But the reality is that Flash is an integral part of the web today.

HTML5 isn’t an option just yet

One of the main uses of Flash on the web is video. People keep forgetting however that Flash is also used extensively for other things. It is the only technology available today that allows you to scale, rotated and distort objects. It has a 3D engine (which admittedly isn’t used widely, yet) and it offers the most advanced controls over typography of any tool in a contemporary web designer’s toolbox.

Flash is used in product demos (360 views), simulations, games, data visualizations and many other areas where HTML falls short. Perhaps the upcoming release of HTML5 will allow designers to do the same things without Flash, but until HTML5-supporting browsers are widely adopted, Flash is the (only) way to go. Especially since most of the HTML5 demos I’ve seen have been built using browser-specific (non-standard) functions and were nowhere near a smooth as Flash animation has been since 1996.

And as for video, HTML5 appears to have a long way to go before it can replace Flash as the web’s preferred video player.

There’s no fundamental issue with Flash and touchscreens

This blog post has been getting a lot of attention, and rightfully so. It clearly describes why some currently available Flash content won’t work very well on touchscreen devices like the iPad. However, the types of applications that Flash is often used for, especially games, have always needed different approaches for mouse pointer based devices and touchscreens. Whether they were developed using Flash or not. Flash allows you to accommodate both interaction models, and it’s no problem at all to create touchscreen interfaces in Flash.

Flash is not buggy, slow or overly power-hungry on other devices

Steve Jobs himself has said that Flash on the iPad would kill its battery life. And I’m sure it could. It’s very easy to create a Flash movie that uses every single CPU cycle available on whatever machine it runs on. But like with all other development platforms, that’s just bad programming. Flash is capable of techniques like bitmap caching which can reduce CPU utilization dramatically. And the soon to be released 10.1 version will be capable of outsourcing most of the remaining heavy work, like decoding video, to the systems GPU. Which is probably what the iPhone’s video player does too.

I’ll admit that the current Flash player is slow (by comparison to Windows) on OSX and Linux. It’s obvious that Adobe has not always maintained these players very well. There’s been debate over whether or not Apple is partly to blame for this, but fact is that the Mac version uses ten times the resources the Windows version needs to display the same content.

That being said, on ARM based sytems (like the iPhone and the iPad), things aren’t quite so bad. I get the feeling that many of the users commenting negatively about Flash as a technology are Apple fans who’ve not been getting the performance and stability that Flash delivers on Windows.

A business decision?

I’m convinced that Apple’s ban on Flash is purely a business decision. Allowing Adobe’s technology onto their devices would in turn allow content (music, video, games, etc) to be delivered to the devices without going through Apple’s immensely successful App Store. No matter how much Adobe would improve Flash’s performance and stability, it still wouldn’t make sense for Apple to change their minds. Not with billions of dollars coming in.

On a side note, Adobe has announced that the next major version of the Flash development environment will allow Flash applications to be exported as iPhone apps. So there will be Flash on the iPhone, just not in web pages. For me, the most interesting thing about this is that it will reveal whether Flash is really as bad as Jobs says. I wonder if those apps will drain battery life and crash frequently. If they don’t, that will tell us a great deal about Apple, won’t it?

(Read this post in Belorussian at PC)

The templating system in WordPress is very flexible, and there’s rarely something you can’t do or that doesn’t work as you’d expect. A notable exception however is the_date. Its purpose is simple enough. It displays the current post’s date of creation. But on pages with more than one post (such as on many blog home pages), something weird happens. If a number of posts on any given page were created on the same date, the_date will only show that date for the first of those posts.

In the early days of blogging, posts were usually listed by date, much like a regular, paper diary. In the old default theme that comes with WordPress a big date title is used to separate posts into days. That’s what the_date was created to do, and so it makes sense it only displays the same date once. In most modern themes however, people like the date to be among the meta data for each article, so the_date falls short.

the_time

In comes the_time. This template tag, as the name suggests, shows the time at which a post was created. However, it accepts a PHP time format string as an argument, and can be made to display the date. You could simply put a date formatting string in there and be done with it, but I like to keep things flexible, so i wanted to use the date format string set in WordPress’ settings. That way the user controls the output, and it can be adjusted to international preferences.

When I first ran into this I posted my issue on the WordPress forums, and Otto42 came up with a prefect solution. I’ve been using it ever since and thought I’d share it here.

the_time(get_option('date_format'));

What this does is get the user-set date format from WordPress and feed it to the_time. Since that function doesn’t have a ‘once a day’ limitation, you can use this as often as you like in your theme.