Functionality: Plugins vs Themes

Functionality: Plugins vs Themes

on Aug 8th 2012 with 74 comments

There are a lot of factors that influence performance on your WordPress site, and one of the tricks that “experts” will often tell you to do is avoid plugins. They will tell you it is better to place functionality inside of your theme, instead of activating a plugin. Is this true?

Introduction

When it comes to the performance of your WordPress site, there are a lot of factors that influence the overall results. These factors include how well your theme is written, the number of images and other resources that must be loaded, how well your site is cached, the quality of your activated plugins, and many more. Two factors, however, that have zero impact on the performance level of your site is the number of plugins (yes, I’m 100% serious) and whether pieces of functionality exist as a plugin or part of your theme.

If you do a quick Google search for “how to add a contact form to WordPress“, you will probably notice a heavy trend when it comes to tutorial titles. Most of the tutorials will include something along the lines of “… without a plugin“. This trend, which exists for dozens of tutorial topics, brings into mind the idea that plugins must be bad and possibly that they hurt your site’s performance. Having the words “without a plugin” so common in tutorial titles, as well as forum posts, many people have come to believe that it is better, particularly for performance, to include pieces of functionality inside of themes (whether your own or one you have purchased) rather than rely on a plugin to provide it.

The first response I have to this commonly held belief is that it is completely unfounded, and actually, entirely incorrect. There are several aspects to the reason this belief is wrong, and I will go through them point by point. I will also briefly touch on the belief that fewer plugins are better, which is (usually) entirely incorrect as well.

Common Beliefs

1. Functionality Is Better Placed in a Theme Than a Plugin

The idea behind this belief is that plugins are often the source of problems on your site, either because they are poorly written or they conflict with something in your theme. If plugins are often bad, then it makes sense that it is better to place functionality (such as contact forms) inside of the theme, right?

Wrong, and here is why:

“Whether code is loaded at point Y or point X, it is no more efficient.”

First, the only difference between code that is placed in a theme and code that is placed in a plugin is the time of execution. Active plugins are loaded and executed before the currently active theme, but other than that, there is zero difference in the way that code contained within each is executed, and also zero difference in terms of how efficient the code is. If you’d like a great diagram of the WordPress core load process, see this Stack Exchange post.

Whether code is loaded at point Y or point X, it is no more efficient.

Second, with point number 1, we now have to ask “how is a theme the better place for functionality?“, since both plugin code and theme code gets executed in the same way. The answer is simple. While themes have zero benefit over plugins when considering where to place pieces of functionality, it turns out that plugins have a couple of significant advantages over themes. I will walk through these advantages in a moment.

2. Code in Themes Performs Better Than in Plugins

I really don’t know where this comes from, though I suspect it is has to do with the fact that people are often scared of plugins, and they frequently hear that plugins cause performance issues on a site. The fact of the matter is that this belief is ludicrous at best. As stated above, there is zero difference (except for timing) in the way that plugin code is executed, when compared to theme code.

If you place a function into a plugin, execute it, record the timing, and then do the same thing with the function but while it is placed in the theme, you will find that there is zero difference. They both execute with the same speed and neither has any direct advantage over the other, in terms of performance.

This brings up the question then, are themes ultimately better than plugins for pieces of functionality? The short answer, no, absolutely not.

Some Reasons Plugins Are Better

We should now ask, are plugins ultimately better for pieces of functionality than themes? The short answer, yes, most of the time they definitely are. But why? Well, there are a few reasons.

  1. Separating your code into “chunks” is one of the best things you can do for large projects, as it makes the entire project much easier to maintain, and debug in the case of a problem. By placing your separate pieces of functionality into their own dedicated plugins, you effectively create these “chunks”. Each plugin is maintained separately, which (as you will find) can make it infinitely easier to track down problems.
  2. If something breaks, you simply deactivate the plugin. Let’s say that the contact form on your site is integrated into your theme and it breaks, bringing the site down with it. What do you do? If you don’t have the skills or know how to replace the contact form with a functioning one, you are in big trouble. On the other hand, if the functionality is provided by a plugin, you simply deactivate the plugin, and bring it back online once the problem is fixed, or you go find a new one.
  3. If you ever want to change themes, as most sites will do at least once or twice, you will lose every bit of custom functionality you have (including short codes) because the new theme will either not have the same functions, or it will execute / build them differently. If you, however, had all of your short codes inside of a plugin, as well as things like contact forms, all you have to do is upload the new theme and activate it: everything will still work just as before. Isn’t that right there a good enough reason to say that plugins are better for separate pieces of functionality than themes? I believe it is.
  4. Plugins can each be separately updated and enhanced. If you add improvements to a theme, then the entire theme has to be updated. How many times have you seen a user of a theme add customizations to the style.css or functions.php? If they have done so, it is impossible for them to update the theme and get the new improvements without manually moving all of their changes over. This is assuming they have not created a child theme, which they should have but many users don’t. When the improvements are placed into a plugin, the user has to do nothing more than update the plugin from their Dashboard.

It goes further than just these four reasons, but it should already be clear the huge advantage plugins have over themes for separate pieces of functionality.

This now brings me to the question of whether it is a bad thing to have a lot of different plugins. You can probably imagine how quickly the number of active plugins will expand if you are placing each major piece of functionality into separate plugins. Does this cause a problem? What about once you reach 10 plugins? Isn’t that a lot? How about 20 or 30? Isn’t that extreme?

No.

During WordCamp Kansas City 2012, I had the opportunity to spend some time talking with Otto, who is one of the top developers for WordPress and also one of Matt Mullenweg’s right hand men. Otto does most of the development on Matt’s personal site and he told me that there are dozens of small functionality plugins running on that site. Each of the plugins has specific tasks and they all run perfectly side by side, even though there are a lot of them.

I personally run about 50 plugins on my Pippin’s Plugins site.

The point is that plugins do not cause performance issues simply because they are plugins, not even with 100 or even 200 active at the same time. Performance problems with plugins come from those that are poorly written, not the number of plugins. You could easily cause more performance problems with a single poorly written plugin than with 300 simple, well written plugins.

Performance issues usually come down to loading resources and performing database queries, so plugins that do a lot of these tend to impact performance. Plugins that do not perform queries on the database or load resources have zero (or very near zero) impact on performance, and that is why you can literally run 300 plugins on your site with no impact.

I also know that WP Candy runs upwards of 80 or 90 active plugins at all times.

The key to remember is that the number of plugins has zero impact on performance, only the quality and type of plugin impact performance.

The second key point to remember is that code in plugins runs exactly the same as code in themes, so get rid of the idea that it’s better to place functionality in your theme than a plugin. Themes are supposed to control the visual aspects of your site, not the functionality.

The last point to remember is that plugins are only evil when built poorly. Plugins themselves are never inherently bad; they are only bad because the code that makes up the plugin is bad.

Pippin Williamson is mordauk on Codecanyon
 
Enjoyed this Post?

Subscribe to our RSS Feed, Follow us on Twitter or simply recommend us to friends and colleagues!

By

Rollover to read this author's bio or click through to see a full list of posts by this author.

Pippin Williamson is a WordPress plugin developer that lives in Lawrence, KS. He runs a website called Pippin's Plugins.com which is dedicated to provided development education for aspiring WordPress plugin developers.  

