I posted a message in the WordPress.org support forums a couple months ago saying that I was temporarily discontinuing support for my Shashin plugin. I was single-parenting for over a month, and getting ready to move to Japan.

Unfortunately, I now need to say that I’m discontinuing development and support of my plugins for the foreseeable future. I’m living in Japan until the end of the year, working full time, studying Japanese, and enjoying the unique experience of being here with my family.

My work over the last couple years has involved an increasing amount of time with Ruby on Rails, and currently involves little WordPress work. Also, I never developed a business model for my plugins, which means I’ve spent many hundreds of hours over the years developing and supporting them for free. That’s not something I can continue doing.

I’ll keep the current versions available at wordpress.org and they are also available on github, if anyone wants to fork them and continue their development.

The WordPress community has been a fantastic place for me. Because of WordPress I’ve improved my technical skills, made friends, advanced my career, and had the privilege of giving 7 WordCamp presentations over the last few years. So this was not an easy decision. I hope that in the future I’ll have opportunities to contribute to the WordPress community again.

Shashin 3.4 is now available for download at wordpress.org. It has great new features for sharing your photos, and for responsive design (so your pictures will look good on any size display). Check out Post to Post Links II error: No post found with slug "shashin-3-development-progress" to see it in action.

Important upgrade notes:

• This version of Shashin comes with a customized version of prettyPhoto. On the Shashin settings page, you will want to pick prettyPhoto as your viewer to take full advantage of the new responsive design and social sharing features.
• If you customized your Shashin stylesheet (shashin.css) in a previous version and placed it in your theme folder, you will need to update it to incorporate the latest changes in the new version.

New features:

• Sharing: you can now share a link that will take you directly to any Shashin photo on your site, and automatically open it in prettyPhoto. The sharing links appear below the caption in prettyPhoto.
• Mobile display of slideshows: I’ve customized the version of prettyPhoto that comes with Shashin to improve its display on mobile devices (if you are using Fancybox, I’ve disabled it on mobile displays, as it simply doesn’t work very well on them).
• Two thumbnail design options to choose from: one is almost exactly the same as the design Shashin has always used – showing the captions underneath the thumbnails and putting a border around each thumbnail. The other design gives the thumbnails rounded corners, a slight box shadow, no borders, and puts the captions in an overlay along the bottom of the thumbnails. Long captions are truncated, to prevent them from covering the entire thumbnail. You can specify which design you want on the Shashin settings page.
• Responsive design for thumbnail layouts: Shashin will resize and rearrange thumbnails to best match the available space on the page. The final result for a given layout depends on several factors. Let’s say you want to display 3 thumbnails in a single row. If you enter “3” for the columns in your Shashin shortcode, Shashin will try to give you 3 columns. How many you actually get depends on how big the thumbnails are, and how wide the content area is. If the content area isn’t wide enough to accommodate the thumbnails at their full size, Shashin will scale down the thumbnails to about 90% of their actual size to maintain the 3 column layout. After that, it will let the columns start to “wrap,” so the thumbnails don’t shrink too much (that is, the number of columns will go down). If you gradually narrow and then widen your browser window you can see Shashin re-arranging and scaling its thumbnails on the fly.

Implementing responsive design for Shashin was a real challenge. This is because the traditional tools for responsive design – media queries – are not helpful with Shashin. Since Shashin is a WordPress plugin that needs to work in any theme, I couldn’t make any assumptions about the page layout. So basing layout decisions on the display width of the viewing device or the browser window is not helpful. What I need to know is the current width of the HTML element Shashin happens to appear in, which could be anything. So I implemented Shashin’s responsive design with a mix of CSS and jQuery.

Please post any support questions in the wordpress.org support forum for Shashin, not here.

