Extend WordPress Plugins screen to allow Admins to easily install features as a plugin

[imath]

In 10.0.0 we'll explore 2 new features as a plugin:

• BP Rewrites : to test using the WP Rewrite API to replace our legacy URL parser
• BP Attachments : to test a new User Media component, making sure to let users choose to install it or not as there are already a lot of Media Components available for BuddyPress.

These 2 plugins will be hosted on WordPress.org Plugin directory when ready and the BuddyPress settings adaptations goal is to give administrator a shortcut to install these plugins without having to Use the Add Plugins WordPress screen to search, install and activate them.

---

Previous summary: A new direction regarding optional components management

Previous description:

In short: I’m suggesting to progressively migrate optional components as BuddyPress plugins, starting by making the BP Attachments component (I’m working on for 6.0.0) a plugin.

Why?

1. BuddyPress is becoming a really huge plugin (zip is 3 MO which represent 1/4 of WordPress size), making us hesitant about adding new components.
2. Only keeping the Core + Members components in BuddyPress can open new opportunities for hesitant users who only need to organize users on the front-end (or to build on top of a lightweight BuddyPress).
3. We could welcome new components & contributors to improve BuddyPress popularity. Being listed into the “BuddyPress” Plugins sub directory could be very interesting for developers.
4. Components could evolved at a different rhythm than core and be updated as soon as they need to be.
5. Users would have a real and wider choice for their community site: they could trust “BuddyPress supported components” packaged as plugins.
6. We have a strength: the WordPress Plugins Directory API, making it very easy to install new components, we just need to list the ones we support to ease their discoverability. (Some alternative paid softwares do not have this advantage).
7. It seems the natural evolution of Components when we look at the Components management screen which look like the Plugins management screen.
8. With the “space economy” we could include new tools like an API to handle huge upgrades which would be very interesting for any plugins.

How ?

• A simple JSON file hosted into the assets directory of our WP repository (​like this one) would be enough to build the BuddyPress Components directory.
• The BuddyPress Components directory replaces the “retired” view of our Components Management screen.
• A simplified installation/activation process so that it’s not taking too long for users to add new components to their community site.
• The attached patch can give you a better idea of how it could look like. Below is a link to a video demonstration of it.

​https://vimeo.com/367830458

Possible steps

• 6.0.0: no more new components into Core. BP Attachments is the first Component as a plugin. It's easily installable from the BuddyPress Components directory.
• 7.0.0: the Site Tracking and Private Message components migrate as plugin,
• 8.0.0: the Friends and Account Settings components migrate as plugins.
• 9.0.0: the Notifications and Groups components migrate as plugins.
• 10.0.0: the Activity component migrates as a plugin.

Let’s talk about it!

[johnjamesjacoby]

I'm going to provide a series of responses. Anything that reads as me disagreeing, is just me poking holes in ideas to try and have a dialog, and isn't meant to be shutting anything down or being negative.

1. The hugeness shouldn't bother us. BuddyPress provides immense value at a third the size of WordPress. This was an original concern with the folks working on BP Media, needing to package huge codecs and such. It could easily be that for BP Attachments, too. But... things are what they are. If it takes 50MB to solve the problem correctly, so be it!

2. Core + Members doesn't really provide a whole lot of intrinsic value, because those Members still can't do anything but comment. They won't even have profiles (well... they'll still have the non-extended ones, provided that still works!)

3. This was always a great idea, and one I'd like to see come back somehow. It's somewhat of a maintenance burden, about the size of what the Plugin Review team does already. To fully implement this, we'd likely want to communicate what our intentions are, and make sure to be available to them.

4. If a component inside of BuddyPress needed love, and if we had the time, we could release a new version with enhancements to any core component at any time. Everything being in a monolithic repository hasn't prevented progress yet. Similar to WordPress, I believe there is still immense value in everything being "packaged" together natively, rather than requiring additional research & discovery.

