It has been a while since I provided a Suffusion update, with Photonic having consumed most of my development time. However, with the first version of Photonic out of the gates I can now get back to Suffusion.

Contrary to my promise earlier, this release of Suffusion is not small in terms of a change log:

1. The bulk of the changes deal with performance. On the admin page side of things I have cut down memory usage a fair bit and now the back-end is a lot more responsive. On the front-end things were tougher to optimize because already a lot of things were quite heavily optimized.
2. I have also isolated several bits and pieces into separate files – breadcrumbs, menus, site footer, individual post header and footer etc. This will help you override things much easier in a child theme.
3. I have built in some rather nice breadcrumb functionality which is a lot broader than something that just applies to pages. Stay tuned.
4. There are some other small changes to facilitate ease of use/migration.
5. One of the key things mentioned to me in the previous release by a reviewer is that since I am offering the capability to use custom headers and custom backgrounds, I should use the native WP functionality. While custom backgrounds were rather easy to provide, the custom header piece is proving to be a major headache. WP requires you to define a header width upfront, which is not possible in Suffusion thanks to the fact that your page width is fully customizable. I believe this feature can be overridden with a hook, but I have, at this point, decided to give it a rest and revisit it when I have had a good rest. Once I am done with this feature I should be able to release this version.

A full change log will be published once I release the theme, and that will happen as soon as I am done with the native Custom Header Image functionality.

Once I am done with this release it will be back to focusing on Photonic and a new font management plugin that I have visualized. Also, the release after 3.8.3 of Suffusion should have a new skin. I do want to build one that is more conducive for photo-blogging, but I am in two minds whether I should release it as a part of Suffusion’s core or as a separate child theme. Right now the child theme route is looking very tempting, because that way I don’t have to burden Suffusion’s core.

Folks familiar with the WordPress universe are probably aware of a major vulnerability that was discovered in TimThumb recently. For others, TimThumb is an image resizing script that is very popular among WP theme developers who like to offer that extra bit of customization to users. When the WP team was made aware of the exploit they immediately suspended all themes in the WP repository that had TimThumb and sent a message to the authors to fix the themes.

In fact, Suffusion had TimThumb bundled with it for a long time, since version 3.2.2. However, owing to a crackdown by the WP Theme Review Team on themes not using WP’s native resizing capabilities, I took the decision to remove TimThumb from Suffusion’s core in version 3.7.5.

So why am I writing this? There are a couple of reasons:

1. Some sites have been publishing false and half-researched information claiming that Suffusion has TimThumb. I did post back on their site pointing out that Suffusion hasn’t had a trace of TimThumb since six months, but I don’t see that things have changed. Just to assuage your concerns, here is how you can check for yourself:
   1. Go to Suffusion’s version control page on WP.
   2. Click on the link for the latest version, 3.8.2. You will not see anything that deals with TimThumb anywhere. Typically themes have a file called timthumb.php or thumb.php.
   3. In fact, check back to version 3.7.4, and you won’t see it anywhere.
2. Now, the real reason for writing. A user posted a question on the support forum asking why thumbnails were not displaying. I checked, and found that the site in question was using TimThumb. Digging just a bit further revealed that the user was on a version of the theme that is almost one year old, while TimThumb has been removed from the theme quite a while back. So, if you have a version of Suffusion at 3.7.3 or older, please UPGRADE now!!! Even if you have backups of WP with old versions of the theme or backups of old versions of the theme itself, do the upgrade. I cannot stress enough how important this is! It might be a case of closing the stable door after the horse has bolted, but it is better to secure your server now rather than later. Note that if your installation is already infected, you have to do major cleanup on your site and it is best to hire an expert for it. Also note that even if you have other themes on your site that are not active, and those themes have TimThumb, your site stands the risk of being infected, because TimThumb can be invoked without loading WordPress.

The current released version (3.8.2) is quite stable. It has very few bugs, and they are fairly minor and pertain entirely to new functionality. So you shouldn’t face any issues due to the upgrade. As you are probably aware, I make every effort possible to ensure you have a low change impact, so things should be generally fine if you are upgrading from a pre-3.7.5 version to the current one. However I have had some users lose some flexibility with respect to resizing. For example, TimThumb could resize upwards as well as downwards. The native resizer only resizes downwards.

About a year back I wrote an article on the Theme Review process that WordPress had instituted. In only its second month at that time I was among several users to have expressed frustration with the process. Several months have passed since the experiment has moved from the lab to the mainstream, and I thought of taking some time to revisit the process to see how it has helped or hindered the reviews.

Significant Improvement in Quality

The biggest outcome of this effort has been a significant improvement in the quality of repository-hosted themes on http://wordpress.org. In the initial stages the process was aimed mainly at catching themes with spam links and obfuscated tracking code. Gradually, as the reviewers found their feet a lot more standards and policies came into force. The review team, or WPTRT (WordPress Theme Review Team) has been steadily enforcing a lot of these:

1. Repository-hosted themes are required to have zero debug errors

   What does this mean? If you look through your server logs you shouldn’t see any messages that say “NOTICE”. WP provides a much easier way to check this. You can go into the wp-config.php file of your installation, then put in this line there:

   define('WP_DEBUG', true);

   If your theme doesn’t spew a lot of messages in the admin panel upon activation, it is probably clean. Of course, you need to also check out each type of view in the front-end, like the search page, a single post, custom widgets etc. Not having error messages is not only good practice, but it also improves performance, as your web server is saved the CPU cycles of writing the error to the log.

   Here is the kicker: setting this flag will almost immediately spit out errors for plugins, because most plugin authors have probably never coded with this flag on. That is why on my DEV environment I rarely have plugins activated.

2. The Theme Review criteria are kept up-to-date
   Every theme has to go through an elaborate review process in terms of standards and compliance. The criteria are divided into categories such as what is required vs. what is recommended. Some people do complain that the criteria change too frequently. However I have managed to stay abreast of the changes most of the time (plus I run a periodic check of my theme – see below), so this has not been an issue for me since quite a long time.
   The review criteria cover various aspects, key among them being the use of standard WP calls. Basically WP’s philosophy is “Decisions not Options” – themes are intended to work out of the box. In other words, a theme like Suffusion is going to be looked down upon by WP aficionados (because it really gives you too many options). But I digress. The expectation is to have every theme be extensible by child themes. The use of standard functions helps this process significantly. In case you were wondering, Suffusion makes use of almost every one of those (apart from WP’s standard Custom Header, Custom Background and Editor Stylesheet functionality).
   Every developer is advised to go through the review criteria to ensure that his theme passes the checks before handing it off to the review team.
3. Themes are tested against a complete test suite
   Something that was rarely updated prior to the WPTRT’s setup has been getting quite frequent facelifts. There is a full-fledged test suite frequently updated to account for WP core enhancements. Developers are encouraged to install the latest versions of the test suite when available and ensure before submission that all the tests pass successfully. The reviewers have to ensure that all the tests are passed while doing a full review of the theme.
4. Automated tools are used to check for bad stuff …
   For all the hours of effort that must have gone into the Theme Check plugin, the benefits are invaluable. Any WP developer can install this plugin, then run it against his installed themes. It provides details at several levels:
   1. Deprecated function calls with suggestions for new functions
   2. Missing usage of required functions
   3. Code obfuscation and spam links
   4. Potential security loopholes
   5. Basic checks like licensing information

   This is probably the most useful plugin a WP theme developer can have. The tool was made a formal requirement for theme submissions about a couple of months back, so any theme submitted would automatically be checked using the tool and the developer would have to ensure all checks are passed.

5. … And the tool developers and maintainers are open to feedback
   There is a constant refinement of the process. To cite an example, I was using a function called get_users_of_blog, that got deprecated with WP 3.1 in favour of get_users. Now, if I was to switch to get_users_of_blog in my code, people still using WP 3.0 would run into issues – after all it was quite natural to have users stay on the previous version of WP to avoid plugins breaking. But if I didn’t do the replacement the theme wouldn’t pass the check. So I highlighted this issue to the review team and a resolution was reached quite quickly: deprecated functions that are one version old will be given a pass. The plugin was promptly modified and further discussions were averted.

Turnaround Time Close to Pre-WPTRT days

The WPTRT came up with a process of classifying submitted themes into 3 categories:

1. Priority 1: Themes that have already been approved. Themes in this queue are addressed first. Such themes typically go through a “diff” process, where the reviewer checks the changes against the previous version and if the changes look okay, the theme is approved. Of course, there are exceptions when a full review might be required (I have had it happen when I redid Suffusion’s innards in 3.7.7). There is some ambiguity as to what happens if the reviewer finds bugs or errors. The theme gets pushed to Priority 2 (see next) upon resubmission, but if the resubmission happens within a reasonable time-frame the original reviewer can review it as if it were a Priority 1 theme.
2. Priority 2: Themes that have been reviewed at least once and the latest version was not approved. The original reviewer marks the old submission with information regarding how complete the review was. If the original reviewer had said that the old review was complete, the new reviewer simply needs to verify that all the points in the old review have been addressed. If the original reviewer had said the old review was not complete the new reviewer needs to check for the old items as well as potential issues with the new submission.
3. Priority 3: New themes that have never been looked at by any reviewer.

With an increased number of reviewers and a much more streamlined process, the review time for previously reviewed themes has definitely come down, though I don’t have exact statistics.

Trainee Reviewers

Any time that a new reviewer wants to start, he is put through an incubation process as a trainee, where he looks at an assigned theme (typically a Priority 3 theme), makes comments and submits it to someone who is a full-fledged reviewer. The latter reviews the feedback and makes comments on the thoroughness of the trainee’s review. After a few such cycles when there is enough confidence that the trainee can go out on his own to review themes, he is upgraded to a full reviewer. This ensures that every reviewer is fully aware of all the areas a theme can potentially trip, and every review is of good quality.

What Could Improve

Obviously there is always scope for improvement. Being an open forum the WPTRT mailing list often sees animated discussions on what should an shouldn’t be there in themes:

1. Theme vs Plugin Discussions
   Very often a theme developer includes some functionality that has little to do with the look and feel of the theme. Classic scenarios in this case include combining scripts on the fly to optimize site speed, or include SEO options in the theme. The developer gets told each such time, “That is plugin territory”. While that may be true on the face of it, the heart of the matter is more complicated. A lot of developers release themes in the repository to compete against the better marketed “premium” themes. There are many reasons for this, primary among them being strong advertisement across the web by folks including core WP members about using repository themes. If a new user comes to the repository based on advice off the web, then starts comparing the popular themes in the repository with top “premium” themes, it might soon start falling apart. For, all the standards apart, an end user will see much more value offered by a premium theme simply because the so-called premium themes have no boundaries to work within. There are a few ways to work around this, none of which is easy though. One would be the following:
   1. The theme page at WP (such as http://wordpress.org/extend/themes/suffusion) could be made to have a list of dependent plugins that the theme works well with or recommends.
   2. Upon downloading the theme the corresponding plugins get downloaded as well. And upon uninstalling the theme there can be an option to deactivate the extra plugins. Of course, this will require probably significant changes to the theme administration in the core.
   3. The biggest challenge with this setup, though, is that plugins have close to zero code quality control. All popular plugins not distributed by Automattic have debug traces that make you shudder. And plugins are often written in a manner that is not optimal from a security point of view. Given that the total number of plugins is orders of magnitude higher than the number of approved themes, getting a manual process around plugin approvals is foolhardy.
2. Specialized Theme Support
   This is a gray area whose resolution will be of significant benefit to developers and users alike. There was a repository theme called Quality Control, which helped users create a bug-tracking system in the standard WP framework using Custom Post Types. The theme is no longer available on the repository because the developer got paid to develop this for a company. You can still get older versions of the theme (which are licensed under GPL). The theme displayed a very innovative use of WP. Unfortunately though, since it requires the use of Custom Post Types in the theme itself, users are compelled to stick to the theme if they want to have their content available on their installation. Basically the user gets into a “lock-in” situation with the theme.
   There was a suggestion to have the authors of such themes provide a way to opt out of the theme. In case of the Quality Control theme it would involve the visual provision of the code to generate the structures of the post types and taxonomies. Users could then paste the code in a new theme and make it run there.
3. Vocal Opposition to Options
   This is a weird one. It is understandable that themes should be extensible by means of appropriate hooks so that adventurous folks can write the code themselves in child themes. But of WP’s several million users, barely 1% can figure out what the anatomy of a theme is, the multitudinous tutorials and oodles of documentation notwithstanding. It is surprising that having code-intensive frameworks is encouraged, but a UI-intensive framework that achieves similar results is frowned upon. Are all users expected to get into PHP code and make a child theme if they wish to display something like excerpts instead of full posts? Admittedly the percentage of people opposing themes with elaborate options panels is small, but if you were to survey people across the web on what they would like better, I am sure you will find that themes with more options have more takers.

How I Have Improved

I have managed to keep abreast of WP changes by various means. Occasionally I go through the last few reviewed themes and see what kind of comments came up from reviewers. I then do an introspection to see if I am breaking any guidelines myself, then I embark on making the appropriate changes.

The ultra-buggy 3.7.5/3.7.7 release of the theme actually involved one such fundamental paradigm shift – I switched to using the Settings API. Nobody had mandated the shift: it just made sense based on comments provided to others. Getting the back-end coded to work with the Settings API was a huge challenge and I spent many hours labouring over getting things right. This was specifically because I had so many options that I needed to group them in three levels (most tutorials on options deal with just one level, and an exceptionally detailed one by Chip Bennett deal with 2 – you can see my comments there).  But at the end of the day it was quite satisfying to get the API working and in place.

Another key functionality I built in was an image resizer, again in 3.7.5/3.7.7. I used to have TimThumb as the resizing script, though I did have support for native WP thumbnails as well. But with the 3.7.5 release I completely eliminated TimThumb, thanks to repeated discouragement for the script in the theme reviews. My resultant code is quite powerful and versatile, but is limited by certain ways of WP handling image resizing natively.

As it turns out, there are a few things I still need to address in Suffusion, namely the use of WP’s native Header and Background functionality. I will be pondering over those the next few days, because the last thing I would want is to break functionality that is working fine for the thousands of users of the theme.

But believe me – it makes a developer very happy to have zero errors on debugging, and have Theme Check say “Pass”!

When in Doubt, Ask!

If you are implementing a big ticket feature that can trespass into gray areas of theme development and involves writing to files or reading from files, do yourself a favour. Ask. The WPTRT mailing list has folks like Chip Bennett and Edward Caissie (Cais) who have been a part of the review team since its inception, Simon Prosser who has written the Theme Check plugin (currently maintained by Otto and Simon), Otto and Justin Tadlock who are WP veterans, and Andrew Nacin who is a key member of the core WP development team. There are other volunteers who have been a part of the process for a very long time.

You might not be in 100% agreement with what they say (a lot of it might appear to be stifling if your goals are ambitious), but asking before implementation will give you fair warning and a potential sense of direction with respect to how you should implement certain features. It will also help avoid some long-drawn and nasty battles.

To Conclude

The Review Experiment is no longer an experiment. It is a formal process that is here to stay. It has helped improve theme quality across the board. Kudos to the review team for making the process successful!

Folks, I have another update on Version 3.7.9 of Suffusion. Unfortunately it is not all good news.

Bad News 1

The feature most looked forward to for this release was undoubtedly photo-blogging. Unfortunately I had to pull this to a large extent. The reason was that I have been quite busy on both, personal and professional fronts and I wasn’t able to dedicate as much time to the theme as I used to earlier. As a result, the last 20% of the features that needed to be fixed for photo-blogging became too daunting to tackle. Eventually I culled the features from the theme.

The reason was that WP version 3.2 is almost upon us, and I am pretty sure that due to the JQuery library changes in the core, version 3.7.8 is going to break on the admin panel side of things (the theme itself would work). So I had to fast-track the development and remove things that were taking too long to build.

Good News 1

This was something I had been debating for a while – should the photo-blogging support be a part of a plugin? Eventually I decided “yes”. As I wrote earlier, I have done a lot of work on the integration of WP galleries with Flickr and Picasa and it would be a shame to throw it all away. So I decided to make a plugin with it. Strictly speaking it is an enhancement of a standard short-code, hence it does fit in the plugin territory. I will keep you posted about the developments on that front.

Bad News 2

I had also hoped to revamp a few things like how the featured content slider looks, in terms of placement of the post index etc. Another area I was working on was the look and feel for the tiles and the magazine layout. Again, these have been relegated to the back-seat for now.

Good News 2

There are, however, several improvements to the magazine layout in general and to the theme overall, like some new widgets, some improved widgets etc. I will publish the full change log once the release is done. The change log is not small by any means.

I should be submitting the new version in a day or two. Hope you will like it.

On a personal front, I believe I have almost reached saturation as far as Suffusion is concerned. I will actively try to avoid big ticket new features from now on and instead focus on releasing functionality as plugins. I will also try to improve my site design skills and make Suffusion look pretty on the front. I believe I have built a unique framework in the sense that it works for people who are not very code savvy, so my goal has been more or less achieved.

The first Beta version of WP 3.2 is out. Though this is more of an evolutionary release, as the release notes point out, there are some significant things you need to note:

1. PHP 4.0 will no longer be an option. You need to have at least PHP 5.2.4 and MySQL 5.0. This makes me very happy, since I have sometimes been caught napping due to the use of a PHP 5* function causing breakage under PHP 4*.
2. IE6 support is being killed. This makes me even happier!! Though I have tried to keep Suffusion running under IE6, it has been a struggle, particularly with respect to certain dynamic sidebar arrangements (I know for sure that some of them don’t work). The official killing of IE6 support means that I can kill IE6 support myself and not feel guilty.

The killing of support for older versions of software has a side-effect that makes me rub my hands with evil laughter. The reason? Plugin authors have to pull up their socks. The two main types of extensions to WP, themes and plugins have very contrasting levels of controls. Themes go through a rigorous and regimented approval process, with a battery of tests, standards compliance checks and so on. Periodically the theme review team goes through existing repository themes, then yanks those which have not been updated for eons.

Plugins are at the other end of the spectrum: once you get space assigned to you in the plugin repository you can check in pretty much what you want. The net result is that plugins often follow poor coding practices, use outdated JS and cause royal conflicts with themes. An example is the one I detailed in a prior post, where incorrectly coded plugins tend to include their JS on all admin pages, resulting in the theme’s admin panel (or other plugins’ admin panels) behaving incorrectly.

In addition there are a handful of other changes, including a new default theme, Twenty Eleven. Do feel free to give the beta a shot on your test sites.

A word about version 3.7.9 of Suffusion: I was on vacation last week, so I couldn’t do much. After my return I have closed the loop on some functionality that I was designing. I should have a version out hopefully by the end of this month.