Getting back to what @frooyo asked at the start…
Since the future is that bbPress will be a plug-in of WordPress, does that still allow bbPress itself to have plugin capability? Because essentially then, any plugin of bbPress would be a plugin of plugin to WordPress.
Plugins would be managed in a single interface. They would use the regular WordPress functions to add admin-area functionality, and to add action hooks and insert themselves into the filter processing. The issue is which actions and which filters are registered in a given plugin. As bbPress is migrated to being a plugin the developers will make sure that it will broadcast its own actions, separate from WordPress, when it makes sense to, and share action/filter hooks when it makes sense. For instance, I could see the “talk like a pirate” plugin for WordPress being shared between bbPress and WordPress on a given site.
In addition to action and filter hooks being distinct between the two systems, or shared in certain cases, it’s entirely possible to write code that a plugin registers with, separate from the main WordPress. Take for instance the current “Topic Icons” plugin that allows other plugins to register new “rules” on how to apply icons. This capability allowed the “Topic Icons” plugin to support skinning the “Support Forums” icon set without ever needing to be coded into the core “Topic Icons” plugin – people who dont run “Support Forums” never need activate that piece of code. What I’m getting at here is that one plugin can register and talk to another – there just has to be a little care about how its done; if bbPress becomes a WordPress plugin, there’s nothing to stop it having its own sub-set of plugins specific to it.
How would the Admin interface look for bbPress within WordPress
Its very easy to add a new top-level menu item in the admin interface, its just not something plugin writers normally do. In the case of bbPress, I could see a “forum” menu being added that then contains a sub-menu of management pages specific to bbPress. That said, we get user and theme management for free from the main WordPress.
@bobtheman – you asked an interesting question
on a side note, this sorta makes you want to ask yourself, will every project that automattic picks up be transformed into a worpdress plugin?
It’s been said that “when all you have is a hammer, all the worlds problems look like a nail”
The fact is, WordPress is a thoroughly versatile foundation to build upon. To quote another software engineering saying, “it isnt code re-use the second time some code gets used – that’s just a happy accident. Code re-use doesnt happen until the third and subsequent time.”
What do I mean here? Simply this: the foundations of WordPress (user management, theming, admin, plugins, etc) are great. They make a solid basis for building from. BuddyPress started down that road and by a “happy accident” made use of the features. Now we are looking at bbPress and saying “wow – code re-use!” but there are large slabs of code that will not be used when you’re a bbPress user/admin. The thing which needs to happen is to look, now that a third (WP, BP, bbP) project is building on the same backend, and refactor the truly common code into a modular WP-Core that is lean-and-mean, and the additional functionality builds upon. We have an opportunity to drive the architecture of WordPress into a better place as bbPress becomes a plugin.
For instance, what if I want to swap out and run my WordPress against Microsoft Active Directory for all the user management thereby gaining single-signon in a corporate shop? Impossible right now, but if the core is more modular, maybe it would be possible. If the core were more modular, then an install of bbPress need not drag the entire WordPress codebase along with it.
