For quite a long time, BuddyPress users has regularly requested us to improve how the plugin’s JavaScript and Style assets are loaded into the front-end of their WordPress site.

How come BP JavaScript and CSS files are loaded everywhere on my site?

A BuddyPress user probably wishing it wasn’t the case!

That’s the question I’m often asked about BuddyPress, maybe you wondered about it too 😁. We’re not sure there’s a specific reason explaining this fact. As it was necessary before we introduced the BP Theme Compat API (see the 1.7 version announcement post) to use a BuddyPress compatible theme like the one we bundle by default (BP Default), I think we kept the way this theme was loading these assets into the first Template Pack (BP Legacy) we added to BuddyPress.

Let’s only load what we need when we need it… progressively!

In version 11.0.0 we are taking a first step towards restricting JavaScript and Style assets loading to BuddyPress pages only (or what I also call the community area of your WordPress site). To take no risks with potential BP plugins or themes needing these assets, we will carry on loading these everywhere on your site in 11.0.0. BUT if you want to avoid this, you now have an easy way to only have these loaded into the community area of your site. Simply put a bp-custom.php file in place (or use the one you already put in place) and add the following code into it:

add_filter( 'bp_enqueue_assets_in_bp_pages_only', '__return_true' );

If using the above filter, you notice something is going wrong with your website due to the use of a specific BP plugin or theme, report it here and we’ll then have another development cycle to fix things before we completely restrict these assets to BuddyPress generated pages in a second step & in version 12.0.0.

To read more about the story of this change, you can have a look at this ticket #8679.

#11-0-0, #developer-documentation

During a development cycle, we can deprecate functions the plugin is not using anymore. In this case we are moving this deprecated code into a specific file named according to the BuddyPress version when it was deprecated. For example, the bp_insert_site_hook() function was deprecated during the 10.0.0 development cycle and was moved into the /bp-core/deprecated/10.0.php file.

Before 11.0.0, deprecated code was never loaded when BuddyPress was first installed or if the BP_IGNORE_DEPRECATED constant was set to true. Deprecated code was only loaded if this constant wasn’t set to true and if BuddyPress has been regularly upgraded since version 2.7. This means if you first installed version 8.0.0 of BuddyPress, deprecated code was never loaded. This was wrong considering BuddyPress Plugin and Theme authors who were not able to be informed by setting their WP_DEBUG constant to true that a function was deprecated (and eventually replaced by another one) and no more available.

Starting in 11.0.0, we’re improving our deprecated code loading strategy

First we are keeping these 2 behaviors from previous versions:

• Deprecated code is never loaded when you first install BuddyPress.
• Deprecated code is not loaded when you define the BP_IGNORE_DEPRECATED constant to true.

Second we’re introducing a new constant to force all deprecated code to be loaded: BP_LOAD_DEPRECATED. Defining this constant to true can help you to identify deprecated functions one of your plugins or you active theme is still using although it shouldn’t.

Third, when BuddyPress has been upgraded, we are loading the code that was deprecated during the 2 previous versions.

To read more about the story of this change, you can have a look at this ticket #8687.

At the time I’m writing these lines, we’ve started the 11.0.0 beta testing period. As this change is pretty important, we strongly advise BuddyPress Plugin and Theme authors to test BuddyPress 11.0.0 pre-versions.

#11-0-0, #developer-documentation