Shashin’s popularity has recently spiked, which makes me happy, but it’s also caused a spike in support requests (my last Shashin post has 127 comments). Until the start of this year, I had been diligent in providing support, but my day job recently has been seeping into my nights and weekends, significantly reducing my availability. It’s likely to stay that way for the next several months.

I started on some major enhancements to Shashin early in the winter – most notably flickr and twitpic support – but it’s been on hold for a while now. At this point, my guess is that it’ll be summer before I can get back to it.

Please use the comment section on this post for support questions. I will do my best to provide responses twice per week. I will most likely not be able to delve into problems that involve the particulars of your server configuration, such as problems with connecting to Picasa via curl for unlisted albums (as those kinds of issues can sometimes take hours to work through). But general usage questions and Highslide issues are usually easier to address, and I’ll do what I can to help out.

Thanks everyone for your patience, and please remember I’m doing this for free 🙂 (donations come in very rarely).

UPDATE: I just posted a minor update, version 2.6.3:

• Shashin is now compatible with WP 3 beta 1 (WP 3 appears to automatically unserialize options, which was causing errors)
• Added support for child themes
• Can now uninstall and delete Shashin from the main plugin page (added uninstall hook for existing uninstall function)

Shashin 2.6 is now available for download at wordpress.org. I figure the end of the world is a good time to release a new version. Here’s what’s new:

• Added support for unlisted Picasa albums (finally!). You must have the PHP curl extension installed to use this feature. I believe most PHP installations include curl, but some hosting providers may need you to ask them to enable it for your account.
• Added ability to group albums by Picasa user accounts when using the [salbumthumbs] tag.
• Bug fix: the EXIF support introduced in Shashin 2.4 caused an error when syncing albums in the Windows version of mySQL. Many thanks to MC for letting me debug this on his Windows server.
• Bug fix: Shashin’s automatic album syncing was interfering with scheduled jobs from other plugins in some circumstances. This is fixed. Note that you also need WordPress 2.9.1 or higher, as this was related to a wp-cron bug in WordPress 2.9.

Also, I’ve installed the Subscribe to Comments plugin, so if you have a support question, you can get an email notification when I reply, instead of having to remember to check back.

UPDATE: I’ve made a couple bug fixes: v2.6.1 fixed another bug related to Windows servers, and v2.6.2 fixed a bug related to Google servers outside the US (see this comment for details).

Shashin 2.5 is now available for download at wordpress.org. This actually isn’t the major release I’ve been working on – it doesn’t include Flickr and Twitpic support (that’s still a work in progress). But it does include one very cool new feature: a jQuery based WYSIWYG browser for adding Shashin photos to your posts. You can now browse albums from within the editor, and click on photos to add them to your post (it will write [simage] and [sthumbs] tags for you). To use it, click the Picasa icon in the editor’s media button bar. This great feature was contributed by Sune Pedersen.

A couple usability items to point out with it:

• If you mouse over a thumbnail on the left hand side, then the right hand side will show you a larger version of it, and vice versa. I found this a little confusing at first, but it’s actually a good way of using the available screen real estate effectively
• To select a photo, just click it once. Don’t try to drag it. After you click it, you’ll see it appear under the “Selected” heading. If you change your mind and need to remove a photo that you selected, just click it, and it will be removed from the “Selected” area.

The other important new feature is that automatic album syncing is now done every 10 hours instead of once daily. This is because Picasa video URLs now expire every 11 hours, as I described previously. If you have any videos in your albums, then you will want to turn on this feature in the Shashin Settings menu.

There are also two bug fixes:

• “Next” and “previous” links for browsing album photos now work in Google Chrome and Safari (this is actually a workaround for a webkit bug)
• Album title links in the album thumbnails sidebar widget now point to the correct URL

Now back to work on version 3.0…

Sometime over the past month, Picasa made an unannounced change to how it serves videos. Previously, the Picasa RSS feeds provided URLs for videos, and those URLs worked indefinitely. Now the URLs in the RSS feeds expire after 11 hours. So if you add a video to a Picasa album, then sync the album in Shashin, it’ll work fine for 11 hours, and then it won’t work anymore. To make matters worse, re-syncing the album won’t help – Shashin doesn’t check the feed for a URL change when deciding whether to update its records, since the URLs used to never change (Shashin doesn’t just blindly update all its records when sync’ing; it checks certain fields, and then updates only if one of them changes, in order to keep sync’ing relatively fast).

The expiration time is built-in to the new video URLs, and the videos won’t play after that time passes, even if you’re logged in to Picasa. This leads me to believe that using the Picasa API wouldn’t help (even the code used to display the videos on Picasa’s own pages expires). There’s also a signature key built-in to the URL, so there’s no simple hack to the URL that’ll make it last longer.

The ability to embed videos in your own site was never a documented Picasa feature, so I really don’t have grounds to complain. But I made it a feature of Shashin, so my users do 😉 .

I’m traveling over the holidays, but I will try to get a fix released before New Year’s. The only solution I can think of is to change Shashin’s automatic once per day sync’ing feature so that it will sync every 10 hours (an hour before the expiration, to be safe). That way you’ll always have a fresh URL for embedded videos. This won’t be the major new release I’ve mentioned before – it’ll just be a fix for this and a few other minor bugs.

Note: videos added to Shashin more than a month ago still work fine, at least for now. The “old style” URLs in Shashin are still working, and – like I said – they don’t get updated when you sync. It’s only videos you may have added to Shashin within the past month that will give you a problem.

Use this post for support questions about Deko Boko, Koumpounophobia, or Post-to-Post Links II.

I just posted a minor upgrade to wordpress.org for Koumpounophobia, which fixes a CSS display issue with the dialog editor. Also, Koumpounophobia and Post-to-Post Links II now include Russian translations, thanks to Fatcow. And Deko Boko has a new Italian translation, thanks to Raneri web design.

Update: I’ve written a new Shashin post, so this thread is now closed.

My last Shashin post has about 60 comments, so it’s time for a fresh thread.

I’m back to work on the new version. It’ll include Flickr and Twitpic support, and a WYSIWYG interface for adding photos to posts. I only have at most a few hours a week to work on it though, so look for it around late January.

I’ve been coding all my plugins in PHP 4 to make them as compatible as possible with the wide variety of hosting environments out there. But I’ve been eager to make use of PHP 5’s features, especially its greatly improved OO features. PHP 4 reached its end-of-life over a year ago (which means no more enhancements, and no more security fixes). My impression is that the great majority of hosting providers have upgraded to PHP 5 since then, and WordPress 3.0 is expected to require PHP 5 for some features, so future versions of my plugins will make use of PHP 5 only features.

If you’re writing a plugin in PHP 5, it’s important to write it in such a way that it fails gracefully if someone tries to run it in a PHP 4 environment. This is because:

1. There are still people using PHP 4.
2. While you can – and should – make a prominent note in your readme file and on your website that your plugin requires PHP 5, many people will inevitably overlook it (when reading online, people – including me – generally notice only what they’re looking for, not what you want them to notice).
3. PHP 5-specific code can cause hard failures when run in PHP 4, making users frustrated, and making you frustrated when they email you with their frustrations.

The best place to check for compatibility is during plugin activation. But WordPress performs plugin activation in a separate process, making it difficult to communicate anything back to the user. Brian Krausz solved this problem, and my solution for safely checking PHP compatibility builds on his work.

If you are only using functions introduced in PHP 5, then you can use Brian’s code and incorporate a function_exists() check for one of them in your activation function. But if you’re using language constructs introduced in PHP 5 – like protected properties or abstract classes – then they can’t be in the same script as the one containing your call to register_activation_hook(). This is because the script will fail to parse in PHP 4, and the user will get a syntax error message (it won’t be at all obvious to the untrained eye that it’s failing because it requires PHP 5).

My solution is a PHP 4-safe “boot” script for my plugins, which loads my class files written in PHP 5 only after it confirms that it’s safe to do so. Here is what I have in the update I’m working on for my Shashin plugin:

register_activation_hook(__FILE__, 'shashin_activate');

if ($_GET['action'] == 'error_scrape') {
    die("Sorry, Shashin requires PHP 5.0 or higher, and mySQL 4.1 or higher. Please deactivate Shashin.");
}

function shashin_activate() {
    global $wpdb;
    $mysql_version = $wpdb->get_var("select version()");

    if (version_compare(phpversion(), "5.0", "<") || version_compare($mysql_version, "4.1", "<")) {
        trigger_error('', E_USER_ERROR);
    }

    else {
        require_once(dirname(__FILE__) . "/Shashin.php");
        $shashin = new Shashin();
        $shashin->install();
    }
}

if (version_compare(phpversion(), "5.0", ">=")) {
    require_once(dirname(__FILE__) . "/Shashin.php");
    $shashin = new Shashin();
}

A few notes:

• version_compare() can be used to compare version numbers generally, not just PHP versions. Shashin requires mySQL 4.1, so I’m checking for that too.
• There is an ongoing cost to this approach: every time your plugin is run, it does a version_compare and a require_once. I haven’t benchmarked it, but I’d be surprised if it caused any noticeable performance difference.
• Savvy programmers generally recommend checking for the existence of the functions you want to use rather than checking language version numbers. I agree when it comes to client-side languages like JavaScript, where it can be difficult to anticipate all the environments your script might encounter. I think it’s less of an issue with server-side languages, and in my case I’m not using a particular PHP 5 function. I’m using PHP 5 language constructs such as abstract classes.

I had to test this a few times live on Twitter before I got it working. I deleted the incorrect entries right after making them, but they still showed up in feeds – sorry if they seemed like spam.

The short URL link that shows up for this post in Twitter is hosted on toppa.com, not bit.ly. Why give SEO love to bit.ly when you keep it for yourself?

I’ve been using Alex King’s Twitter Tools plugin (version 2.0), which automatically tweets my new posts. The full URLs for my posts always exceed Twitter’s 30 character limit for links, so Twitter automatically shortens them to bit.ly redirect links. And I just installed Husani Oakley’s Link Shortcut plugin (version 1.4), which lets you create short URLs on your own site.

So the trick is getting Twitter Tools to use Link Shortcut to create short URLs for your posts. This takes just a couple of edits to the Link Shortcut plugin.

1. On line 63 in the LinkshortcutDataManager.php file (in the addLink method), I changed return true; to return $ident;. This makes it return the short identifier it generated for your post (I checked all the calls to this method, and they check for any positive return value, so – as currently written – this change doesn’t harm anything).
2. In linkshortcut.php, I added the following code starting at line 37:

   // MT - shorten urls from Twitter Tools
   add_filter('tweet_blog_post_url', 'mt_tweet_shortcut');
   
   function mt_tweet_shortcut($url) {
       $LinkshortcutDataManager = new LinkshortcutDataManager();
       return 'https://toppa.com/' . $LinkshortcutDataManager->addLink($url, date("Y-m-d G:i:s"), false);
   }
   

   This takes advantage of the tweet_blog_post_url filter added by Twitter Tools, which lets you use whatever URL shortening service you like. The addLink() method doesn’t return a complete URL, so you have to add your WordPress base URL. The “correct” way to get it is the get_bloginfo('wpurl') function, but in this case I want the URL without the “www.” portion (to save 4 precious characters), so I just hardcoded it.

   The only hitch is there’s no way to pass a custom name for the link to Link Shortcut (the second argument to addLink), so I’m using the current date and time as a name. The admin page for Link Shortcut shows you the full URL for each redirect link it creates, so the name you assign isn’t really that important.

I’ll get in touch with the Link Shortcut author and see if he’s willing to integrate this functionality into the plugin (in a more graceful way than my hack here).