Shashin 3.1.5 is now available at wordpress.prg. Also, I have updated the Shashin documentation to cover using it with Fancybox (the photo viewer now included with Shashin).

Shashin 3.1.5 is a maintenance release with the following improvements:

• Improved installation and activation process (manual re-activation is no longer needed when upgrading, and the dependency on Toppa Plugin Libraries is handled more smoothly)
• Ability to disable Shashin’s Fancybox if you already have your own Fancybox plugin installed
• Improvements to album synchronizing, for handling slow connections and servers with misconfigured SSL settings (which is surprisingly common)

People arriving for the start of WordCamp Nashville, at Watkins College View at Picasa People arriving for the start of WordCamp Nashville, at Watkins College21-Apr-2012 09:55, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.033 sec, ISO 320	My dependency injection talk at WordCamp Nashville (photo by Patricia Melton) View at Picasa My dependency injection talk at WordCamp Nashville (photo by Patricia Melton)21-Apr-2012 00:56, Canon Canon EOS 40D, 4.0, 70.0mm, 0.017 sec, ISO 1600	@rfair presenting "Less, JS, and WP" View at Picasa @rfair presenting "Less, JS, and WP"21-Apr-2012 16:07, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.04 sec, ISO 400
The Otto and Nacin show - @otto42 @nacin View at Picasa The Otto and Nacin show - @otto42 @nacin21-Apr-2012 12:09, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.033 sec, ISO 250	@ryngrn presenting "Child Theme Frameworks" View at Picasa @ryngrn presenting "Child Theme Frameworks"21-Apr-2012 11:06, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.033 sec, ISO 400	@studionashvegas presenting "The Blank Screen: Overcoming Fear of Pressing from Scratch" View at Picasa @studionashvegas presenting "The Blank Screen: Overcoming Fear of Pressing from Scratch"21-Apr-2012 10:11, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.025 sec, ISO 400

I’ve traveled coast-to-coast across the US 4 times, but until this past weekend I had never been in the South (except for a brief visit to UVA many years ago). I was in Nashville for only 48 hours, and I enjoyed every minute of it. The first thing I noticed was how kind and polite everyone is. The driver of my shuttle bus from the airport pointed out all the sights as we drove into town, and he seemed genuinely interested in what everyone on the bus was planning to do that weekend. I spent the day on Friday with my friend Caryn, who I hadn’t seen since we finished grad school 16 years ago. She showed me around town, and it was great to catch up.

This was Nashville’s first WordCamp. The organizers did a great job pulling it together, and they clearly had a lot of local talent to draw upon for their speakers. Coming from Philly, I think I was the only Yankee among the speakers – I felt honored to be included (Nacin, coming from DC, is a borderline case ).

I was in the developers’ track all day. The first two sessions were design focused, and here’s an excellent summary of both presentations. They were followed by the Otto and Nacin show. They are both deeply involved in the development of WordPress, and they gave a preview of features in WordPress 3.4. Their talk was the most popular of the day in the developers’ track.

I was up next after lunch, and my talk went well. It was an advanced topic (dependency injection) so I drew a smaller crowd. But I got some good questions towards the end, and some good tweets:

View at Picasa @rfair's tweet about my session29-Apr-2012 19:40

Here is a non-technical summary of my talk.

Russell Fair wrapped up the day, and he did a great job of sharing his experiences using LESS with WordPress.

I didn’t get to see Joel Norris’ WordPress bootcamp presentation, but from what everyone was saying, I believe he gets the prize for having the most popular session. He stayed in character as a drill sergeant for almost the entire session. And he was in costume – here’s a photo.

The speakers dinner and the after party were both a lot of fun. I learned a lot chatting with Otto and Nacin, made some new friends, and my friend Caryn was able to come too, so it was a great evening.

If you want to read more, WP Candy has a great review, and they also have links to many of the presenters’ slides. There’s also a great photo pool on Flickr. Here are my slides:

@theandystratton presenting "Accomplish it with Core: Galleries, Sliders and More" at WordCamp San Diego View at Picasa @theandystratton presenting "Accomplish it with Core: Galleries, Sliders and More" at WordCamp San Diego24-Mar-2012 11:31, Canon Canon PowerShot SD780 IS, 5.8, 17.9mm, 0.05 sec, ISO 500

@norcross is out of uniform for his presentation "Stay Classy, WordPress" at WordCamp San Diego View at Picasa @norcross is out of uniform for his presentation "Stay Classy, WordPress" at WordCamp San Diego24-Mar-2012 18:26, Canon Canon PowerShot SD780 IS, 5.8, 17.9mm, 0.05 sec, ISO 800

WordCamp San Diego Developer Day, at CoMerge View at Picasa WordCamp San Diego Developer Day, at CoMerge25-Mar-2012 14:35, Canon Canon PowerShot SD780 IS, 3.2, 5.9mm, 0.033 sec, ISO 250

@tweetsfromchris takes on Nicky Rotten's 2.5 lbs. burger challenge (with a gigantic side of fries) View at Picasa @tweetsfromchris takes on Nicky Rotten's 2.5 lbs. burger challenge (with a gigantic side of fries)25-Mar-2012 21:34, Canon Canon PowerShot SD1400 IS, 2.8, 5.0mm, 0.017 sec, ISO 800

This was my second WordCamp, and my first not as a speaker. When I presented at WordCamp Philly last Fall, I was blown away by the positive energy of everyone there (which is one of the things that led to my current position with WebDevStudios). WordCamp San Diego was just as much fun, and there was plenty to learn too. Coming from Philly means it’s a long way to go for a WordCamp, but WebDevStudios was a sponsor, so several of us from the company went. Since we are a virtual company, I also met a couple of my co-workers in person for the first time – @tweetsfromchris and @TobyBenjamin

WordCamps typically have 2 simultaneous tracks – one for developers and one for users. They also provide an opportunity for these two parts of the WordPress community to come together, so online businesses can find good developers, and for developers to find rewarding projects.

I stayed in the developer track for all but one presentation, and they were all excellent. WebDevStudio’s own @williamsba presented on how to configure and use WordPress multi-site. Even in the more introductory-level sessions, where I thought I’d already know everything, I actually learned a lot. The vibrancy of the WordPress community, and the dedication of the speakers, who appear without compensation, continues to impress me.

The “spring training” theme was really well done, from the matching baseball jerseys for the speakers, to the web site, stickers, and, of course, the cake. @norcross gave his whole talk as Ron Burgundy (yes, in his boxers), which was hilarous enough to justify him being the only speaker out of uniform.

The after party was a blast. It was my first experience where it was socially acceptable to both drink and have endless conversations about code and WordPress. I have found my people and it was great to meet @housechick, @jaredatch, @matthewjcnpilon and @i3inary.

The 2nd day of the conference was a developers’ day, held at the very sleek Co-Merge workplace. This was similiar to the developers’ day at WordCamp Philly, with some short presentations, but the focus was more on people making connections and helping each other code.

The one challenge for me was sleep. WebDevStudios rented an apartment since several of us were there. The first night there was a party happening in an adjacent unit, and the thumping bass didn’t stop coming through the floor until about 3AM. The next night someone was shot and killed right outside our apartment, and the last night one of my co-workers had to get up and leave really early for his flight. But I’m not so old (yet) that I can’t handle it (actually, having kids has conditioned me to handle sleep deprivation better than I did years ago).

My next WordCamp is in just a few weeks. I’ll be speaking at WordCamp Nashville, on how to apply dependency injection techniques to WordPress plugin development.

I took pictures throughout the day – here’s the complete album:

2012 - WordCamp San DiegoMar 23, 2012Photos: 14

Here’s what’s coming up for Shashin:

• Simplifying upgrades: I plan to integrate Plugin Dependencies so Toppa Plugin Libraries will be automatically installed or updated when you install/update Shashin. And I’ve already removed the need to deactivate and reactivate Shashin when auto-updating (this is actually an interesting issue with WordPress’ automatic plugin upgrades).
• A Highslide add-on for Shashin: I plan to make this available outside the wordpress.org repository, but in a way that will stay within the good graces of the GPL.
• Social media buttons: my #1 request is for Facebook like buttons, Google Plus, etc
• Provide the ability to make a Shashin photo the featured image of a post (maybe): I need to confirm this is possible

…And possibly making Shashin more responsive design friendly (if it doesn’t make it in the next version, it will in the following one).

I’ve uploaded Shashin 3.1.3 to wordpress.org. Several people have complained of error messages that start with “Invalid data property __get for…” when updating to 3.1.x. These messages relate to new settings that are added during activation, but they were not actually being added. This puzzled me because the WordPress automatic updater shows a message saying it is deactivating and reactivating the plugin when it upgrades. The problem is, it’s not actually doing it – here is the WordPress defect ticket: Auto update plugins does not activate activation hooks.

Apparently this behavior is an intentional choice. I’ve submitted a patch that corrects the wording (so at the very least, plugin authors like me don’t misunderstand what it means). In the future I will make sure to work around this, but with 3.1.3, you will need to deactivate and reactivate Shashin one more time yourself from the plugin menu after upgrading.

My apologies if you’ve had other difficulties with the recent Fancybox changes. I’ve included Highslide with Shashin since 2008, and I gradually added features and made improvements as I learned the capabilities and quirks of Highslide. Due to a licensing conflict I was alerted to, I had to rip Highslide out of Shashin immediately and switch to a different viewer with a GPL compatible license (Shashin was temporarily removed from the wordpress.org plugin repository because of this). Some of the other great viewers, like PrettyPhoto, are also not GPL compatible, so I went with Fancybox. I had only a short period of time to add it, and I’ve spent many hours recently working through some of the intricate issues involved with making it work with Shashin.

Version 3.1.3 makes the following improvements:

• Added automatic timed slideshows
• Improved captions for photos shown after clicking an album thumbnail (this also fixes the bug with then “return” link for albums)
• In FancyBox caption, show exif data if requested, even if there is no photo caption text
• Bug fix: show correct FancyBox captions on photos shown after clicking an album thumbnail, on pages that have a mix of photo groups and album thumbnails
• Possible bug fix: add a 30 second buffer to the time check when synchronizing albums, in case there is a delay between synchronizing the album’s meta data and the album’s photos (this is to try addressing occasional reports of photo ID numbers changing, which means they are being deleted and re-added).

Also, its worth highlighting that in 3.1.2 I resolved the problem of the Fancybox slideshow navigation controls overlaying controls for videos. The video controls are accessible now.

Update 3/7: I’ve uploaded new versions of Shashin and Toppa Plugin Libraries that corrects the installation bug in Shashin 3.1 that was affecting new installations. You will need to update both plugins.

You can use the comments below for any support questions about my plugins. Please read the Shashin 3.1 release announcement post, as it explains the replacement of Highslide with Shahsin, and explains some of the limitations of Fancybox.

A couple other things to note when installing Shashin 3.1:

• You’ll also need to latest update of Toppa Plugin Libraries for WordPress
• On my own site I got an error on the Shashin settings page after doing the automatic upgrade. Deactivating and reactivating Shashin will solve this problem. Deactivation and reactivation should happen as part of the automatic upgrade, but it didn’t seem to happen for me (the automatic upgrade process is handled through WordPress itself, so I can’t modify it).

Update 3/7: I’ve uploaded new versions of Shashin and Toppa Plugin Libraries that corrects the installation bug in Shashin 3.1 that was affecting new installations. You will need to update both plugins.

Shashin 3.1 is now available for download at wordpress.org. I’ve added support for WordPress multi-site installation, and improved error reporting when there are problems with album synchronization. But the biggest change is that, due to a licensing conflict, I have removed Highslide and replaced it with Fancybox 1.3.4. Highslide uses a Creative Commons license, which is not compatible with the GPL, and all code in the wordpress.org plugin repository must be GPL compatible.

While the visual style of Fancybox is different from Highslide, the functionality is mostly the same. However, there are a few limitations with Fancybox:

• Loading Twitpic photos may be slow. Twitpic URLs for photos redirect to cloudfront.net, and Fancybox is unable to resolve redirects. I added my own code that resolves the redirect before passing the link to Fancybox, but this means two calls for loading every photo.
• Fancybox requires this approach to the code when mixing videos in groups with photos, and this approach if you want to dynamically set the dimensions of a video, and the two are not compatible. I decided including videos in groups was more important, so video dimensions are fixed for all videos (you can set your desired video size in the Shashin settings page).
• A related issue is that the Fancybox overlay for navigating videos in groups overlaps the video controls, which means you can’t pause, adjust volume, etc with videos if they are in groups. This is simply an unfortunate limitation of Fancybox. As of Shashin 3.1.2 this is no longer a problem.

So why Fancybox? Despite these issues it is still one of the more robust viewers available, and it is GPL compliant. Highslide, PrettyPhoto, and even the just released version of Fancybox (2.0) all use GPL incompatible Creative Commons licenses.

Making the transition to Fancybox was a huge effort. I’ll be willing to entertain including another GPL compatible viewer if you can recommend one that doesn’t have these technical limitations, but not right now

Also, to my surprise, Shashin was removed from the wordpress.org plugin repository yesterday. The reason is a perfectly good one – Shashin comes with Highslide, which has a license that is not compatible with the GPL, and all code in the wordpress.org plugin repository must be GPL compatible. I’ve packaged Highslide with Shashin for 4 years, and this issue had simply not crossed my mind.

I will replace Highslide with Fancybox, which is GPL compatible, and then I can make Shashin available again at wordpress.org. I would like to continue supporting Highslide, as neither Fancybox nor most other viewers have the same range of features. But since I can no longer include Highslide with Shashin at wordpress.org, I need to determine if there is an alternate solution that will not cause concern for the wordpress.org folks, and will not make life complicated for Shashin users.

My next week or so is very busy but I will work on transitioning to Fancybox as quickly as I can. In the meantime, Shashin is still available at GitHub. Make sure to read the appropriately named README_GITHUB_IMPORTANT file that contains specific installation instructions when downloading from GitHub.

Update: by request I now have Shashin available for download here as a zip file, with no special steps needed for installation (except that you still need to have Toppa Plugin Libraries installed first). Download Shashin 3.0.9.

Update II: The GitHub version no longer works with Highslide – I’m phasing in Fancybox. Use the link above for Shashin 3.0.9, which is the current stable release (with Highslide).

Update III: I’ve submitted a revised version of Shashin for review to wordpress.org. I have therefore removed the old version of Shashin from my site, as it does not meet wordpress.org’s license requirements.

As a plugin author, all you need to do is write your activation or deactivation function as you normally would, and then:

$functionsFacade = new ToppaFunctionsFacadeWp();
$functionsFacade->callFunctionForNetworkSites('yourActivationFunction');

This will call your activation (or deactivation) function for every site in the network, including the parent site.

Or in an object context, after passing the FunctionsFacade to your object:

$this->functionsFacade->callFunctionForNetworkSites(array($this, 'yourActivationMethod'));

For uninstalling, you need to pass a 2nd argument, which indicates that the “networkwide” flag should not be checked (for some reason, WordPress multisite uses this flag for activating and deactivating plugins, but not for uninstalling).

$this->functionsFacade->callFunctionForNetworkSites(array($this, 'yourUninstallMethod'), false);

I’m going to release the next version of Shashin soon, which uses this method to make it multi-site compatible, so I wanted to get this Toppa Plugin Libaries release out first. Enjoy!

This concern makes sense if you’re assuming plugin code is not very well organized and not very well tested. Unfortunately, that’s a safe assumption with many plugins. As plugin authors, we should have higher standards for our work. There are two things that come to mind:

1. Optimizing the readability and maintainability of our code. This means writing “clean code” (the subject of my Philly WordCamp presentation). It reduces the likelihood of bugs, and makes our plugins easier to enhance and adapt to changing needs. It also makes it more likely that others will contribute to the project, or learn from it, and start writing better plugins themselves. These are some one of the main attractions for participating in the WordPress open source community, right?
2. Optimizing for performance: one aspect of the “clean code” philosophy is to not prematurely optimize code for performance, especially when our guesses about how to do that are often wrong.
   

   More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

   Wulf, W. A. “A Case Against the GOTO,” Proceedings of the 25th National ACM Conference, August 1972, pp. 791-97.

The rule of thumb is to optimize for readability and maintainability first. If a performance problem comes up, it is likely stemming from a small area of the code, and you can focus your performance optimization efforts there. As one person put it: “There is far, far more money wasted on fixing and customizing and maintaining hard-to-read code than there is lost on inefficient code.”

There are many techniques involved with writing clean code. A foundational one is following the Single Responsibility Principle (SRP). Bob Martin has a very succinct definition of the SRP: “a class should have only one reason to change.” In his book Agile Software Development, he explains further:

If a class has more than one responsibility [more than one reason to change], then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the ability of the class to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

If you follow the SRP, then it doesn’t matter how big your plugin is. What matters is how you use it.

The trick, of course, is figuring out what it means to have a single responsibility. WordPress itself helps you figure this out. When you call a WordPress hook or filter, it’s likely that you will want to create a class that implements what you intend to do for that hook or filter call. For example, if you call add_shortcode, then you should have it instantiate a class that implements your shortcode. If that class needs to change, it will be only because your needs for the shortcode have changed. The shortcode logic is not tightly coupled to other parts of the code. Removing that coupling is an important step towards also removing that sinking feeling of fear when you start monkeying with the innards of some gigantic application.

Not every hook and filter call deserves its own class. Some are merely stepping stones to others and do not need their own class. For example, if you call admin_menu simply for the sake of calling add_options_page, one class is enough. Others may need more than one class to support them. But for getting your feet wet, having a class per hook or filter is a good place to start.

My Shashin plugin has a total of 55 classes and subclasses (you can see the code on GitHub). How can you find what you’re looking for in all those classes? It sounds horribly bloated for a WordPress plugin, right? It’s actually the opposite.

A coding habit that goes hand in hand with the SRP is the use of meaningful names. Each class in Shashin serves a specific purpose, and has a name that tells me what it does. If I need to make a change to the settings, I go to the Settings class; if I need to make a change to how album synchronizing is done with Picasa, I go to the PicasaSynchronizer class, etc. The majority of the classes are less than a couple hundred lines. With small, well-named classes and methods with clear purposes, when there is a bug, it’s usually not hard to find. And if I need to change something, I can make that change in one place with a greatly reduced fear of breaking something unrelated.

By using a class autoloader, such as mine, you can also save yourself the trouble of figuring out where to put require_once statements, for loading your class files. With an autoloader, a class file is loaded only when “new” is called (so if you are worrying about performance with so many objects, they are only loaded when they are actually needed). How you keep track of object dependencies, and when and how you instantiate your classes, are what I’ll write about in my next post, which will cover using an injection container.