Plus Premium
 
 
Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • http://www.guillaumevoisin.fr Guillaume

    For most part, I agree with you.

    However, when it comes to develop some functionalities that involve loading several pieces of stylesheets and scripts that are deeply linked to the theme, the benefits developing them inside the theme itself is that you can compact and combine those scripts alltogether which will improve performance.

    Also, even if I admit separating functional code from visual code is good and almost necessary, it’s not always easy to change the visual aspect of the site relying on code that is part of a plugin. You’ll have lots of additionnal checks on whether a plugin is active or not.

    Lastly, things are different when it comes to sell themes. You don’t necessarily want your functionalities to be used outside of your theme that is to say keep the code active and switch theme. By the way, you’ll have to edit the code of the new theme to use those functionnalities, it cannot it guess them.

    I totally agree with your thoughts though, there is no difference of performance, theme over plugin as long as the plugins are well written.

    Great article thanks!

    • http://pippinsplugins.com Pippin
      Author

      You bring up some very valid points.

      One thing I would mention, that was perhaps not super clear in the post, is that when I say separate “functions” into plugins, I don’t literally mean only the functionality bits. This “chunks” could also include stylesheets, javascript etc. For example, for a client site, I recently built a plugin that allows users to “love” gallery images. This plugin included the necessary functions to render the output (including styling and JS) and all of the functionality needed to process the “loves”. So this plugin was one large, complete “chunk”.

      A great example of themes that separate “functions” into plugins, are themes that utilize 3rd party plugins for contact forms. The theme provides all of the necessary styling and then just does a quick check to see if the plugin is active.

      I know a lot of premium theme sellers that are removing functions from their themes and relying on 3rd party plugins instead. The famous Orman Clark is a perfect example, and no one can say he’s not successful.

  • Lucas Rolff

    Actually, if you have 1000 plugins, or 1000 pieces of inline code – there is a difference in performance.

    When you have plugins, each time a page is loaded – WordPress will do a SQL query to wp_options, which contains enabled plugins, this string it will get, will be smaller the less plugins you have..

    But anyway, it’s maybe 0.0001ms

    • http://pippinsplugins.com Pippin
      Author

      Okay yes, technically that is true, but the difference would be so minimal it’d be almost impossible to measure, at least between say 5 and 200 plugins. Between 5 and 1000 plugins you could probably see a difference, but it’d still be extremely minuscule.

      • Gemma

        It’s probably even more minimal when you host with guys like WP Engine.

  • http://www.netbulae.eu Xander

    @Author:

    Everytime I look for a tutorial “without a plugin”, it is because I want to write my own code, rather than being a slave of the plugin author. I do not be dependent of his updates.
    It could be that I will create a plugin afterwards, just to seperate the code. Just for readability.

    Also, most times it happens that plugins contain a lot of code. Most things can be done with a few lines of codes. I rather build my own, rather than install some code I do not understand which could be bloated and unsafe.

    • http://pippinsplugins.com Pippin
      Author

      That’s a valid reason, but I’d advise you to not ever discredit code just because it happens to be in part of a plugin. You could open the file files and dissect the code just as easily as you could from a tutorial, assuming you have at least a basic knowledge of the way it works (which sounds like you do). Obviously this is not always the case for large plugins, but take small ones, such as those that hide the admin bar. These types of small plugins are rarely any different than the code that “without a plugin” tutorials often boast.

    • http://www.kriesi.at Kriesi

      Second that. I’ve written a fair share of tutorials with the mentioned “without a plugin” in the title.

      “Without a plugin” more often than not indicates that the visitor either wants to learn to code it himself or that the functionality that plugins provide are way to extensive.

      First time I encountered that was when I needed a breadcrumb plugin and pretty much the only available plugin was breadcrumb NavXT, which works great, but tries to so solve every possible problem one could have with breadcrumbs and therefore was much more than I needed.

      What I needed was a super simple solution that was finally written with 50 lines of code, without any option panels, db queries, etc. Of course this small snippet performs better than the extensive Breadcrumb Plugin, but of course it performs better because it does less, not because I added it to the theme code afterwards :)

      What I am trying to say is that I think most people know that if you put the exact same code into either a plugin or into the functions.php file there wont be a difference in performance. The difference comes from the fact that most plugins are bloated and custom solutions are usually more focused :)

      • http://pippinsplugins.com Pippin
        Author

        While that is definitely what “without a plugin” should (and often does) mean, I’ve found that it really has a different effect on non-developer users. The number of times I have had to explain to someone that placing code in a plugin is no different than a theme (in terms of performance) is crazy. I probably see this more as a plugin developer than most people, but it’s definitely prevalent.

        Last week I had an extensive conversation with a user that was following one of my tutorials. He was struggling because he wanted to move the plugin code over to his theme files, and the only reason he wanted to do that was because his boss told him that plugins are bad. The code was literally identical in both places, but it was still a struggle to convince him that using it as a plugin was just fine, and actually better.

        Tutorials like you mentioned (I’ve used your function btw, it’s great), are great, but I’d suggest renaming them to things like “Write a Simple Breadrumbs Function”. The fact that it is or is not a plugin should have nothing to do with it.

        • http://www.kriesi.at Kriesi

          Well, as you said, I guess it all comes down to personal experience. I havent met any people with the weird believe that plugins are bad. Most of them simply either want an all in one package (typical theme developers ;D) or dont need the 30 options that plugin X offers. I often recommend plugins to my customers and pretty much the only reason they prefer a built in solution is CSS styling ;D

          On the other hand I can totally see how you, as author of a number of very good plugins, will always end up with such requests from less educated customers :)

          • http://pippinsplugins.com Pippin
            Author

            After suggesting plugin X or plugin Y, do you ever have customers come back and say they’d prefer to avoid plugins? These are typically the users that believe plugins are bad simply because they’re plugins. At least in my experience.

          • http://www.kriesi.at Kriesi

            hm no, cant really remember that something like this happend before. Of course it did happen that users were not happy with the plugin solution because it didn’t do 100% what they wanted, but I have never had a “plugins eat children and make my site slow” response :D

    • http://jamesbanks.me James Banks

      Definitely agree with this point. Almost all plugins that I’ve ever used for my WP sites can be optimised one way or another. Compressing down the code and formatting it to my style of writing is often the first thing that I do after downloading a plugin.

      Keeping code tight, focused and compressed wherever possible and cutting away excess lard makes the functions a lot easier to manage, even if the performance gains are arguable on today’s modern high-speed connections.

  • http://keisermedia.com Lucas Keiser

    I have spent time in both realms and I find that most themes have coding problems if not incomplete functionality. Most of the time I run across a theme it is too limited in the basic functionality required of any theme. For example, I find that if the author adds a slider custom post type, there is no way for main slider to connect to posts rather than the cpt.

    In also find inbuilt code in themes to be rather annoying. What happens if you want to change your theme but you relied on shortcodes that are specific to that theme? I encourage people to find a plugin for shortcodes, which will span any theme, instead of using the theme functionality.

    • http://pippinsplugins.com Pippin
      Author

      Getting locked into a theme because of the features it provides is one of the greatest reasons to use plugins instead.

  • http://customct.com Richard Guay

    I totally agree with this article. I have “fixed” many themes that had their functionality (especially sliders) in their theme coded poorly that would mess up with certain plugins (for pay themes). Many times, that could of been avoided by using the standard way to load css and javascripts provided by WordPress instead of hardcoding into the theme template. Everyone complains that you can not place the code properly except in the theme. With proper use of shortcodes, this really is not the case and would give the user of the theme more flexibility in changing the theme to their need.

    • http://pippinsplugins.com Pippin
      Author

      Improperly loaded javascript is the single most common problem I run into when working with customers.

  • Roberto

    Very interesting topic. I have a question. Since putting theme functionalities into separate plugins seems the recommended course, what functionalities do you recommend keeping in functions.php or moving into a plugin?
    Say, should I make a plugin for activating menus? Should I make plugins for loading specific js libraries, like one for fancybox.js, another for sliderjs.js and so on? Should I make a plugin for handling custom column?
    Thank you in advance.

    • http://pippinsplugins.com Pippin
      Author

      It all depends on your scenario. If you are building a theme for distribution, then you should be cautious about what you place in plugins. Menus, for example, should always be registered in your theme, as they are an integral part of how the theme “appears”.

      Contact forms, social media sharing buttons, sliders, etc: these should be plugins.

  • http://cloudofthemes.com Connor Crosby

    I prefer “hard-writing” code into a theme than relying on plugins. As mentioned by Xander, I do not want to rely on someone else’s work and wait for them to make updates. I rather know what the code is and have it built into my theme files.

    • http://pippinsplugins.com Pippin
      Author

      What if they were your plugins? No one ever said you have to rely on others.

  • http://www.foralien.com Anna Ladoshkina

    It seems as there is some misconception about plugin as “3rd partly extension”, so that people generaly assume that it should be written by somebody else not them. So that when it comes to the the point “where should I add this piece of code” many think about theme, not plugin. But even for more experienced developer this choice could be tricky.

    Thank you for the valuable article.

    • http://pippinsplugins.com Pippin
      Author

      This is definitely true! If you look at some of the comments on this article even, you will see a couple people expressing disgruntlement about the idea of relying on third party extensions, so they just wrote their own instead. The point is that it doesn’t matter WHO wrote it, functionality items are still most often best in plugins.

  • http://prop-14.com Randy

    I think this is one of those things that shouldn’t be debated as “use plugins” vs. “don’t ever use plugins”.
    When the time comes to add functionality to a website I approach it as:

    - Is there an existing plugin that does what I need exactly?
    - Does the plugin make use of hooks and filters so I “can” interact if I need to customize?
    - Is this plugin well coded and well maintained?
    - Has this plugin been downloaded a lot (I only say this because it means it has been “tested” a lot)
    - What is the budget of the project? Can the client/project even “afford” to have me code this plugin from scratch?

    For example, I consider myself a decent php coder but I am certainly not going to code my own database backup plugin.

    Lastly, I think the real bonus of a plugin is that it has been tested by many users. I think it’s safe to assume we aren’t going to test a hand-coded plugin 500,000+ times as some plugins have?

    • http://pippinsplugins.com Pippin
      Author

      Excellent points. I would go one step further and ask whether there is a reason to re-invent the wheel? I find a lot of users that look for the “without a plugin” tutorials are simply looking for the code to avoid using a plugin all together, even when their is no reason other than “I don’t want a plugin”.

      When working on client sites, I often build custom functionality, but only when there isn’t a plugin that does exactly what I need. For example, if I need a simple (or advanced) events system, I’m going to use a plugin because their is no way that I’m going to build the events calendar system in any sort of efficient manner. And since events are typically a complicated process, I’d much rather rely on a plugin that has (like you said) been tested many, many times.

      • http://prop-14.com Randy

        I actually had a point for re-inventing the wheel but I thought my comment was getting too long, hehe.

        BTW – Studying well written plugin coding is the next best thing to using the codex IMO. I think people forget to use plugins even if only as a great learning resource.

  • Daniel

    Great post Pippin

    I completely agree with you. I personally think that most theme developers include all these functions in to a theme is because themes with many features sell better than the ones with less features.

    I personally prefer building plugins for the different features because I think it’s the same amount of work writing the code in to the functions.php file of the theme or building a plugin from it. The advantages are really the flexibility like you said. If I, or my client want to change the theme after a year or so then I have much less work doing that because the most features are already there.

    If I would build all these features in to the theme, I would need to copy/recreate them in to the new theme if I don’t want to mess up the site. Just think on shortcodes or SEO (meta tags) features. If these features are built in to the theme you always need to recreate/copy them in to the new one. If you don’t you’ll have a lot of work replaying all the shortcodes and rewriting the SEO meta tags for all the posts/pages.

    Just think of a client who buys a theme with many features and after a while he wants to change the theme because he wants one which does work well on mobile devices too. So he goes out to a marketplace and does purchase a theme he wants to install on his site, but this new theme does not have the same features. As soon as he recognizes the work he will have to change the theme, I’m sure he would prefer to have all these features in different plugins :-)

    • http://pippinsplugins.com Pippin
      Author

      Spot on, Daniel!

  • http://wpconsult.net Paul

    I totally agree with Pippin on using plugins for functionality rather than putting it in the theme. I think one of the reasons for this misconception is the trend in building feature rich themes for selling on theme marketplaces.
    A “software-like” theme is more attractive to the non technical user. And I often see the question: “please recommend a theme that does so and so”, rather than “please recommend a plugin that does x or z”
    Non techy users probably want to install a theme like they install MS Word on their computer. I’m not being condescending, I understand their position.
    An alternative if you want to bundle functionality with your themes is to use the excellent class by Thomas Griffin:
    http://tgmpluginactivation.com/

    • http://pippinsplugins.com Pippin
      Author

      Spot on. I was actually discussing that exact topic with some folks while at WordCamp San Francisco. Themes that have crazy features bundled always sell better, so it’s easy as a theme developer to include those “hot” features. Unfortunately, they just aren’t usually the best thing to include, when looking at it from a management perspective.

      • http://smithsrus.com/ Doug Smith

        I’ve often wondered if a theme seller could actually get some traction and increase sales by presenting the benefits of leaving those things out. You would have to answer the “what’s in it for me?” question in a well written way that really shows the advantages and helps the buyer emotionally move into that mindset.

        For example, tout not being locked in to the theme, reduced confusion and clutter in the interface, not slowing down your site if you don’t want that feature, and extol plugins that do the job better than any theme on the market.

        I could see putting something like that in the features on a theme’s sell page. A great example would be SEO features. Go ahead and put that bold SEO heading in the features list and then explain why it’s not built in like inferior competing themes and point to a couple great SEO plugins.

        • http://pippinsplugins.com Pippin
          Author

          Personally I respect theme authors much more that do make the conscious choice to exclude features. It really helps to separate theme authors into two groups: those that care about providing good systems and those that are only in it for the money.

        • http://webtuts.pl Aleksandra Laczek

          I think that the biggest advantage to built in functionality, is that it has integrated graphics. I certainly wouldn’t mind theme with less built in features, but I’d like it to support some popular plugins, like Contact Form 7 or WP Page Navi.

  • Aman

    I totally agree with Pippin and prefer plugins.
    But the problem I think people face (probably) (& perhaps sometimes me too) is the WordPress.org Plugin repository contains 20,000 plugins and not all plugins are up to the mark.
    There are only a dozen of plugins author like you who I can completely rely upon from coding standards to updates to support.

    • http://pippinsplugins.com Pippin
      Author

      There are definitely a lot of plugins to wade through, but if you look to the right sources, it’s usually pretty easy to locate a good one.

      • http://wpconsult.net PauldeWouters (@PauldeWouters)

        Matt mentioned a more Amazon like experience for the plugin repository, that would be awesome. If I could see plugin suggestions based on the ones I favorited, starred and downloaded.

      • Corey

        Do you have some good sources?

        I know of a handful myself, but it’d be great to list them out here for those who don’t have a clue. I’ll start!

        1) WordPress.org plugin repository

        • http://pippinsplugins.com Pippin
          Author

          One of the best resources is Twitter. Find active developers who are also active on Twitter and follow them. Plugin developers tend to tweet about other good plugins a lot ;)

  • tpk

    great article. I completely agree with the author.

  • http://www.metaphorcreations.com Joe

    Good article! I have just recently started making use of plugins to execute little bits of my own code. Sometimes just for testing purposes. I used to hard-code little php tests into my functions.php (or somewhere else), but then I always had to try and remember to comment out or remove the code before putting sites live… and then go back an un-comment or re-code it again if I needed it again. It’s much easier to just create a little plugin that is completely separate from the theme code and turn it on or off in the admin.

    • http://pippinsplugins.com Pippin
      Author

      Perfect example.

  • http://www.igmoweb.com Ignacio Cruz

    This topic was necessary.

    First af all, was necessary to demystify the common idea that plugins are like parasites that consume a lot of resources, kidnap your family and your dog and steal your money. No, they aren’t. They can be beautiful pieces of useful code.

    And second, and the most important point is that functionalities should be separated from visual. I have done some WP Themes that included shortcodes, special buttons and other stuff. Well, customer, get ready if you want to change your styles in your web ( I know, probably he’ll want to call me again). Separating those functionalities into little pieces of code should benefit the transit between themes, is a good idea and should be an extended practice when developing themes for selling. But…

    That leads me to think… What can we do about Custom Posts? Custom Posts are a great idea but make you Theme-dependant. Many times, themes are written around a Custom Post and its visual style depends on them. Should we put them in plugins and let the user choose in which page and where to show them or not?

    Thanks for your knowledge, Pippin.

    • http://pippinsplugins.com Pippin
      Author

      Figuring out what to do with custom post types is a great question. There are two ways that I think they should be handled:

      1. By plugins so that they are theme independent
      2. If by the theme, then all theme authors should start using a standard naming scheme for post types so that themes can be switched without losing data.

  • Pingback: Wordpress: A verdade sobre desempenho e plugins - [ Ferramentas Blog ] | [ Ferramentas Blog ]

  • Corey

    Another great article Pippin!

    As a theme designer/developer and amateur plugin developer I can say that you are absolutely correct in almost every way. I say “almost” just because some people have mentioned that they write their own plugins based off other plugins and/or include it in their theme. Some people just like control over everything and I think that’s alright.

    When I first got started in WordPress I did a ton of reading and I did indeed find a lot of tutorials that made it seem like plugins were not as good as theme code. Thanks to Pippin and some other WordPress folks, I was able to firmly establish in my mind that plugins are perfectly fine – as long as the code is good.

    Long story short: use all the plugins you want, as long as you do your research and (if you’re capable) check the code!

  • http://twitter.com/turtlepod david

    Hi pippin.

    I agree with you. But I have problem when I have to choose a functioanality should be in plugins vs theme.

    For example, cpt. I know that cpt should be in plugin, so when user switch theme, it’s still there. But most of cpt I create require custom styling and custom templates files.

    What’s your solutions for this?
    Thanks for a great article.

    • http://pippinsplugins.com Pippin
      Author

      Just because a custom post type is registered via a plugin doesn’t mean that the theme cannot provide template files and styling for it. For example, if you have a plugin that creates a “portfolio” post type, all you need to do to support it in your theme is create a single-portfolio.php and style it accordingly. If the post type is registered, that template file will be used, and if it’s not registered (because the plugin is inactive), it will just sit there harmlessly.

  • http://freakify.com/ Ahmad Awais

    Great post.
    I definitely am not a big fans of using plugins. I use plugins only for things like breakcrumbs, SEO etc.
    Even if someone after reading this article tends to deactivate some of his plugins I would recommend to delete them as they some of them leave left outs.

    I myself code things in my themes and I love them to be that way. It make my blog load fast and optimized sites have better SERP Rankings. I never said over optimized or extra optimized.
    Nice one !

    Cheers,
    Ahmad Awais (Freakify)

    • http://pippinsplugins.com Pippin
      Author

      I think you misunderstood the article. I’m advocating the use of plugins, not the disuse of them ;)

      A fast site and good SERP rankings have absolutely nothing to do with whether your code is placed in your theme or in a plugin.

  • Frederico Gorski

    Whole new approach to me! Thanks. But I have a question that maybe does not apply, I am not a developer. I manage the design of my website and am totally dependent to other theme and plugin developers to put my website running. That’s why I follow carefully these tutorials, to understand what’s going on, and deal better with it, without necessarily care about reinventing the wheel. So, my question is on the server side:

    Doesn’t a pletora of plugins make your site slower by consuming to many memory? Isn’t it a bit a matter of whether you are hosted properly with sufficient resources?

    I ask this cause I have followed many instructions from many websites to later find out I should also care about the amount of resources I could spend money on to run my site right now. Particularly, I have trusted a very famous cache plugin which have put me in lots of problem cause of the memory consumption.

    I don’t mean you lack some comments on that in your article, but these question came to me when reading it. Sometimes newbies like me who come to these kind of discussion don’t have the knowledge to understand other problems surrounding the matter.

    anyway, hope this contributes to the discussion.

    • http://pippinsplugins.com Pippin
      Author

      It is not the number of plugins that affect the memory consumption, but rather the tasks that each plugin is doing. If you have one plugin that performs a lot of tasks on every page load, or does a lot of database queries, it is going to cause a much more significant impact on memory consumption that 50 other plugins combined that all do simple, well executed tasks.

      It’s all about quality, not quantity.

      • Sascha

        Well written article Pippin but Frederico is right in this case. Not every plugin is “simple” and does “simple tasks” like you assumed. Some require more memory and produce more database connections by nature e.g shopping and database-backup plugins. Ever used them in a productive WP multisite environment? You will see it does affect your server performance… In this case quantity does count.

        There´s another point: a lot of plugins do connect to external services like facebook, flattr, etc. If you just run one of them it doesn´t matter, but if you are running 10+ of these service plugins in a WP multisite environment at the same time it could have negative effects.

        I understand your point, that this is a factor of programming quality in first place and not the plugin technology itself. But to be honest, I personaly believe that most free available plugins often lack quality.

        I´m running a WP network (with caching) with 10k+ views per day and in this case more then 50 active plugins do significantly slow down the site-network. Same configuration, but less than 1k page impressions per day and I had no negative effects at all. Most of them were “official” or paid plugins by the way. Also the servermonitoring obviously underlines the “more plugins slow down your site”-theory, but I believe it depends on the amount of pi. You can say I tested it in real life.

        I do fully agree with you, that if the code is of high quality it does make no or little difference, if you use a plugin or a theme integrated solution. But I don´t agree that you can use as many plugins as you like without negative effects. If these functions are written in the theme or a plugin makes no difference. In both cases it could have negative effects on your performance.
        BUT these “negative effects” are depending significantly on the amount of page impressions and the number/ complexity of active plugins. The more you have, the more likely are performance issues caused by plugins / themefunctions. I made the experience that both quality and quantity can cause negative performance effects.

        Besides the average pluginuser doesn´t have any php, js or just html knowledge. They´re just users not developers. In their point of view a “all-in-one” solution like a theme with all needed functionality is much simpler than a bunch of plugins. But this is more a psychological thing than a technical…

        It’s not all about quality.

        • http://pippinsplugins.com Pippin
          Author

          I never said all plugins are simple, at least not intentionally. That is far from the truth :)

          Of course the number of plugins matter when you have a lot of complex plugins that perform a lot of tasks, I would never disagree with that. And I didn’t mean to say that you can use a ton of plugins no matter what, I simply mean that the argument of keeping code inside of a theme because you don’t want to cause page load problems by having a lot of plugins is invalid.

          The code and what it does is really the only thing (in this particular discussion) that is going to impact performance; it doesn’t matter if that code is spread across 100 plugins or all kept in one massive plugins.

  • http://www.fluidwebstudio.com Jordan

    Interesting article, thanks. I have heard many different things about functions in themes vs plugins and this makes the most sense to me. If I develop a custom theme I would like to package it together, but I could see using third party plugins for forms and the like.

    It is good to know, sometimes I load up a lot of stuff in functions.php and I was wondering about performance. It seems that I can go either way with this and it really is no big deal.

    I see the advantages of plugins too.

    Thanks,

  • http://jasonhobbsllc.com Jason Hobbs

    I could not agree with you more Pippin. I heard or read somewhere from the WordCamp San Francisco that, I’m paraphrasing, “the WordPress.com pages load like 200 plugins on each load so don’t tell me plugins slow your site.”

    The point is the quality of code and the consistency in updates to the plugin going forward.

    There is a good amount of misinformation about the use of plugins and how they are bad for website performance, but thankfully those misconceptions are being cleared up for the non-coders to understand that the plugins are not inherently bad and, depending on your needs, they can work much better for users than cramming everything into the theme to be lost once the theme is deactivated.

    Any end users that want the functionality and not be married to their theme for life, should check out Pippin’s plugins. The support is fantastic, the updates are constant, and the code is excellent.

    • http://pippinsplugins.com Pippin
      Author

      Yep, that was said at WCSF, though I don’t remember who it came from.

      Thanks for the support as well :)

    • Sascha

      “the WordPress.com pages load like 200 plugins on each load so don’t tell me plugins slow your site.”

      Well that is not a valid proof. This has mainly two technical reasons:

      1. WordPress.com is running their own high performance server grid only dedicated to WP installations with over 1,500 servers in three SAS-70 Type II data centers. This is not comparable to the managed low-cost server providers that most WP users utilize.

      2. WordPress.com has a cloud structure, that means:
      a. The needed CPU and memory power is dynamicly allocated. And they have lots of these :)
      b. Also really important is that they´re using a horizontal database partition with external SQL servers. This database architecture does significantly increase server performance. I´m pretty sure on that, because I´m using the same structure for a customer.
      c. Perhaps not a real “cloud thing” but don´t forget WordPress.com infrastructure is adminized by server experts specialized on WP..

      Does the average WP user have these ressources?

      There´s eventualy another point: the number of 200 plugins says nothing about the complexity of them. A simple “comment” or “frontpage registration” plugin has different performance requirements than a full e-commerce solution.

      As I said above, the quality of code is important. But with increasing page impressions the quantity (depending on the complexity) of the plugins is also important.

      Always provided, that a adequate caching solution is utilized.

      • http://pippinsplugins.com Pippin
        Author

        Very good points.

  • http://webenvelopment.com Ben Racicot

    Either way each plugin gets its own stylesheet and other php files so that’s more http requests.. which is in fact slower and noticed by search engines. Writing these into your themes code would eliminate the http’s and there’d be no worry about anything conflicting.

    Right?

    • http://wp.envato.com/ Japh Thomson
      Staff

      Hey Ben, actually this isn’t really the case at all. If a plugin needs to load stylesheets and scripts, which not all plugins do, then if they’re called the correct way caching and minification plugins can bundle them all up together with the theme’s stylesheets and scripts anyway.

      This isn’t a problem inherent with plugins either. Loading those same stylesheets incorrectly through the theme would cause the same issues.

      It’s kind of going back to the argument of “but if you coded things poorly, then plugins are bad”, which also applies to anything (including themes). If you’re coding the right way with both themes and plugins, then there is no problem with having hundreds of plugins. If you code poorly, then even just the theme could be a massive performance issue.

      The real trouble is, how does a normal user identify a poorly coded theme or plugin…

      • http://pippinsplugins.com Pippin
        Author

        Yep, Japh is exactly correctly. I’d also add that including extra .php files into a plugin does not use HTTP requests, so doing that does not slow your site at all.

      • http://webenvelopment.com Ben Racicot

        “caching and minification plugins can bundle them all up together with the theme’s stylesheets and scripts anyway.”

        Whoa! Well that sounds like an entire tutorial I would read a couple times over. Writing your plugins to take advantage of however to get that to minify and combine correctly is something I don’t know if I’m doing right or wrong.

  • http://www.lecklin.fi Tuomas Lecklin

    Excellent article Pippin, thank you!

    Text was so good it made me check out your website, and I immediately found something of interest to purchase for my projects. Really impressive stuff.

    Btw, your base url gives the unsecure/unverified certificate page on at least mobile Chrome. Mobile version doesn’t even respond to proceed anyway.

    • http://pippinsplugins.com Pippin
      Author

      Thanks Tuomas. I’m aware of some of the https issues and am working on getting them fixed up.

  • http://ubergeni.us/ Kevin

    I think when most people say to stay away from plugins, they are referring to the fact that the majority of plugins out there run shit code, to be honest. There are plugins all over that either use deprecated functions, are loaded with extra bullshit JS and CSS files, perform multiple (unnecessary) queries on every page load, or don’t cache results, and thats just to name a few of the issues that I have found with plugins that have tens and sometimes hundreds of thousands of downloads.

    As far as do I create my own plugin or do I build the functionality into the theme, I decide if I’m going to publish it in the Plugin Directory and if so I build it as a plugin. But, if the client is asking for something specific (and you’re not building a theme to sell, but actual client work), it should really be baked into the theme since it is specific to the theme. Why take the time to strip out bullshit and correct the plugin someone else wrote when I can write my own and know that it is specifically what the client wants? This doesn’t mean its acceptable to have a never ending functions.php file, but instead you should create theme specific plugins that contain their own classes consisting of their “chunk” of code and give them their own folders within the themes file structure you prefer.

    • http://pippinsplugins.com Pippin
      Author

      There are definitely a LOT of bad plugins out there, but there are also a ton of great ones.

      Even when working on client sites, I’d still advocate separating some of your features into actual plugins, not just pieces within the theme. I wouldn’t usually do it on small sites, but have found it to be extremely helpful on really large sites.

      • http://ubergeni.us/ Kevin

        In what was did you find it to be helpful on the really larger sites? The fact that it was separated from the rest of the theme in the directory structure? As I said, I already do this by providing each separate piece of functionality within its own classes and directory structure. (i.e. wp-content/themes/theme_name/plugins/plugin_name1/plugin.php ). Except being able to share the code on the WordPress.org plugin directory, I really don’t see any benefit.

        Another reason I stay away from working with plugins that have to reside within the plugins directory is because I work with WordPress VIP often, and there is no wp-content/plugins directory. You have to instead do as I said and load each plugin or section of code with a custom function or just a include or require.

        • http://pippinsplugins.com Pippin
          Author

          In terms of overall functionality, it really doesn’t make any difference where it is. The key point, however, is that the pieces are literally separated from the theme, meaning that you can remove/deactivate any one of them without touching any theme files. There are times this is very important.

          That’s a very good point about VIP.

  • Pingback: Various geek stuff « @ITGeek on … most everything/anything

  • Pingback: les escaliers

  • Ray

    Great article, makes a lot of sense. For rooks like myself who don’t know much coding though, how do we determine whether a plugin is of good quality or not?

    • http://pippinsplugins.com Pippin
      Author

      A couple of ways:

      1. How long has it been around? If it has been around for a long time, does it have a decent rating? Ratings do NOT always mean a plugin is good or bad, but a ton of 1 or 5 star ratings tend to at least give a decent idea.

      2. Check the support forums (or whatever support method the plugin has). If you see that the author is responsive and fixes issues, then you’re probably in good hands. If, however, you see lots of unresolved issues and a general lack-of-presence by the developer, then you may want to avoid it. But, keep in mind, not all authors are able to support their plugins. Just because an author doesn’t support it does not mean it’s not good code.

  • mrto2

    Any tutorial for working on functionality within the theme? e.g. Main slider …

  • Pingback: Битва за функциональность: плагины против тем | Wordpresso

  • Pingback: The functionality plugin lets you take your custom functions with you! | Christmas Webmaster

  • Pingback: Site Specific Plugin vs. Functions.php

  • Pingback: Site Specific Plugin vs. Functions.php | WPhub.biz

  • Pingback: Why Loading Your Own jQuery is Irresponsible | Pippins Plugins

  • Pingback: Плагины WordPress. Польза или вред? | Дневник Блоггера

  • http://www.facebook.com/mittul.chauhan Mittul Chauhan

    I was also one of these believers that plugins cause performance issues..

    but now i come to the reality .. thank god its not true ..

    coz i also like to put my different functionalities to different plugins with customization which really helps me when i find my self in any trouble ..

    “Plugins are only evil when built poorly. ” thats true .. thanks for this very well written tutorial ..

  • http://jameswoo.net/ James Woo

    Good article especially for a non programmer/developer. Always thought that too many plugins are bad news. Based on the comments, looks like bad code + overloaded server = problems

    Assuming that those of us on shared hosting (i.e. with limited resources) the more plugin, the heavier the load it places on the server no matter how well written the plugin is? Granted a well writtsen plugin will require the minimal resources compared to a badly coded one, right?