Support » Plugin: Heartbeat Control » Unnecessary Bloat

  • Resolved zigpress


    Why does this plugin now include the CMB2 plugin? Hundreds of extra files when the plugin’s functionality could be achieved in one file?

    • This topic was modified 3 years ago by zigpress.
Viewing 2 replies - 1 through 2 (of 2 total)
  • Justin Sternberg


    Hello, I am the author of the CMB2 plugin.

    I’m not familiar with the Heartbeat Control plugin, however I am familiar with CMB2, obviously. CMB2 is intentionally built in a way to be able to be bundled into other plugins with minimal effort by the plugin author, and to provide plug & play solutions for adding fields, forms, metaboxes, settings, etc.

    To clarify on that point, CMB2 is built so that it can be bundled with any number of plugins, your theme, as well as the CMB2 plugin itself being installed, and it intelligently loads only one version of itself at a time (the most current version). This ensures there are no compatibility issues, or function/class collision errors. This also means, it’s entirely possible that CMB2 is already in use in your system if your theme or another plugin has it bundled. By using CMB2, plugins are able to actually decrease bloat in some cases since multiple plugins/theme/etc are all depending on the one library, loaded once, rather than multiple systems/code-bases all doing the same work. If every plugin built a bespoke system for outputting fields, escaping their values, sanitizing and storing those values, including the right hooks in the right place to allow other plugins or the theme to modify it, you would actually end up with much more bloat on your system.

    As for number of files… A large number of files in the CMB2 plugin are translation files which allow the CMB2 text strings to be properly translated in many languages. Again, this helps the broader ecosystem as there are far fewer custom translations needed for each plugin which bundles CMB2.
    CMB2 also leverages a class file autoloader. This means we purposefully split functionality into distinct classes wherever possible so that if certain functionality is not used, it is not included/loaded into the system’s memory. This means that the number of files can actually result in an improvement to your system’s performance.

    Again, it’s unfair to expect every plugin to build their fields/forms/settings/file-inclusion patterns with the level of care and level of effort that has gone into CMB2, and also brings me to my final point.

    CMB2 helps minimize the barrier to entry for many busy plugin developers like Jeff, such that they are able to quickly prototype and release effective and helpful solutions such as this plugin without having to worry about large chunks of code which are simply supportive to the plugin’s main goals. Providing the stable CMB2 platform for others to stand on is all about why we do what we do, and is exactly why libraries (bootstrap, jQuery, React, Font Awesome) are so popular and helpful.

    I’m not speaking for Jeff and this plugin or arguing that your main point is incorrect, but simply wanted to provide a peek behind the curtain as to what CMB2 is all about.

    • This reply was modified 3 years ago by Justin Sternberg. Reason: typos
    • This reply was modified 3 years ago by Justin Sternberg. Reason: more typos, shocking i know
    Plugin Author Jeff Matson


    @jsternberg hit the nail on the head. I chose to use CMB2 to save time, and ensure the settings page aspects require less maintenance on my end. Since CMB2 is a library that multiple major agencies maintain, I felt it was a reliable choice.

    There are a lot of files, but it has zero negative impact on performance. I wouldn’t worry about it in the slightest.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Unnecessary Bloat’ is closed to new replies.