Some users have asked me why “Toolbar Extras” is required as a base plugin, so that an Add-On like “Toolbar Extras for Oxygen Builder” or the other official Add-Ons can be used. And the next questions that are implied with the first are those: “Why I have to install another plugin to run this (Xyz Add-On)?”, and, “Why is the Xyz Add-On not a standalone plugin?”
These are good questions, and I can totally understand where those users are coming from. Let me explain the background story for all of that:
Toolbar Extras Does the Heavy Lifting
It provides the complete base functionality for what it does AND its Add-Ons. This means all hook places for the Toolbar, all the settings for disabling certain groups, items and sections. And it provides lots of logic, string and helper functions. The reason is simple: so that this code is only there ONCE and needs not to be replicated in any Add-On or standalone plugin.
Toolbar Extras loads its features – all its stuff to be precise – only when it is needed. This especially applies to all and any integrations aka supported theme and/ or plugin. If a theme/ plugin is not activated, the items in Toolbar Extras won’t even be loaded. Period.
In consequence, this means in a vanilla WordPress installation with only Toolbar Extras, it can do already a lot of really useful and smart stuff just because it has lots of stuff built-in for WordPress Core. And then, if you happen to have maybe one supported plugin active, then it can do a little bit extra on top – but only as long as this other plugin is activated.
Modular Approach / Add-On Model
The splitting in a base plugin – which already does the most – plus specific Add-Ons is better for maintenance, faster updates (and bug fixing) and even for developing new features. It is as simple as that.
The Add-On model allows for more specific use cases and to target specific user communities, for example the product Oxygen Builder and its community. Oxygen Builder does not need a theme and even disables it in WordPress. So this requires also for my Toolbar Extras Add-On some specific code to cover these specialties. This is best done via an extra Add-On where this code is separated from the main codebase.
Let’s think of this comparison: Add-Ons are to Toolbar Extras what plugins are to WordPress – an extension. And, Toolbar Extras works fully the WordPress way, with Hooks and Filters, too. A smart (plugin) Add-On API if you want :-).
Let’s give an example, setting a default Page Builder in Toolbar Extras: I learned that a lot of users have more than one Page Builder installed and activated (for whatever reason, not our topic here). Toolbar Extras handles that but only allows for the Toolbar to be one Builder having the priority at a time to place its items there. With this approach the space in the Toolbar gets not too crowded and can still be useful. Add-Ons now can register other Builders (plus settings) so users can choose between more options. This can happen dynamically and independently from the base plugin. Even third-party authors could develop Add-Ons for Toolbar Extras completely independent from me (David Decker), release them at any time and have them doing their specific stuff.
With only one standalone plugin some of the above would also be possible but not all and not as smart as with the Add-On model: the base plugin does all general things behind the scenes and the Add-Ons dynamically and optionally add specific things on top. Only the Add-On model ensures that an API-like structure is implemented that works the way WordPress itself is laid out. This also strengthens the flexibility of the plugin internally, and makes it open for better customization with the WordPress concept of Hooks and Filters.
The Toolbar in WordPress Is “Global”
This might sound “simple” but it has a lot of consequences: The Toolbar in WordPress is a “global” thing that was added to mostly only serve WordPress Core. That is the reason why this Toolbar we have is somewhat limited. Therefore the base plugin, Toolbar Extras, tries to work with these limitations and somehow to overcome or work around them. Consider this an extra “logic layer”.
With this “logic layer” there, the Add-Ons for Toolbar Extras can work for specific use cases and environments. The base plugin behind the scenes manages all these relationships in the “global space” between WordPress Core, the theme, the Builder tool, and, of course, other plugins. Without the modular Add-On approach you would end up with an un-maintainable “monster plugin”. Not a second, that would make any sense.
I Have Used the Standalone Model – It Didn’t Work!
And, last but not least: I have been there, in the standalone Toolbar plugin model. Before Toolbar Extras, I did 10 (!) other single/ standalone Toolbar-specific plugins. While they all worked perfectly on its own it would have not made any sense to use all of those ten plugins together in the same install. — Why, would you ask? Simply, because there was no “logic layer” behind the scenes, which would have managed all the relations between those different plugin tools and use cases.
To take this real-life example further, you would have ended up with 10 new top-level Toolbar items – no settings to disable or re-hook them, nothing (only for code-savvy users…). Out of this frustration and dead-end road I figured out that the Add-On approach would solve my “issue”.
Essentially, this issue was, that I was not aware that the Toolbar was indeed a global thing (see above). There is NO Toolbar for Oxygen alone, not one for WordPress alone, Genesis, Elementor, Astra, WooCommerce, whatever, you name it. You can only solve it when working together.
This was my big aha moment when I realized that why my approach from about 6, 7 years ago did not fully work at the end. Thanks to Toolbar Extras and its “global vision”, together with the Add-On approach I was and am finally able, to bring my real vision from years ago into reality now.