post

Limitations of a Core Functionality Plugin

I love working with Gary Jones (@garyj) of Gamajo Tech. Every time I talk with him, discuss any thing development related, I learn something. In a recent “conversation,” he said:

I’m not keen on Core Functionality plugins—it’s still one plugin that has many roles, all of which could (and therefore should) be separated out.

To me, this single comment caused me to think and analyze the role of the Core Functionality plugin. As I thought about my site and client sites I have created, I think he’s identified a major weakness of a Core Functionality plugin.

As such, I believe it has two essential limitations:

  1. Difficult Post-Development Workflow
  2. Potentially, Poor Post-Deployment User/Client Experience

In development, as a developer my goal is to develop as quickly as possible for two reasons: more projects and better client experience. In doing this, it is great to place all the site’s functionality into a single plugin that serves as a glorified functions.php file. To me, it also leads to less code bloat with the ability not to have to place functions and classes (e.g., Metaboxes) in each plugin wrapped in a conditional.

if ( function_exists( 'foo' ) ) {
function foo( $param ) {
echo $param;
}
}

So, using a single core functionality made it easy to rinse and repeat. However, using only a single core functionality plugin or a site-specific plugin, while having its advantages, can be problematic. As Gary specifically illustrated to me, generalizing his example, let’s say you have a core functionality plugin (or a functions.php file run rampant) that contains several different custom post types and functionality extensions. Then something breaks with a single, specific custom post type or functionality extension that is developed within the core functionality plugin. This can cause a domino affect of issues within the site, maybe even the dreaded white screen of death.

One cannot simply disable the core functionality plugin in production/live site and begin to fix the issue in their staging or local development environments. Disabling the core functionality plugin essentially would remove some of their content (based on custom post types in the core functionality plugin) from visibility (not that it would be removed from the database), or even break the entire site. Instead, with a set of smaller plugins, only the specific plugin causing the issue needs to be disabled.

(Note: No developer would ever assure that their code will always work on the site forever as clients enable other plugins that may cause conflicts, change the code, current plugins become upgraded or even deprecated, and WordPress core is ever changing, growing, developing, and improving.)

As a result of using only a single core functionality plugin, the client now has a problem in identifying the issue and re-mediating the issue forcing them to hire someone else to fix the problem immediately.

Then, as Gary notes, the client is paying more because the developer has to take extra time to troubleshoot the code and find the issue, which is frustrating for developers.

Instead, not using only a single core functionality plugin, the client has options. This becomes very client-centric, which leads to loyal clients and more work. The client then can determine whether they need that functionality on their site (and I have seen clients rightly choose this may times over). Or, they can decide when they could fix it within their timeline and their cash flow. Simply, it creates a better post-production client experience.

Please do not get me wrong. I believe that the core functionality, site-specific plugin has its place, especially in extending a theme, a child theme, skinning a theme/child theme, or in creating a grandchild theme.

What are your thoughts? Do you see any other limitations or disadvantages?

About Travis Smith

As a WordPress Enthusiast, Travis writes about his journey in WordPress trying to help other WordPress travelers and enthusiasts with tutorials, explanations, & demonstrations of the things he learns.

Comments

  1. Nice post & interesting topic! On principle I agree that it’s best to keep plugins (core or otherwise) limited in scope.
    A well programmed functionality (as plugin of in functions.php) should have solid error handling, something which quite a number of plugins and themes lack. Basic testing should include the ‘whatifitfailscatastrophically’ scenario. If a plugin fails it should be limited in scope to its functionality.
    I tend to group functionality per plugin and limit dependecies when possible. You’ll never eliminate all dependencies but it does make it easier to find the cause and fix it.

  2. I love the idea of the plugins page being almost like a glorified settings page. Having plugins be very specific so you can turn features on/off by activating/deactivating plugins.

  3. The problem is typically one of time… The client wants it done now and when it’s done and working, they don’t want to pay for the time to go back and clean it up. Of course, you could develop it properly as you go, but that slows you down and you get the 200 “is it done yet” emails a day.

    Darned if you do and darned if you don’t.

  4. Great post. Just had a paradigm shift and will develop this way moving forward. Doing it this way may slow dev down for the moment but would most likely save time in the future. Take time to save time.

    Also, grandchild themes… they exist?

Leave a Reply

%d bloggers like this: