[buddypress-trac] [BuddyPress] #4470: BuddyPress Singleton

[buddypress-trac at lists.automattic.com]

#4470: BuddyPress Singleton
------------------------------+------------------------------
 Reporter:  johnjamesjacoby   |       Owner:  johnjamesjacoby
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  1.7
Component:  Core              |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |
------------------------------+------------------------------

Comment (by foxly):

 > The lengthy clean-up efforts of 1.5 and 1.6 enable us to work towards a
 goal of protecting
 > third party plugins from each other, preventing users of BuddyPress
 powered sites from seeing
 > wp_die() messages they shouldn't see, and protect BuddyPress developers
 from themselves and
 > each other, similar to WordPress's _doing_it_wrong() function.


 Developers don't need to be protected from either themselves or each
 other.

 When you design a system that idiots can use, only idiots will use it; and
 in the coding world, those idiots will also burn tremendous amounts of
 your time and trash you all over the internet while doing so.

 This is Wordpress, not Windows.

 You're working in a common memory space with a staggering array of
 dangerous functions that let other developers do practically anything they
 want to your code. Leave it open. Design for failure. By making even a
 token attempt to 'nerf' your code, you'll end up with the *worst* of
 *both* situations: something that's difficult to mess with when you need
 to and impossible to stop others from messing with when you don't.

 The fact that people are 'messing' with Buddypress in the first place
 means its design is flawed.

 Either:

 1) Your design doesn't work properly and they're messing with it to make
 it work properly
 2) You have inadequate documentation
 3) You've failed to provide an interface surface that other developers
 want
 4) Or your code monolithic, excessively complicated, and difficult to
 trace


 Here's an example of why people are 'messing' with Buddypress.

 See: example-01.jpg

 Practically every client I work with that has group forums enabled on
 their site asks me to remove the "Home" tab from their forums. That's
 because, due to bad design decisions, the home tab offers confusingly
 similar, redundant, functionality to the group's forum and doesn't
 synchronize with it.

 So how would another developer remove that tab?

 See: example-02.jpg

 Well, first they'd probably check your codex. Unfortunately, the search
 function on it is broken, and has been for more than a year.

 See: example-03.jpg

 Next, they'd probably check Google ...and a *lot* of people are clearly
 doing that, because it's #4 on the auto-suggest dropdown and #1 out of
 24,000 results. If they follow the top link, it points to a 5-page long
 thread on the BP forums that's been going for 2.5 years, includes horribly
 out-of-date information, and '''has 2 out of 3 members of the core BP dev
 team''' flat-out saying "tamper with the $bp global to fix the problem".

 But, even using the most current solution posted in the thread, the tab
 persists.


 {{{
 function bbg_remove_send_invites_from_group() {
         bp_core_remove_nav_item( bp_get_current_group_slug(), 'send-
 invites' );
 }
 add_action( 'bp_setup_nav', 'bbg_remove_send_invites_from_group' );
 }}}

 At this point, you've lost 95% of your customers, although people that
 code for a living would start to go hunting. Only experienced developers
 would know to use ctrl-shift-f to search the entire plugin source tree for
 bp_core_remove_nav_item(), which has been cleverly hidden in a file called
 bp-core-buddybar.php.

 Totally thought to look there.

 See: example-04.jpg

 Examining the source file, its obvious at least one of these methods has
 '''incorrect documentation''', since they can't both do the same thing.
 Because none of the function headers in the file have a @version or @since
 tag, we have to start guessing.

 The correct function is bp_core_remove_subnav_item(), and it works as
 expected for most of the tabs on the groups screen. However, when we call
 bp_core_remove_nav_item( bp_get_current_group_slug(), 'home' ); it 404's
 the page.

 There are maybe twenty people in the *entire world* that fully understand
 why this would happen.

 See example-06.jpg, example-07.jpg

 The first root cause is located beside the red square in the screen
 capture. Because your team '''didn't follow good code formatting
 standards''' its hidden from view on even a widescreen monitor. The second
 root cause happens because you made a design assumption in bp-groups-
 loader.php that invalidates the interface you offer through
 bp_core_remove_nav_item().

 At this point, there's '''no practical option left except directly
 modifying the $bp global variable'''; and if you block plugins from
 modifying the global $bp variable, the only remaining option is to '''fork
 Buddypress'''.

 In this example, you've failed on all four counts:

 Your base design doesn't work properly. You've provided not only
 inadequate, but flat-out wrong documentation. You haven't provided a
 centralized interface surface to get a common set of tasks done, and
 you've hidden the functions that actually do the job in all sorts of
 obscure places.

 In addition to this, while I've skipped over it in this example to save
 time, it would take another developer *days* of work to trace through the
 code and understand how your routing system works well enough to remove
 the tab's screen.

 That's simply unacceptable. Especially considering that we wrote you a
 faster, easier to understand, and better documented class that's a drop-in
 replacement for the offending code, and sent it in almost eight months
 ago.

 Other developers aren't 'messing' with Buddypress because they don't know
 what they're doing; they're messing with Buddypress because, in many
 cases, '''you''' didn't know what you were doing, and they're going to
 '''continue''' 'messing' with Buddypress until you fix the problems that
 made them mess with it in the first place.

 The best thing you can do to fix all these problems is get your unit tests
 built: the simple act of testing your code, and the challenges you'll face
 in doing so, will straighten out your architecture and coding practices
 incredibly quickly.

 Razor will find practically every design flaw in Buddypress and kick your
 ass until you fix it.

 Write some tests. You'll see ... :)

 -F

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4470#comment:8>
BuddyPress <http://buddypress.org/>
BuddyPress