5. In an ideal world, every component could have alternatives, including Core & Members. If these components are "native applications" inside of BuddyPress, they should be hot-swappable, to allow some other different/better component to take their place. Deep within the Core of BuddyPress, this is actually achievable, though I've seen zero people take advantage of this ability or API.

6. Absolutely agree with this. Leveraging the existing WordPress.org plugins repository is definitely the way to do this. There's literally nothing currently to gain in maintaining a separate system.

7. The Components admin screen was specifically modeled after the Plugins screen, so that it would feel familiar. Many different plugins with their own ecosystems have invented much more tailored UI than what BuddyPress has, but I'm generally not a fan of introducing more things to interface with unless they are solving other real problems, like accessibility, etc... I'm all for making these use a card-like UI, but we should hug closely to existing conventions and try not to be too inventive.

8. People are able to use the WordPress.org repository currently, and we had previously pulled plugins in tagged with "buddypress" into a page on buddypress.org/plugins, but the duplication and fragmentation was weird and unappealing to most users. In addition, we used to use BuddyPress Groups and Group Forums to give them all a place to offer support. All of this is still re'doable, but it's hard to know if these are things we need again, or things we could do, or want, etc...

[imath]

Thanks a lot for your feedbacks @johnjamesjacoby 😍 I agree we need time to discuss about this suggestion.

BuddyPress provides immense value at a third the size of WordPress

I agree 💯

I think there are 2 ways: the BuddyPress or JetPack way (everything is inside) and the WooCommerce way (uses Plugins and includes a specific Plugins directory). Both ways have advantages and disadvantages of course.

(The funny thing about this suggestion is that it first came up to my mind because of a very limited configured server, I wasn't able to install BuddyPress because its size exceeded the Max Upload file size allowed 😆. I guess this must be very unusual in most cases).

I believe there is still immense value in everything being "packaged" together natively, rather than requiring additional research & discovery

Having features inside external plugins does not necessarily mean there are not there when you activate BuddyPress. For instance when you install WooCommerce you silently get additional plugins (JetPack, WooCommerce Services, the Gateway extension plugin, etc) corresponding to your payment options and the first settings you selected during the installation process.

So we can still have the default components there as plugins on first install, and make sure to fetch the needed plugins if the ones activated are no more included during an upgrade.

It also does not mean BuddyPress plugins would be maintained in external repositories. I believe we can & should carry on maintaining all existing and new components from this SVN repository.

The main difference from having everything packaged against available as plugins would be modularity. With the Plugins way, you can easily remove/replace a feature completely.

I simply believe moving to a Components as Plugins model is giving us and users more freedom.

More freedom for users because:

• they can get what they need at any time without extra "dormant" features they don't need.
• they can have more choices and trust these choices because they are powered & maintained by the BuddyPress community.

More freedom for us because we can try new things without being limited with backward compatibility. There's now a huge gap between WordPress 5.+ and WordPress 4.7 (the version we need to still support) and the gap is increasing fast. Having plugins evolving on their side could allow us to keep a version making sure to satisfy our back compatibility requirements (because I agree it's important) and introduce new versions to satisfy the users who would like to enjoy the latest and innovative features or "breaking" changes.

Having a separate & more BuddyPress focused place to install BuddyPress components can give some new interests to BuddyPress plugin developers: today as you said the WordPress.org Plugin Directory "tag" system is not reliable (mostly because of people abusing it probably), that's why I've used a specific hand made selection of plugins using a JSON file. We only need to make sure this file is hosted outside of the BuddyPress plugin to easily update it without updating BuddyPress. The ​assets sub directory of our WordPress.org repo seems a nice place to host it.

It's also a way to show we are very open (I know we already are) and welcoming new contributors seems very important because unfortunately we're not eternals and what matters most is the project & not the individuals contributing to it.

To fully implement this, we'd likely want to communicate what our intentions are, and make sure to be available to them.

Absolutely. If some new contributors were interested to have their plugin listed into the "BuddyPress sub directory" or if we were asking a plugin author to be listed into it, my suggestions about this would be that this would require these authors an "agreement" asking them:

