It took a while, but version 4.4.3 of Suffusion is finally live. This version has a handful of changes:
- New Features:
- I have added an option to disable widgets, under Back-End → Modules. In there you will see a listing of all of Suffusion’s custom widgets. If you are not going to be using a particular widget, feel free to disable that widget. It will reduce the load on your server.
- Bug Fixes:
- I have fixed a problem that was causing all tiles in a tile layout to be of the same height.
- There was also a problem where users were unable to unset certain options, like the one to make responsive layouts compatible for iOS devices. This should now be working.
- Code Housekeeping:
- I have removed most of the BP integration content that was bundled with the theme. This is mainly because BP integration is exclusively supported in the Suffusion BuddyPress Pack, and this plugin has been around for a couple of years now.
- I have also completely separated out conditional WPML code so that it doesn’t load with the theme if you don’t have WPML installed.
- I have moved the CSS generation code to a dedicated CSS generation file from functions.php. This reduces the load for those scenarios where the CSS is not being generated.
- I have removed the BGIFrame library from the JS code, since the theme doesn’t aim to support IE6. This library was intended to help IE6 users not have issues with overlapping navigation bars.
- I have deleted some functions that were no longer being used in the theme.
As I write this, WP 3.5 is nearing its release. For several reasons I am not very thrilled about this.
Firstly, this release, as in the case of the previous one focuses on style rather than substance. There are several tickets in WP with patches for some WP problems, which don’t seem to get triaged ever. Instead the core developers focus on things like supporting larger theme screenshots in the back-end. In the meanwhile, several of my pet peeves (such as the fact that two active plugins cannot both modify the navigation menu traversal) continue to be ignored.
Secondly, the dogmatic approach of the theme review team, which reaches new levels with every major WP release, is now becoming too much of a headache to deal with. The latest set of guidelines that will be effective around a month after 3.5 goes live has some gems that make me want to stop theme development for good:
- “New guideline under presentation-vs-functionality: Themes must not bundle custom post-content shortcodes”
While I understand that this is intended to prevent “lock-in”, the levels to which the review team is willing to go to shove this down our throats is astounding. The above essentially means that two particular shortcodes that Suffusion offers, suffusion-widgets (which lets you do ad hoc widgets) and suffusion-multic (which helps you do multi-columns) have to be pulled from the theme very soon. It doesn’t matter that these have been in the theme so long that if they are pulled, sites can break. More surprisingly, it doesn’t even matter that to prevent a lock-in I published a plugin (Suffusion Shortcodes) that will help users transition out. I made several suggestions like making theme authors bundling such shortcodes indicate this in their readme files or in the theme CSS header. I even volunteered to write a patch to core that will make users aware that a theme is defining custom shortcodes and alert users to the potential lock-in. But none of this made a difference.
- “Timing for making do_settings_sections() required (as opposed merely to recommended) as part of Settings API implementation”
This isn’t one that affects me, but it makes me wonder if the review team is really so starved of work that they think up such ridiculous “guidelines”. I can say without a trace of hubris that I have pushed the WP Settings API farther than any other theme author on this planet. To the best of my knowledge there is no other theme that does 2-level options pages using the Settings API honestly (and I use the aforementioned do_settings_sections calls, which are terrible). And IMO the Settings API is among the lousiest and most hard-to-use pieces of code in WP. Telling users to use it for their options is like asking them to start drinking kerosene instead of water. I would love to see other themes with multiple options pages embrace this and use this function whole-heartedly. Of course, this isn’t a full-blown guideline yet, so it might not see the light of day.
Basically, the Theme Review Team is fine as long as it reviews theme quality. But telling a theme that it cannot include certain features even when such features are offered separately in a plugin primarily to prevent lock-in is BS. The people making the recommendations, for the most part don’t have to handle massive user bases, and that gives them a woefully inadequate view of ground realities. What is more amusing is that prior to each release there is an elaborate charade of “gaining consensus on guidelines”, yet what happens is that the only people whose opinions count are core developers, WP community big-shots and admin reviewers (I am none).
While I don’t normally rant here, the latest revision to the guidelines upset me so much that I have seriously begun to evaluate if developing Suffusion is worth it. It isn’t that I am upset because somebody has taken away my new toys. If you check Suffusion’s history you will see that however convoluted a requirement is, I have always managed to handle it even if I don’t agree to it. But there is always a straw that breaks the camel’s back; hopefully this wasn’t mine. A hobby is supposed to be fun, and I have been avoiding Suffusion development because the fun is all being bled out of it.
In the meanwhile, the Instagram module of Photonic is almost ready!