Since update 2 days ago

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 3 years, 3 months ago by codejp3. Reason: edited for easier readability on functions to edit