Here’s a fix. It will be rolled out in the next update.
In /includes/functions.php replace lines 371-373:
OLD (remove)
// setup the class for the link
if ( $bsp_style_settings_buttons['button_type'] == 2 ) $class = $bsp_style_settings_buttons['Buttonclass'];
else $class = 'bsp_button1';
NEW (add)
// setup the class for the link
$class = 'bsp_button1';
if ( ! empty( $bsp_style_settings_buttons['button_type'] ) && ! empty( $bsp_style_settings_buttons['Buttonclass'] ) ) {
if ( $bsp_style_settings_buttons['button_type'] == 2 ) $class = $bsp_style_settings_buttons['Buttonclass'];
}
@robin-w – same kind of extra checks and changes should be added to functions:
bsp_new_topic_button() (lines 305-306)
bsp_unread button() (lines 318-319)
bsp_display_reply_button() (lines 402-403)
and bsp_profile_link() (lines 449-450).
It’s happening when no values are present for button type and button class.
@keith_saunders – I want to encourage you to disable displaying debug messages to the public on the frontend of your site. It can make your site vulnerable by revealing hacker-friendly information to people who don’t need to see it. Debug messages are very good and helpful, but can be a liability if not managed correctly.
I recommend changing WP_DEBUG_DISPLAY to false, and using a plugin like DebugPress to select which user roles you want to be able to see debug information (ideally only admins).
With a plugin like that, you can still see debug messages, but they’ll be in a pretty interface. You can always view the debug log directly, which is a good idea to do every once in a while (usually /wp-content/debug.log).
-
This reply was modified 2 years ago by
codejp3. Reason: edited for easier readability on functions to edit