WordPress themes and plugins usually work pretty much by themselves, coming together only when it comes to implementing features. This is usually managed by having the correct widget areas available in the theme’s template files, so that the user can drop the plugin’s widget where it should be, or by actually putting plugin PHP code snippets into the theme. And sometimes the plugins will output or activate the functionality by use of the WordPress hooks, which in essence means that the theme only has to comply with WordPress to trigger the plugins. It is all pretty straightforward.
However, there is one case where themes and plugins collide, and that’s when functions.php comes into play. The theme file can do more or less anything a plugin can, which means that it can be an optional solution for a publisher that normally would require a plugin. It also means that functions.php can clash with plugins, if used without caution.
In short, there is a good rule for when to use a plugin: everything that extends WordPress functionality should be a plugin. This means that if you add something to WordPress that you wouldn’t be able to do otherwise, you should do the actual addition with a plugin. What that addition of functionality actually is would of course depend on what needs you have, but anything from added data management to integration with third-party apps would qualify.
However, there’s a big grey area here. A lot of plugins are actually mimicking WordPress and its loop, such as recent post listings and similar solutions that exist so that the user won’t have to create a lot of custom loops within the theme. They do that for you, and they do it in a more user-friendly fashion, with options pages that set up the custom loop for you, and widgets that let you drop them wherever you like. Compare that to having to actually write the loop code and put it in your theme file to be output where you want to. That may not seem like a big deal to you and me, but for most users, it is a real hassle. The loop is, after all, a scary thing.
So what it boils down to isn’t only if the plugin has any reason to exist according to the rule mentioned above, but also what needs the actual users have. That isn’t to be forgotten, since a Word- Press site isn’t much use if the people maintaining it can’t seem to understand how it works.
Custom fields are another example. They are great for a lot of things, as has been covered already and will be shown to an even greater extent later, but at the same time they aren’t exactly easy to use, with a bulky interface and so on. A plugin can do the same thing, and in fact use custom fields, but with a sleeker interface. That is something to consider since it can potentially make updating the site easier. When opting for the plugin solution over the functions.php option, or comparing the use of a plugin with a custom hack in the theme, you need to consider the following things:
A positive answer to all these means that you should go ahead with your plugin. If you can’t provide anything additional, you should really think things through again.
Nobody likes a slow-loading site, no matter how flashy it is. How fast it needs to be, and how much patience the visitor will have, depends on the target audience and kind of content being served. After all, Flash intro pages are still fairly common, and they should really not exist unless there is an audience for them.
All those things aside, no site should be slower than it needs to be, and a sure way to bloat your WordPress site is to fill it to the brim with plugin-powered functionality. Think about it: most plugins needs to be initialized to work when the visitor encounters their functionality on the site, and that in turn can mean anything from running a PHP function (at the very least), to a full-sized loop with database queries. Say you have 10 plugins on a page, and each one initializes a loop and outputs relevant database content. That will not only take time, it will also put additional strain on the server, possibly making it move sluggishly.
The thing is, a lot of plugins are really the loop in disguise. If you’re displaying posts, comments, tags, or anything that builds around that, you’re really querying the database. It is just like putting all those custom loops in your theme and watching them spin. Now, a decent server won’t mind this, but a lot of visitors at the same time can bring it to its knees. Database queries are heavy stuff, so you should be wary of having too many of those on the same page without the hardware to back it up.
The same goes for other types of functionality, from simple PHP functions to inclusion of thirdparty content. True, the biggest issue with these things comes whenever you fetch something from outside the server, which means that you’ll be relying not only on your own host’s hardware, but also the speed that the content can be reached (in other words, the speed of the Internet), and how quickly the target server can serve you the content. That is why a bunch of widgets pulling data from various services online will slow down any site out there. The lesson is to not use too many plugins that put a strain on the server. That way you’ll keep site load times as low as possible.
Our website is not responsible for the information contained by this article. Webworldarticles.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
This article was sent to us by:
Leonardo Ferolli at
05132010
1. Creating Your Own Wordpress Template Tags
All articles in this directory are property of their respective authors. Additionally, read our Privacy Policy
© 2010 WebWorldarticles.com - All Rights Reserved.