• to join the team,
• to contribute to BuddyPress Core codebase and new BuddyPress Core or BuddyPress plugins versions beta tests,
• to contribute to documentations & support forums.
• to provide at least 3 years of Plugins maintenance and to find a successor when they have no more time to maintain the plugin.
• Components as plugins listed should always be fully featured, free and without any ads.
• TBD.

One another advantage of only having Core + Members: it would allow some plugins to use BuddyPress to provide their front end users profile. For instance, users are often asking me "Why do I get BuddyPress users profiles, WooCommerce users profiles (or account), ACF users profiles etc.. Why isn't it possible to have a unique profile ?"

People are able to use the WordPress.org repository currently... we used to use BuddyPress Groups and Group Forums to give them all a place to offer support

Yes well, I'd say having more than 54,000 plugins available in the WordPress.org repository is great but it's also a problem for the reasons you mentioned. Discovering trustable BuddyPress plugins is hard for users. There's a project to have a Blocks directory, I think it makes sense for us to have a BuddyPress Components Plugins subdirectory inside of the WordPress site BuddyPress is activated on. I don't think we need to provide something more on BuddyPress.org for example.

but I'm generally not a fan of introducing more things to interface with unless they are solving other real problems, like accessibility, etc... I'm all for making these use a card-like UI, but we should hug closely to existing conventions and try not to be too inventive

Like the the video demonstration shows: it can simply be a replacement of the "retired" tab. I know there is a screen in the video/patch showing a card style UI, but this screen it there to quickly benefit from the WordPress "shiny updates" feature and more precisely from their installing queue management. I agree we should simplify this screen and make it look like our Components management interface.

Of course I'm not sure the "Plugins way" is the best way, I feel it can improve our modularity. Whatever road we'll take I'm totally fine with it 👌.

I'm happy to continue the conversation about this suggestion 😉

[shawfactor]

This is not neccesarily an either or.

Realistically this approach could be be tested with the attachments "canonical" plugin in 7.0 and if the model worked well back fill it to the other components.

[imath]

During our latest dev-chat we talked about this ticket to help us make our features as a plugin easier to install and test (eg: BP Rewrites, BP Attachments). Let's adapt the patch for this new goal during 10.0

[imath]

In ​8148.2.patch, I'm suggesting to make things easier as a first step. The patch is simply adding a new patch to the Add Plugins WP Admin Screen to list the features as plugin such as the BP Rewrites (which should be ready a bit before our 10.0.0 release. Here's a screenshot of how it looks:

The trick to have our plugins/blocks populate the list is to use the ​`buddypress` WP.org account to favorite them. Unfortunately the Plugins API is not providing an "include" argument. The benefit of using favorites will be that we'll be able to update the list without updating BuddyPress.

@johnjamesjacoby could you use this account to favorite ​BP Beta Tester so that we can have 1 plugin into the list 😉 ?

We'll probably need to create a specific page on the codex to explain what is a feature as a plugin copying ​this one's text for example.

[johnjamesjacoby]

@johnjamesjacoby could you use this account to favorite BP Beta Tester so that we can have 1 plugin into the list 😉 ?

Done!

[imath]

In 13163:

Add a tab to the WP Admin Add Plugin screen to easily get BP Add-ons

BuddyPress Add-ons are features as Plugins or Blocks maintained by the BuddyPress development team & hosted on the WordPress.org plugins directory. Thanks to this new tab, Admins will be able to find these Add-ons faster and will eventually contribute to beta features early to give the BuddyPress development team their feedbacks.

Props johnjamesjacoby

See #8148

[imath]

In 13164:

Use an XHR request to dismiss the BP Add-ons screen welcome panel

This commit also improves oursrc/js folder to be able to generate Modern JavaScript files for BP Admin screens. It starts with removing the need to add a dependency to jQuery for the BP Add-ons screen and the WP-Admin extended profile screen.

Fixes #8148