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 'http://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).

I’m considering adding a new syntax for Shashin’s shortcodes, and I’d like to hear from Shashin users about it. The current format is compact but not easy to remember. For example:

[srandom=3|7|9,288,2,6,n,left]

It’s also not compatible with the newer shortcode syntax that WordPress currently supports and recommends. I’m thinking of switching to the recommended syntax. So the equivalent shortcode for the above example would be something like:

[shashin type="random" albums="3,7,9" size="288" cols="2" count="6" caption="n" position="left"]

The reason I didn’t use this syntax originally is because it’s a lot more typing. So to make the typing easier, I would also add editor buttons, for both the Visual and the HTML editors. There’s a standardized way to add buttons to the Visual Editor already, and my Post to Post Links II error: No post found with slug "koumpounophobia-wordpress-plugin" makes it easy to add buttons to the HTML Editor (having buttons for Shashin was my inspiration for creating Koumpounophobia).

New versions of Shashin would have an option to support the old syntax, so you wouldn’t have to rewrite tags in old posts.

So, if I added the new syntax and editor buttons, would you use them, or would you prefer to keep using the old syntax? Please leave a comment and let me know.

This morning I uploaded minor upgrades for Post to Post Links II error: No post found with slug "shashin-wordpress-plugin" and Post to Post Links II error: No post found with slug "deko-boko-wordpress-plugin" to wordpress.org. The Shashin upgrade adds back the getAlbumList function I inadvertently removed in Shashin 2.3. It provides a non-widget solution for showing a Picasa photo album list in your sidebar. The Deko Boko upgrade offers new translations in Spanish and French, and fixes a small bug in the Settings menu (it would show English as the selected language even if you had picked a different one).

I just upgraded to WordPress 2.8, and Post to Post Links II error: No post found with slug "wordpress-plugins" are working fine with it so far. The only problem I’ve noticed is the headers on the Koumpounophobia modal dialogs are no longer styled correctly, but the functionality is fine. If you notice any upgrade-related problems, please add a comment to this post.

And while I’m here: Shashin was one of five image-related plugins (out of the 285 available at wordpress.org) listed in the Weblogs Tools Collection’s article Five Image Related Plugins for your WordPress Site.

(My blog has been quiet recently as I’ve got a big home renovation project going. I’ll post pictures when it’s done. I may not have the opportunity to blog much this month.)

Beta testing is done, and Shashin 2.4 is now available for download at WordPress.org. The beta version was downloaded 54 times and no bugs were reported. For a description of the new features, see the post announcing the beta version. Russian and Dutch translations are included in the new release. Thank you to everyone who helped with the translations and with testing.

I’m almost done updating Post to Post Links II error: No post found with slug "shashin-wordpress-plugin". I’ve finished documenting the most important new features. I’ll finish the rest in the next few days.

If you encounter any problems or have any questions, please add a comment to this post.

Update 5/29: Beta testing is done, and Shashin 2.4 is now available for download at WordPress.org

Shashin 2.4 has several new features that people have been asking for. It’s available on my site only as a beta release. I’ll upload it to wordpress.org after I get feedback on the beta. If you can contribute a translation, a .pot file is included.

New features:

• Support for image viewers other than Highslide, such as Lightbox, Fancybox, etc.
• Display album photos using the order you’ve set in Picasa.
• Customizable pagination of album photos.
• New settings for customizing Highslide’s borders, navigation bar, and background color/opacity.
• Dynamically set thumbnail sizes and the number of thumbnail columns to suit your WordPress theme (this means you don’t have to worry about images being too large or small if you switch to a wider or narrower theme).
• Show camera EXIF data in Highslide captions.
• Improved usability for the Shashin admin screens, with detailed examples of Shashin tags.
• Align images and groups of thumbnails to the center.
• Specify an alternate image to use as a thumbnail – this is often useful for videos.
• Includes the latest version of Highslide (4.1.4)

Download Shashin 2.4 Beta

Upload the new files, deactivate and reactivate Shashin in your plugins menu, and then go to the Shashin settings page to configure the new features. There’s help text there, which should be sufficient for most of the new features, but a few require more explanation:

• Dynamically setting thumbnail sizes: if you indicate the width of your theme’s content area in the Shashin settings menu, you can use the word “max” instead of specifying a Picasa image size in your Shashin tags. Shashin will then figure out which Picasa image size to use. This is very useful because it means you won’t have to go back and edit all your tags if you change to a wider or narrower theme in the future. For example, if the width of your theme’s content area is 610 pixels, and you use “max” with the simage tag for a single image, Shashin will pick 576 as the image size (the largest Picasa size that will fit in the available space). If you use “max” as the image size with sthumbs, srandom, or snewest, Shashin will do the math to determine the correct size for the thumbnails based on the number of columns you specified. Note that “max” doesn’t work well for photos with a portrait orientation, as the size will be applied to the height instead of the width.
• Dynamically setting the number of thumbnail columns: you can also use “max” to indicate the number of columns in sthumbs, srandom, and snewest. Shashin will figure out the number of columns based on the image size. For example, if you set the image size to 160, and your content width is 610, your thumbnails will be displayed in 3 columns. You cannot use “max” for the image size and the number of columns at the same time. Shashin needs one to be a number so it can calculate the other.
• Centering images and using alternate thumbnails: I actually slipped these in to version 2.3.5, and they are documented here.

The Shashin documentation page is not updated yet for the new features. I’ll update it after version 2.4 is out of beta.