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.

@wp_smith Great post. The other missing point: smaller plugins make it easier for future devs to find code.

— Gary Jones (@GaryJ) February 12, 2014

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?