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:
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.
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.
During our latest dev-chat, we’ve been talking about putting together a documentation site for the BP REST API. I’ve been exploring the subject more deeply this week and I believe we should take this opportunity to try to ship a first version of the developer resources site.
I think 5.0.0 is an interesting time/release (as it’s a very developer oriented one with the inclusion of the BP REST API) to start powering BuddyPress developers with some resources just like WordPress does with its DevHub project.
The « BP » DevHub project?
@tw2113 started working on a BuddyPress Code Reference site 3 years ago, see #6812. In his last comment he expressed his concern about the lack of developer content the site would offer. Then I thought the BP REST API documentation could be a great companion to this BuddyPress Code Reference! So I’ve carried on his work and built a local test site to check how difficult it could be to make this real.
Preview of the homepage of the Developer resources site.
It’s doable before the 5.0.0 release!
It took me a couple of days, following and adapting the installation steps described in this chapter of the WordPress Documentation handbook, to build a « proof of concept » framework. Actually all I had to do was to create a child theme for the « wporg-developer » theme and share 2 patches on the Meta Trac (see #4516 & #4517) so that the Meta Team could fix the 2 issues I’ve found during my explorations.
Install/Build the latest version of BuddyPress 😍 (no need to activate it).
Run the WP CLI command using the BuddyPress directory of point 5 as the argument. For example: wp parser create path/to/wp-content/plugins/buddypress --user=1 or wp parser create path/to/wp-content/plugins/buddypress/build --user=1 if trunk is used.
Install & activate the Handbook plugin (We don’t need the wporg-markdown & wporg-cli plugins as we don’t write our documentation on GitHub and moreover it would import the WordPress REST API and Coding standards documentations).
Install & activate the « bporg-developer » child theme I’ve built using the Customizer live preview (so that it automatically creates the starter content – make sure the fresh_site option has its value set to 1).
Go to the General Settings Administration screen and insert the version of BuddyPress into the BuddyPress latest stable version option.
Wait, but what about the BP REST API Documentation?
If you’d go on the BP REST API Handbook at this stage you wouldn’t see any content. We need to create it. We chose to have it generated thanks to the REST schemas of our REST endpoints. The Restsplain plugin does this task for all the WordPress and custom endpoints of the website.
Using it as it would first mean to activate BuddyPress (and possibly the BP REST plugin if not yet included into BuddyPress).
There are benefits of having the generated documentation this way as new endpoints would automatically be included. It’s also possible to create and attached content to our endpoints using the post type included inside the plugin. But there are also disadvantages:
All BuddyPress components would need to be activated.
The React Application inside the Restsplain plugin is displaying the real URLs at various places.
It is also including a feature to use them into a specific container to make real REST requests.
The good new is: we can filter the list of endpoints the Restsplain plugin is generating. So I’ve added this filter to the bporg-developer theme and the documentation generation is now restricted to BuddyPress endpoints. Then I thought we could avoid the need for BuddyPress to be activated by first looking for an external Json file (a static copy of the array expected by Restsplain, where links are « anonamisized »).
But still, I had to remove completely the live testing of endpoints feature. Although it can be done in CSS, I chose to edit the plugin because:
it has not been updated for 7 months and as a result contains outdated node modules and React library.
Some real links are built in React using the rest base URL.
One of the link of the React endpoint viewes is triggering the live testing.
As a result the version of the plugin I suggest to use is the fork I’ve made here. As I’ve edited the React part, I also edited the styles to match the BuddyPress.org colors. Here’s how it looks:
As you can see it’s very different from the output made by the WordPress handbook plugin. The best I could do to make it more looking like it was to use the [restsplain] shortcode in a page.
That’s why I think we should probably only use this plugin to write a static version into the BP REST API handbook post type of what it generates dynamically.
We have 14 endpoints to document for 5.0.0 and 8 others for the 6.0.0 release and I think we can do some copy/pasting: it won’t take too much time and the layout of the documentation will be the same for every potential handbooks (eg: BuddyPress plugins or themes).
Moreover we’ll be able to improve the navigation grouping endpoints by components, we’ll be able to use more meaningful titles for the GET, POST, PATCH, DELETE methods, eg: Get a specific user, add a user, update a user and remove a user. Finally we would be able to use code examples using our bp.apiRequest function instead of the fetch function Restsplain uses. Below is a screenshot showing what I mean about this copy/pasting task.
What if we’re running out of time building the developer resources site?
It would be too bad, but not a so much big deal! I’ve already created a documentation site for the BP REST API. You can test it here. We would simply need to attach to this site a more meaningful domain name 😉
And when/if we get the developer.buddypress.org site ready (See the 9 steps above) soon enough we’ll be able to use this website to do the copy/pasting tasks.
Let’s discuss about it during our next dev-chat!
As a reminder, it will happen this Wednesday (June 26) at 19:00 UTC into our Slack channel: #BuddyPress. All BuddyPress Contributors are very welcome to join us. If you’re a bit intimidated (you shouldn’t!) but still want to give us your opinion about this topic, please use the comments area below 👍
I think they are going to post another update soon about whatever they format standardise on, but this is something BuddyPress should also try to do going forward.
BP Dev Updates 