codejp3

FYI – I’ve been working on a big update, restructuring the admin settings page. Those changes have fixed this bug. Unfortunately, I can’t release the fix as a simple patch to the existing 5.3.5 release due to the new code being a complete overhaul of how tabs/settings are handled which is not compatible with the current plugin as-is. It’s a complete overhaul that brings all tabs, option groups, and settings fields into a new defined standard that should help prevent any mysterious bugs like this in the future.

@robin-w – don’t worry, all existing plugin settings will work fine and transfer over to the new revision without any issues.

@metesey – I wish I could publish a fix for you sooner, but it will be taken care of in an upcoming release. Sorry for the delay!

If you’re using a menu plugin, try the support forum for that plugin.

If you’re using a theme that handles the menu, try the support forum for that theme.

If you’re using default WP menus, try the general WP support forum.

I’m able to replicate it consistently now. Reset the settings for Topic/Reply Form, then walk through the initial steps:

In the “Topic/Reply Form” settings tab > #10, click to activate posting rules for both topics and replies.

In the Topics posting rules textarea I put “Test TOPIC rule”

In the Replies posting rules textarea I put “Test REPLY rule”

In Plugin Information, the values saved to the DB for that tab show:

s:16:"topic_rules_text";s:15:"Test TOPIC rule";
s:16:"reply_rules_text";s:15:"Test TOPIC rule";

Refresh the Topic/Reply Form and sure enough, it shows the duplicate “Test TOPIC rule” and “Test REPLY rule” is nowhere to be found.

Manually change the bad value for reply rules back to “Test REPLY rule”, and then it finally saves it properly.

If I reset the settings, I can consistently duplicate the issue. But once settings have been saved and then re-saved, it behaves properly.

Still digging to find the culprit, but at least it’s narrowed down to the initial saving of the options for that tab.

@metesey – Until this is officially fixed, my advice as a temporary work-around still stands: Try re-saving that tab, and maybe adjust values before re-saving.

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

Gotcha. Loud and clear now.

What you want is wp-core modifications. Well beyond the scope of Style Pack. Looking at the core-track for WP, I see you’re already all over it:

https://core.trac.ww.wp.xz.cn/ticket/47218

My input just from reading that thread and comparing changes from v4 to v5 or v6:

1.) I think the biggest issue is backward/forward compatibility. It’s as much TinyMCE’s fault as it is WP’s fault. WP went above and beyond to provide backward/forward compatibility between v3 and v4. It would be a HUGE undertaking to also extend that to make sure WP plugins written for v3 or v4 also work with v5 and v6. If TinyMCE provided internal backward compatibility, then it wouldn’t be an issue and WP would adopt newer TinyMCE versions quickly.

2.) WP seems to really be reaching for Gutenberg / block editor enhancements and wide-scale adoption, while gradually trying to phase out classic editors in the process, especially TinyMCE. With that in mind, it’s a really hard sell investing a ton of time into the compatibility issues mentioned in #1 above for something that’s a very low priority.

It’s beyond my skill-set and available time to take on a project of that size, but I’m certainly going to look at https://github.com/ClassicPress-research/ClassicPress-Editor and see if it’s realistic/practical/stable to allow the use of a newer version that overrides the default WP v4 (without breaking all current WP plugins written for v3 / v4).

Can you give me one (or more) specific examples of what you would like to see or be able to change with the TinyMCE Toolbar?

I ask because the default TinyMCE used in bbPress & Style Pack can pretty easily be extended with a few initialization arguments like:

args['tinymce'] = array('toolbar' => 'formatselect );

That example would initialize the TinyMCE editor with the font formatting selection drop-down as the ONLY button, and all other buttons removed.

On the opposite end of the spectrum is adding all kinds of buttons to the toolbar. Here’s a picture of the supercharged Topic/Reply TinyMCE toolbar on my personal site:

That’s just using some custom code hooks/filters against the existing TinyMCE editor to add all kinds of default buttons, and even integrating shortcodes from other plugins, smileys, a format highlighting code block, and all kinds of extra, unnecessary, useless junk that no one’s ever going to use. Why? Not really sure, but I did it anyway. 🙂

Honestly, most of what I did in the picture above, and probably anything that MOST PEOPLE would want can be accomplished with “the plugin formerly known as TinyMCE Advanced“, and it works with bbPress & Style Pack. Yeah, it hasn’t been updated in a while, but it still works fine (for now).

That’s kinda why I’m asking for examples of what you want. If there’s no real suitable options available and it serves a purpose that fits within the intent/scope of Style Pack, then I may be up for adding it.

Ever since 5.3.0, I have a “oh no, what else did I break” freak-out moment every time a new support topic pops up now. 🙂 While this particular support topic had nothing to do my code submissions, I have a vested interest in the plugin and don’t want any lingering issues if they can be helped.