post-page

Reduce the Size of Your WordPress Plugin Footprint

19
responses
heading
heading
heading
19
Responses

 

Comments

  1. David Bradley Blogging Tips (20 comments.) says:

    Is there anything a lowly blogger can do to reduce plugin overheads on their blog? Other than disabling plugins, that is…

    db

  2. andy says:

    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…

  3. Chess Teaching (15 comments.) says:

    Interesting post.
    I’ll try to keep these steps in mind during the development of my chess publishing related plugins.

  4. LcF (19 comments.) says:

    thanks for the tips. going to hack the plugin I used now :)

  5. Ronald Huereca (39 comments.) says:

    David,
    Unfortunately it is the plugin author’s responsibility.

    andy,
    I *think* they were added with 2.1.

  6. andy says:

    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.

  7. Dougal Campbell (35 comments.) says:

    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).

  8. w00kie (4 comments.) says:

    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

  9. Jason (75 comments.) says:

    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.

  10. Scott (2 comments.) says:

    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.

  11. Truden (23 comments.) says:

    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.

  12. Ronald Huereca (39 comments.) says:

    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.

  13. David Bradley Blogging Tips (20 comments.) says:

    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

  14. Ankur (3 comments.) says:

    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.

  15. brVinceFMS (1 comments.) says:

    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! :D

  16. Ronald Huereca (39 comments.) says:

    brVinceFMS,
    This is something a plugin author would have to do.

  17. Aaron :: miLienzo.com (1 comments.) says:

    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

  18. Rishi (1 comments.) says:

    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. :-)



Trackbacks/Pingbacks

Obviously Powered by WordPress. © 2003-2013

page counter
css.php