Several websites have reviewed WPSSO in the past few months, and the reviews are all very positive…
“If you want to make every tweet, like, share, pin, and +1 count, then you should definitely start using WPSSO on your WordPress site.” — indexwp.com
The WPSSO and NGFB plugins for WordPress are licensed based on the WordPress Site Address. Typically, a Development, Staging, and Production website – for example – would require 3 licenses. In the spirit of helping our fellow developers, we are offering a free license for every license purchased – on all past and future purchases. So, for example, if you purchased a license for example.com (or www.example.com), you can also register dev.example.com using the same Authentication ID. This allows developers to purchase a license, develop a customer’s website, and then change the Site Address upon delivery, without having to purchase an additional license for the production website.
There is a huge variety of available plugins for WordPress — 30,326 plugins as of today — and if you’ve tried more than a few, you’ll have noticed a marked difference in their quality as well (functionality, user interface, stability, etc.). If you know your way around PHP, you should take a moment to browse the source code of a plugin before installing it. You’ll notice quite a difference there as well. ;-) You can view WPSSO’s source code directly from WordPress.org’s SVN repository. If you do, please excuse the lack of comments — it’s on my To-Do list. ;-)
I’ve always kept an eye on performance, and used WordPress’s object and transient caches when possible, along with disk based caching when appropriate. NGFB and WPSSO are fast, but until recently, I’d never compared their performance to other plugins. As I prepare WPSSO v2.4.4 for release later this week, I took some time to double-check its performance and that of a few other plugins as well.
If you are concerned about the quality of your NextGEN Gallery v2.x resized images, this should be of particular interest to you.
Some months ago I contacted Photocrati to ask them how, in version 2.x, developers could retrieve the “actual” dimensions of a resized image. In the past, after resizing an image we could use PHP’s getimagesize() function on the resulting file, but in v2.x image resizing is dynamic and those resized images may not be available on disk. I had some concerns between the expected / calculated image dimensions, those returned by NGG v2.x’s methods / functions, and the actual image retrieved by the URL. All 3 dimensions were different! A resized uncropped image which should have been 300x200px, was reported as being 300x199px by the NGG methods / functions, and the image retrieved by URL was 298x199px!
This may not sound like much, but a few pixels here and there can lead to image distortion when rendered by browsers, alignment issues in page layouts, and failures when working with minimum image dimensions (for example, Facebook ignores images smaller than 200x200px).