Featuring New WordPress Tweaks Bundle And WordPress Tweaks Composer Tool
Cheerio, dear performance-conscious WordPress user. I present you the continuously evolving, streamlined WordPress Tweaks Bundle, and its accompanying WordPress Tweaks Composer online tool.
Read about it at the WordPress Tweaks homepage, or about the technical background of it in the rest of this post.
Note: The rest of this post may sound very technical to some readers.
[toc style=”margin: 1em 5em”]
How Come?
Hackadelic WordPress Tweaks is the result of my attempt at a twofold novel approach to WordPress plugin development, and the continuation of my steady quest for streamlined and highly effective WordPress solutions. One novel aspects is the renunciation of WordPress options in favor of a generative approach. The other is the utilization of the plugin code to control the configuration and generation of streamlined variations of itself.
Configuration vs. Customization vs. Generation
The usual approach to adjustable plugin functionality is the configuration approach. That is, the use of options. The plugin adds a dashboard page where the user can adjust aspects of the plugin functionality. This is called a configuration approach. In the fron-end (or wherever that plugin functionality is used), the plugin queries and evaluates the configuration, and acts accordingly.
From a performance perspective, this is not always appropriate. Let’s see why:
Effectively, that phrase “the plugin acts accordingly” means that different code paths / code variations are executed for different configuration settings. For example, if the plugin’s options are comprised of 3 check boxes, each of which can be turned off or on, then there are 8 code variations contained in the plugin. 10 check boxes result in 1024 (!) code variations.1
Why does this matter?
For one, code size: All code variations are part of the plugin code, many of which are never executed.
For another, database size: Every configuration adds more entries to your options table. It not only bloats your database (the options table is one of the most bloated tables in a WordPress database), it also consumes space on your hosted server (this matters if your hosting plan limits your hard disk resources).
And LBNL, performance: The configuration is queried and interpreted at run-time. In case of front-end plugins, it is evaluated on potentially every page view that every user (or even robot) ever makes. This may not only affect user experience (if page loads are too slow), but also eats up CPU resources – and many web hosting companies are known to suspend websites for “exhaustive CPU usage”.
In particular in the case of simple tweaks like here, it feels unjustified to bloat code and add run-time overhead for “administrative” purposes that is of a potentially comparable or greater magnitude as that of the primary function.
That’s why I chose to implement a one-file plugin that bundles such tweaks. (I used to call it Hackadelic Basic Tweaks.) If I wanted another tweak, I would add it to that plugin. If I wanted to turn a tweak off, I would comment out the corresponding code (but that rarely ever happened). This approach is called a customization approach. A custom version of the code is produced every time the desired configuration changes.
Of course, such an approach is inapplicable for the average user. Especially when done manually. After all, options are a very convenient way to tune a plugin behavior. They are convenient, because the tuning happens in a GUI.
At this point, the next logical step evokes itself clearly: Combine the best of two worlds by providing a tool, with a nice GUI, that generates a custom version according to user-supplied options. This approach is called a generative approach.
Tool Bootstrapping
The problem with the generative approach is that is is disproportionately more complicated to develop and maintain. And test the generated code. A tiny typo in the code generation system, and it produces crap instead of a useful plugin.
Another problem is that when a new tweak is to be added, I’d have to make changes at many places to keep everything up to date. (For example, I’d have to change the GUI to add the new tweak to the options.)
Fortunately2 I had an ingenious idea that simplified the whole process:
I’m using the “full version” of the tweak bundle (with all tweaks included) to drive the GUI and the whole generation process!
That way, when I add a new tweak to the “full bundle”, everything else automatically adjusts itself accordingly.
Bottom Line
What should I say? I’ve put quite some thought into this, and I’m curious how it’ll work out from a users perspective. Feel free to provide feedback, it’ll be highly appreciated.
