I also have error with BuddyPress:
WordPress version 6.0.1
Active theme: OneCommunity Child Theme (version )
BuddyPress (version 10.3.0)
PHP version 8.1.0
Uncaught Error: Class "BP_Admin" not found in ..../wp-content/plugins/buddypress/bp-core/bp-core-admin.php:20
It works ok, if I set PHP to 7.4 version.
Site works ok with PHP 8.1.0 if i disable BuddyPress plugin.
Hi thanks for your feedback and sorry you’re having trouble between BP & PHP 8.0. I also use it but can’t manage to reproduce your issue. You can fix this trouble easily though. You simply need to add the following code:
<?php
remove_filter( 'block_editor_rest_api_preload_paths', 'bp_blocks_preload_paths' );
into a bp-custom.php file and put it in /wp-content/plugins as explained here: https://codex.buddypress.org/themes/bp-custom-php/
Hi Mathieu, thank you for this suggestion, but I’m sorry to report that this does not fix the error for me.
First I added a bp-custom.php file containing your code, following the instructions you linked to, and the same fatal error still occurred on any attempt to add a new page or post.
Next, I tried deactivating ALL plugins except for BuddyPress, and switching to the Twenty Twenty theme. This error still occurs, even when the only plugin active is BuddyPress, on a default WP theme, both with the new bp-custom.php file and without it. I did this on the development environment for the site: https://edrmdev.wpengine.com/
So I’m really at a loss, having tried every recommended troubleshooting technique.
Is there anything else you can suggest?
I’m happy to test anything that might work.
@wcholbi I’m able to replicate the issue and I have a fix for this here: https://github.com/buddypress/BP-REST/pull/450
Thanks for reporting the bug.
Thank you @espellcaste !
I tried editing my line 101 of /wp-content/plugins/buddypress/bp-core/classes/class-bp-rest-components-endpoint.php as shown in your fix, and I am still getting the same fatal error when trying to add a new post. I will wait and see what happens with your Github pull request (in case I am somehow applying the fix incorrectly).
I’m more hopeful now, knowing progress is being made. And I’m still happy to test fixes.
@wcholbi Could you share the error you are getting after applying my patch?
@espellcaste it looks like the same error message from my original post (to me at least), which is why I’m wondering if I’m applying the fix incorrectly.
All I did was edit line 101 of /wp-content/plugins/buddypress/bp-core/classes/class-bp-rest-components-endpoint.php to read:
if ( 'optional' !== $type && ! empty( $components['core'] ) ) {
and when I try to add a new WP post, I get the “There has been a critical error on your website” message, and the PHP error log shows this:
PHP Fatal error: Uncaught TypeError: Cannot access offset of type string on string in /nas/content/live/edrmdev/wp-content/plugins/buddypress/bp-core/classes/class-bp-rest-components-endpoint.php:102\nStack trace:\n#0 /nas/content/live/edrmdev/wp-includes/rest-api/class-wp-rest-server.php(1143): BP_REST_Components_Endpoint->get_items(Object(WP_REST_Request))\n#1 /nas/content/live/edrmdev/wp-includes/rest-api/class-wp-rest-server.php(990): WP_REST_Server->respond_to_request(Object(WP_REST_Request), '/buddypress/v1/...', Array, NULL)\n#2 /nas/content/live/edrmdev/wp-includes/rest-api.php(519): WP_REST_Server->dispatch(Object(WP_REST_Request))\n#3 /nas/content/live/edrmdev/wp-includes/rest-api.php(2868): rest_do_request(Object(WP_REST_Request))\n#4 [internal function]: rest_preload_api_request(Array, '/buddypress/v1/...')\n#5 /nas/content/live/edrmdev/wp-includes/block-editor.php(601): array_reduce(Array, 'rest_preload_ap...', Array)\n#6 /nas/content/live/edrmdev/wp-admin/edit-form-blocks.php(75): block_editor_rest_api_preload(Array, Object(WP_Block_Editor_Context))\n#7 /nas/content/live/edrmdev/wp-admin/post-new.php(72): require('/nas/content/li...')\n#8 {main}\n thrown in /nas/content/live/edrmdev/wp-content/plugins/buddypress/bp-core/classes/class-bp-rest-components-endpoint.php on line 102, referer: https://edrmdev.wpengine.com/wp-admin/edit.php
Should I be doing something differently?
@wcholbi Thank you for trying that again.
I’m still unable to replicate this issue but I think I know why that’s happening. Could you apply this patch and test it?
if ( 'optional' !== $type && ! empty( $components['core'] ) ) {
$active_components['core'] = '1';
}
@espellcaste I appreciate your response and I’m sorry to report that I’m still getting the same fatal PHP error (referencing the same filenames and line numbers), even after applying your latest patch.
I went to double check the github pull request here, and applied both of the changes shown there (lines 102 and 111).
I also tried it both with and without @imath ‘s bp-custom.php suggestion from earlier in the thread.
Let me know what I can try next.
@wcholbi Odd! Could you var_dump the $active_components as suggested below?
var_dump( $active_components );
if ( 'optional' !== $type && ! empty( $components['core'] ) ) {
$active_components['core'] = '1';
}
Could you also type cast this as an array? On line 98.
$active_components = apply_filters( 'bp_active_components', (array) bp_get_option( 'bp-active-components' ) );
I think this is coming as a string where it should be an array.
@espellcaste I’m delighted to say this works!
To be specific:
Adding var_dump( $active_components ); before line 101 displayed string(0) "" at the top of the “there has been a critical error” screen.
Replacing line 98 with your fix resulted in me being able to add a new post or page with no errors reported.
Also, just to indulge my own curiosity, I went back and reverted the previous two changes (line 101-102 and line 111), so that the only change to the file was the one to line 98, and it still works (no fatal error).
So that indicates to me that the line 98 fix, which (not sure of the correct terminology) provides an array instead of a string to the next line, is the true fix of the original problem. The changes to lines 101-102 and 111 didn’t seem to hurt anything, and I couldn’t tell what they did, but if they represent code improvements, so much the better!
In my original research into the error Cannot access offset of type string on string, I saw people talking about the code expecting an array where a string was provided, but I just didn’t know enough PHP to figure out what to change.
Huge THANK YOU for persevering with me on this!
Awesome! Sorry for not seeing that at first. In my tests, I always get an array for bp_get_option( 'bp-active-components' ), so I did not see it as a possible bug at first.
Glad we sorted this out! =D
Following up on this because the 3 versions of BuddyPress that have been released since this issue was fixed don’t seem to include the fix.
I just verified on a test site that the error still happens with BuddyPress 10.6.0, and looking at the /wp-content/plugins/buddypress/bp-core/classes/class-bp-rest-components-endpoint.php file, line 98 doesn’t include @espellcaste ‘s fix (which I thought was approved/merged in Github).
Do I need to create a Trac ticket or do something else to get this fix into the next release of BuddyPress? I looked at the Roadmap for 10.7.0 and 11.0 and I don’t see this fix, but I’m not super familiar with Trac so I’m not sure if I’m reading things right.
