[buddypress-trac] [BuddyPress Trac] #8148: A new direction regarding optional components management
noreply at wordpress.org
Wed Oct 23 05:32:53 UTC 2019
#8148: A new direction regarding optional components management
Reporter: imath | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: 6.0.0
Component: Core | Version:
Severity: normal | Resolution:
Keywords: has-patch |
Comment (by 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
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
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
[https://plugins.trac.wordpress.org/browser/buddypress/assets 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.
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
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 😉
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8148#comment:2>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac