For each WordPress plugin you install, you are adding to the bandwidth/server overhead of your site. As a plugin author, there are some simple steps to take to reduce the footprint of your plugin (whether it be helping with server load or conserving bandwidth), even if your plugin still requires a lot of code.
Break Out Admin Panels Into Separate Files
Even for simple plugins, adding admin panels can easily balloon a plugin’s file size. A simple, yet effective technique, is to copy the code used for the admin panel to a separate file and simply provide an include in the function that loads the admin panel.
For example, say you load in your admin panel using this code:
add_options_page('Plugin Name', 'Plugin Name', 10, basename(__FILE__), 'printAdminPage');
The function printAdminPage is going to be the function that loads the admin panel. Within this function you could have:
function printAdminPage() { include 'includes/admin-panel.php'; }
The above snippet assumes you have an ‘includes’ directory with your admin panel code in ‘admin-panel.php’.
Note: Per Dougal Campbell, includes pose a security risk. Here is one technique for securing PHP include files.
Use Includes to Separate Major Functions
If your plugin has separate functionality, why not separate this functionality into separate files that can be included when needed? For example, what if your plugin deletes or saves something? You could include the delete code in its own file, and the save code in another file.
function save_or_delete($task) { switch($task) { case 'save': include 'includes/save.php'; break; case 'delete': include 'includes/delete.php'; break; } }
The above code includes the appropriate code only when certain tasks are performed.
Load Parts of Your Plugin on Relevant Pages
With more plugins coming with their own stylesheets and JavaScript files, it may be necessary to specify which pages these files should be included. Fortunately, WordPress has a nice collection of conditional tags and/or actions that can help you determine what kind of page the end user is using.
Say that you want to load a piece of JavaScript only when a user is in the admin panel. Fortunately WordPress has an action specifically for loading scripts in the admin panel called admin_print_scripts. A simple action call would look like:
add_action('admin_print_scripts', 'addAdminJS');
Within this ‘addAdminJS’ function, I would run the wp_enqueue_script to include my JavaScript file.
Another example would be only loading a JavaScript file on just single posts and nowhere else. The action that is necessary to load JavaScript files is wp_print_scripts.
add_action('wp_print_scripts','addJS');
Within this ‘addJS’ function referenced above, we could include a simple conditional tag to determine if we are on a single post.
function addJS() { if (is_single()) { //Do JavaScript code loading here } }
Now the JavaScript code will only load on a single post and nowhere else. You can use the same technique for the wp_head action when loading style code.
Conclusion
I outlined three simple ways to reduce your plugin footprint. Not all ways are beneficial for all plugin authors, but they will hopefully get you thinking about how to reduce the amount of overhead your plugin uses.
Is there anything a lowly blogger can do to reduce plugin overheads on their blog? Other than disabling plugins, that is…
db
Thanks for this. It raises one question for me that is not covered in the WP codex – and indeed the above JS loading functions are not covered in detail either. Do you by any chance know with which WP version the likes of ‘admin_print_scripts’, ‘wp_print_scripts’ and ‘wp_enqueue_script’ were added? More than once I have used a call only to discover that it wasn’t avalable in (for example) 2.0…
Interesting post.
I’ll try to keep these steps in mind during the development of my chess publishing related plugins.
thanks for the tips. going to hack the plugin I used now 🙂
David,
Unfortunately it is the plugin author’s responsibility.
andy,
I *think* they were added with 2.1.
Thanks Ronald – that was my guess. Even though the codex doesn’t detail usage, version would be useful to know in all these cases. I have a lot of users of my plugins on the V2.0 family.
You might want to note, however, that when using this kind of include pattern, you have to pay extra attention to security. Make sure you do something to block attackers from browsing directly to these snippet files in a way that could cause side-effects. This is extra-super important if your php install has globals turned on (which, of course, it shouldn’t, because it’s bad for security).
how is separating files for conditional inclusion and bandwidth in any way related?
this is all server-side, there is NO impact on what is sent to the user
the only relevant part of this post is about loading or not an hypothetical JS bundle depending on which page calls the plugin
I agree with w00kie.
Seperating files should have no effect on the speed of a plugin as the functions are all compiled server side. Splitting files will make things easier to read for beginner and novice plugin developers, but that’s about it.
Put me down with wOOkie and Jason. Sure seems like the backend of plugin code is only seen by the server. Maybe you meant saving server load? Breaking it up into separate files would mean php didn’t have to read in as much code but it doesn’t seem like a few K are going to make any difference.
Great post!
I think it could be a good lesson for the WordPress developer team as well.
The “beauty” of the WP code is sucking up the speed of the weblog.
Loading index.php to call wp-blog-header.php, which will call wp-config.php, then wp-settings.php and finally end up with more than dozen of files loaded, one of which is functions.php with 78 (seventy eight)(!) functions.
There are so many places where you can simply use the “hard code” instead of calling file which contains the needed function.
Many of the plugins are so simple that you can just include them in the theme (as I did with “Quick-tags” in “Collapsing Blue” wp-theme) without using the plugin hook, and the authors of such plugins must provide installation instructions for users who would like to have them implemented in the theme.
Separating the functions in different files and loading them only when neded is the first thing a wp-developer must have in mind before start coding.
w00kie, Jason, Scott,
Thanks for bringing the bandwidth issue to my attention. Using conditional includes will help with server load, but doesn’t have any effect on bandwidth unless code is being served to the user (such as CSS, JavaScript, or HTML). Using conditional includes is still a good idea from a server-side standpoint though. I’ve updated the post. Thanks for your feedback.
I did a site for a friend’s company, set them up with nice blogging options, half a dozen plugins, the works. We eventually decided a blog wouldn’t work for them, so I stripped it right back and created a conventional static site, pretty straightforward to do but here’s the howto in case you’d like to know – http://www.sciencetext.com/hyd.....bsite.html
db
With my Gregarious social bookmarking plugin, there were so many functions and features that I implemented a plugin system for the plugin! Basically, different “modules” provide the features and the user can choose which modules to load. If you want a Digg button, enable the Digg module. Want a “Share This” link? Activate it. In this way, the plugin saves a lot of bandwidth and is significantly faster than loading everything even if it’s not being used.
This is a very nice idea, amazing, but for those who are not really good on PHP or whatever about codes like me, hmm, difficult to follow the instructions how to do it, is there any plug-in to make it simple? lazy just as I am to learn, lol! 😀
brVinceFMS,
This is something a plugin author would have to do.
Hi Ronald
I just release my first plugin (using a lot of your help from your Devlounge guide – thanks) and as you have shown above I included the code for my “Print Admin Page” function. However this doesnt seem to work with WordPress 2.3
The include works fine with an old instal I have (2.1.3 I think) but not with 2.3 – it just gives a blank admin page suggesting that the include is not including.
Have you noticed this with 2.3? Can you suggest any reasons why this might be happening?
Thanks
These are some great tips which I’ve seen a handful of authors NOT employ (especially loading the relevant JavaScript on relevant pages/posts rather than the whole site). I’ll be writing a plugin soon, so these points will come in handy. 🙂