3

I could not find a thread discussing this, so starting this one.

I am currently working on a rather elaborate theme for 3.1+, and by elaborate I mean that in addition to styling and regular front-end functionality, I am including plugins at the core of the theme, both for back-end and front-end. So, to keep this a little more organized, I split this into three questions:

  1. Is integrating plugins a common practice?
  2. What are the implications/complications in regards to auto-updating the theme/plugins?
  3. What would be the most optimized way of including each plugin without breaking pre-existing functionality?
Improve this question
3
  • 1
    All the answers below are excellent, so I'll just add a caveat here: try to ensure that Theme code deals with content presentation, and leave content generation to Plugins.
    – Chip Bennett
    Commented Apr 8, 2011 at 16:27
  • @Chip Bennet That is indeed the classical definition of what a theme should do. However, the line between the two is somewhat more blurred: Altering functionality within presentation, such as a generic anti-spam plugin is normally considered reserved for just plugins. But could it not be an integral part of the theme, as the theme usually deals with both comment presentation and behavior? I do agree with your point, and it is truly the most classical way of going about a theme, but I am hoping to expand certain aspects of themes to go beyond that.
    – OleVik
    Commented Apr 8, 2011 at 17:30
  • Sure, you could have your Theme handle anti-spam functionality, rather than respect the classical differentiation. You can also eschew CSS for the classical differentiation of presentation and style. I wouldn't advise either one, though. :) The reason to separate presentation from functionality is preservation of functionality should the current Theme be changed. A user would (rightfully) expect his anti-spam functionality to work the same, regardless of what Theme he is using.
    – Chip Bennett
    Commented Apr 8, 2011 at 17:58

3 Answers 3

Reset to default
2

1) Is integrating plugins a common practice?

Not really. Normally you got a theme that offers a base functionality. You then only extend the theme with plugins for special purpose like twitter stuff, event calendars, etc.

Imo it makes sense. I'm currently working on an extremly slim theme that has some plugins (OOP approach) that get delivered as plugins, but are not bundled. These plugins offer template tags for pagination, breadcrumbs, ... even the loop with post formats. I like the idea of only offering functionality if the user really wants it. For ex. the comment system is rarely needed if you use WP as a CMS for a buisness homepage, so why should the theme offer this? Another pro for this approach: You just disable the plugin and exchange the template tags with custom stuff if you don't need it.

Important with this approach is: Don't place those template tags directly. Use hooks & filters wrapped up in functions, so your theme doesn't crash because of undefined function calls if you disabled a plugin.

2) What are the implications/complications in regards to auto-updating the theme/plugins?

This is something i'm currently questioning myself. I thought about a massive routine that checks for updates on both the theme and the plugins, but overall: It makes no sense. Imo it's even better if you just use the builtin update system (or use some custom class if you're not hosting at the official repo). Why: You only update what really needs to get updated. This saves some time and energy, so i'd even call it the "greener" way to go.

3) What would be the most optimized way of including each plugin without breaking pre-existing functionality?

What exactly is in your case pre-existing functionality?

Function Names

WordPress got around 2.500 functions that get read on a request. So questioning if ( function_exists('whatever') ) is never a good idea. Better use unique names. @Jan Fabry had a good idea: He prefixes all his answer functions over here with wpse and the number of the Q - example: wpse14277_function_name(). A 4 or 5 digit number combined with alphas will likely stay unique. Imagine that you got 50 custom functions in your theme and are questioning them against 2.500 per Request (you can do the math yourself) - that's not performant.
Edit:
If you just want to know if a plugin is active, then use the is_plugin_active() conditional tag.

Improve this answer
3
  • 1) Yes, I take the point about bloat and excessive functionality. However, if I made them modular rather than integrated, they would serve the purpose of being included with the theme rather than having to be downloaded. 2) Is there any way to split a theme or parts of a theme into a Git-like system, so only differential upgrades are necessary? 3) As discussed with @Drew Gourley, the function_exists only comes into place on a top-level, to check for plugin existance.
    – OleVik
    Commented Apr 8, 2011 at 15:42
  • Ad 1) Serving plugins with themes imo is not a good idea. It's hard to copy files around (chmod) and else. In this case i'd suggest to simply integrate it into the theme. Ad 2) No, not really. But you could maybe add something like a versionnumber constant to every file and check against that and then only update the changed files. Seems a lot of work just to get this structure. Ad 3) See edit in A.
    – kaiser
    Commented Apr 8, 2011 at 18:10
  • Addition: If you use an OOP approach, then you can also question if the class exists. The number of loaded classes it around 10% of the total functions loaded.
    – kaiser
    Commented Apr 12, 2011 at 11:51
1
  1. Yes, anything you build into functions.php could technically be re-purposed into a plugin and distributed, the same goes in reverse.
  2. You will have to handle the versioning aspect a little differently. With plugins, every time you make a change, you have to update just that plugin. With a theme, every little change will update the entire theme. This isn't a big deal, really, it actually may be a little more convenient, since WordPress will alert users when a theme update is available the same way it alerts for plugins.
  3. Make sure you rename the functions to make them unique, otherwise you'll run into crashes when functions are re-declared. I find it easiest to pre-pend the function with your theme name. plugin_function() would become theme_plugin_function().

If you find that your functions.php is getting a little hefty and disorganized, you may create more .php files in your theme to help organize things, then call those files in functions.php via include_once('path/filename.php').

Improve this answer
2
  • In regards to 3; Even if I rename the functions, their functionality would still apply. Would I be better off using the original-plugin name together with if (function_exists), seeing as that would just give just one of them permission to operate?
    – OleVik
    Commented Apr 8, 2011 at 13:30
  • Actually, this is a much better solution than renaming the functions, sort of a way to include pre-installed plugins, whether or not the user already has them installed.
    – Drew Gourley
    Commented Apr 8, 2011 at 13:56
1

Just to be clear, are you talking about including code that already exists as standalone full-featured plugins?

Is integrating plugins a common practice?

Integrating code in general in themes is common practice. However bundling excessive amounts of code and functionality, commonly realized with normal plugins, is viewed by some as feature bloat and trying to lock users into your theme.

What are the implications/complications in regards to auto-updating the theme/plugins?

Update overwrites everything with new version.

What would be the most optimized way of including each plugin without breaking pre-existing functionality?

This heavily depends on specifics of what plugin does, how is it coded and if it is required for your theme to function at all or is merely extra functionality.

Improve this answer
1
  • Yes, basically using existing plugins but implementing them on a theme-level (activated with the theme). For example, I am developing a comment system that is similiar to Disqus. The plugin will exist as a standalone-plugin, as well as a integral part of the theme. The problem I guess, is that it should not be installed with the theme if another comment-system is in place, or if the plugin is already installed. But what is the optimal way of getting around such issues?
    – OleVik
    Commented Apr 8, 2011 at 13:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.