The beta version of Shashin 3.4 is ready. It has a lot of front-end design changes, which means its needs testing in a variety of browsers. So if you’re comfortable installing WordPress plugins manually, please download the beta version from GitHub and give it a try (important note: rename the folder after you unzip it to “shashin”). It especially needs testing in everyone’s favorite browser, Internet Explorer. Note since this isn’t a normal upgrade through the wordpress.org repository, you will need to deactivate and re-activate Shashin to update its settings.

The biggest new feature is responsive design. This was quite a challenge: since Shashin is a plugin that should work with any theme, the thumbnails it displays need to be responsive to their containing element (the <div> containing a post). This means I can’t just rely on media queries, as they require knowledge of the entire theme layout. So the first thing to note is that if your theme isn’t responsive, Shashin won’t be either. If your theme is responsive, Shashin thumbnails will shrink as the available width decreases. I also tried to find a happy medium for honoring the number of columns you specify for displaying your thumbnails. The rule I’m applying is this: if the thumbnails shrink to less than 80% of their intended size, then the columns will “float”, meaning that the number of columns will go down as the page gets narrower. Also, Shashin detects browser resizing, so you can expand and contract the width of your browser to see how Shashin responds.

Captions now overlay the bottom of the thumbnails, instead of appearing below them. A rule I’ve applied to displaying captions is that they will not appear if they would cover more than 30% of the image.

I’ve improved the browsing experience when you are paging through albums that contain a large number of photos. The “previous” and “next” links will scroll you to the top of the next thumbnail set as you page through them. I’ve added the navigation controls to the bottom as well, which several people have requested.

There are various other updates as well. The complete list is in the Change Log in the readme file.

Please use the comments section on this post for any feedback.

In his recent post The Dire State of WordPress, James Shakespeare predicted doom for WordPress if it doesn’t undergo radical architectural change. Henri Bergius followed up with a similar argument in Why WordPress needs to get Decoupled. I appreciate where they are coming from: I can say without hyperbole that Bob Martin’s book Clean Code changed my life (I even had him sign it for me), but as a WordPress developer, I can also say the approach they’re taking is counter-productive.

Bergius advocates rewriting WordPress into multiple, separate software components, and Shakespeare calls for “…a fundamental rethink of the entire platform. We’re talking thousands of man-hours for no direct financial reward… But this doesn’t mean it couldn’t or shouldn’t be attempted.”

There are three big problems with thinking about it this way:

1. Chasing the “grand rewrite in the sky” is typically a recipe for disaster. Being aware of this is a tenant of the Agile approach, where “the boy scout rule” is preferred (leave the code better than you found it, by making continuous incremental improvements). Here’s Bob Martin describing what happens when you have a team still maintaining the old code on a project (since you can’t just abruptly abandon it), and a “tiger team” working at the same time on the grand re-write:
   

   Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does. This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.

2. Check out Yoast’s infographic on WordPress’ popularity: 72.4 million sites running WordPress, and 20-25% of all new websites are using WordPress. There are over 19,000 plugins in the wordpress.org repository and over 1,700 themes (with probably thousands more not in the repository). With that kind of user base, backwards compatibility and stability take precedence over everything else. Therefore, architectural change must be gradual, low-risk, and backwards compatible.
3. When you’re not actively involved with WordPress, and you’re telling people who live and breathe WordPress development that what they’re doing is awful, it’s hard for that to not come across as antagonistic, and therefore be unproductive. There is a huge community of developers and designers who make their living coding for WordPress, and really enjoy it. While feedback and guidance from outside the community can and should be welcome, one-off prognostications of doom at some vague point in the future are likely to be met with a shrug.

Having said all that, there are some things they’re right about, and there are a couple practical steps forward I’d like to recommend:

1. Bergius observes that he doesn’t see WordPress developers at non-WordPress conferences, and relates a similar observation from Symfony activist Lukas Smith. This fits my experience as well. I see a very real gap between the WordPress development community and the mainstream object-oriented coding community. The WordPress community is big enough that it can get away with being insular – probably every major city in the US (not to mention the rest of the world) has a WordPress meetup group and an annual WordCamp. I’ve spoken at several WordCamps, and a common reaction to my talks is that people are intrigued, and sometimes mystified, that my talks are about various aspects of how to shoe-horn object oriented design into WordPress plugins. I also attend the Philadelphia ETE conference every year, which is the annual tech event in Philadelphia, and I’ve attended various Agile conferences in other parts of the country. Developers in Java, Ruby, C++, JavScript, Scala – you name it – they’re all there, attending each others’ sessions and learning from each other. I’m a gregarious guy, and I have yet to meet another WordPress developer at any of them.

   I can’t speak for other cities, but Philadelphia has meetups for PHP, DevOps, JavaScript, blogging – you name it. There are well over 100 different tech meetup groups in the greater Philadelphia region. And there is interaction between groups, such as the annual RedSnake Philly event that brings together the local Ruby and Python communities. The WordPress meetups are fantastic, but if you’re a WordPress developer, consider getting involved in the broader community. There’s lots of good stuff out there!

2. One of the reasons WordPress is so successful is that it’s such a great platform for hacking. You don’t need a degree in computer science or years of experience to get started with it, and once you learn some basic techniques and WordPress best practices, you can be productive and successful with it. So even if a huge rewrite was a practical idea, it would be a really bad idea to introduce an architecture with many layers and abstractions, as it would make the barriers to entry too high (and if someone wants to use a full fledged web development framework, then they can use a framework – WordPress doesn’t need to become one).

   However, I strongly feel that the WordPress architecture needs to become more open to modern object-oriented design practices. In my previous position at the University of Pennsylvania, I hired many developers, and interviewed some who primarily had WordPress experience, and it did not prepare them well for working outside of WordPress. They had acquired habits they needed to un-learn. I’m talking about routinely using global variables; using classes only as giant buckets of vaguely related functions; using constructors for more than just initialization; etc. As far as I know, these are design practices you really don’t see anymore in well-established development environments, except WordPress.

   The WordPress architecture forces awkward design choices for developers trying to take an object oriented approach. It drives them to use Singletons to deal with all the global state (a choice I can understand but disagree with). It requires a laborious setup to do automated testing (and even after you set it all up, you still can’t do unit testing – you’re doing integration testing). In general, it forces a style of development that is very particular to WordPress, as opposed to an architecture independent style that can be commonly applied to other modern development environments.

   The complaint that learning object oriented design is too hard or not worth the trouble doesn’t make sense to me. WordPress developers learn all kinds of arcane and complex practices to be successful with it. Why not instead make WordPress more compatible with mainstream development practices? Then learning those practices will allow you to be successful with more than just WordPress.

   I understand how and why WordPress evolved the way it did, but I haven’t yet heard a compelling reason why the approach taken to its architecture should forever remain apart from the practices of the mainstream development community. Backwards compatibility can be provided while gradually shifting the organization of the core code.

   The key step that needs to be taken is providing better encapsulation. Here’s a simple example in PHP for moving away from globals but still providing backwards compatibility (more than just that would be needed to getting a handle on all of WordPress’ globals, but with some planning it should be feasible). For hook and filter functions, they could become thin wrappers for instance methods (through the use of an injection container you can avoid unneccessary re-instantiation of objects). Doing these two things would provide backwards compatibility (so nothing breaks, and hackers can still hack), and at the same time would open the door to decoupling, real unit testing, and object-oriented design (without needing to argue about Singletons).

The WordPress community is big and vibrant. Philly WordCamp 2011 was the first WordCamp I attended, and I was thrilled by all the energy and enthusiasm. But from what I can see, WordPress has isolated itself, both as a community and as a web development environment. I don’t see a benefit for anyone in perpetuating this situation, and I see lots of potential benefits for WordPress joining the mainstream development community.

I’m speaking at WordCamp Nashville in a few weeks, where I’ll touch on some of these topics, and I’m happy to discuss this further with anyone interested.