codejp3

@neofilm and @markballard – check the theme compatibility settings @robin-w mentioned. If your theme is a FSE theme, the issue may be resolved without any code changes by enabling compatibility.

@neofilm – I looked at your site link on my phone and you may also want to add some kind of color to the mobile nav menu dropdown. It’s transparent right now and very hard on the eyes. View your site on a phone to see what I’m talking about.

I was wrong about the root cause of the issue. It isn’t bbPress, it’s WP core. I can’t even call it an issue either. Prior to WP 6.5, there were no issues with overwriting the textdomain of one plugin within another plugin. Now, WP core is enforcing textdomain limitations that prevent that overwriting. It’s actually a good thing that they’re doing that now, and not an actual problem.

The code change removes the bbpress textdomain, loads bbp-style-pack textdomain, and then re-registers bbpress textdomain and assigns it to the actual bbPress plugin language files. That takes care of the new textdomain handling limitations in WP core.

There are many other language changes I see should be made, plus new mo/po/php/json file generations, and that’s a pretty big update for just getting translations straight.

I’ve been the primary one handling translations, and I’ve been absent from plugin development and support for many months. Blame me for this issue going on for as long as it has.

Glad to hear your issue is solved.

@maksanse – Robin was on the right track earlier. Part of the recent WP core updates has made major changes to how translations are handled. I’ll probably release a major translation overhaul in the near future, but I believe this will hold you over until then:

In Style Pack 5.9.4 (latest version),

/bbp-style-pack/bbp-style-pack.php starting line 95:

Chang this function from this:

function bbp_style_pack_init() {
        load_plugin_textdomain('bbp-style-pack', false, basename( dirname( __FILE__ ) ) . '/languages' );
        //load the plugin stuff
        bsp_load_plugin() ;
}

To this:

function bbp_style_pack_init() {
    	unload_textdomain( 'bbpress' );
        load_plugin_textdomain('bbp-style-pack', false, basename( dirname( __FILE__ ) ) . '/languages' );
    	load_plugin_textdomain('bbpress', false, 'bbpress/languages' );
        //load the plugin stuff
        bsp_load_plugin() ;
}

This will allow bbPress translations that exist to be used (instead of Style Pack). If you have a custom translation file for bbPress within Loco Translate, then that custom file will be used. bbPress is updated far less often then Style Pack, and strings rarely change, so that should make translation issues far less frequent for you an others in the future.

I’m still looking into all the recent translation changes with WP core, but that should be an immediate fix for you until we include translation fixes in a future release.

There were some major translation handling changes in release 6.5 of WP core:

https://core.trac.www.ads-software.com/ticket/59656

It mentions using php files for translations instead of po/mo files whenever possible. I don’t see the exact issue listed there, but there have been many translation issues that have popped up since that change. May not be the cause, but just something that stood out as a possible cause. I’ll keep digging.

I’ll add another oddity to the mix:
I have a multisite test site for testing purposes as well. There are zero translation issues that I can find on the multisite install. The issues seem to only exist on the standard single site WP install. Hmmm. Strange.

@robin-w – Sorry for my long departure. Email coming your way soon. I’ll keep looking into this issue since it’s a pesky time-consuming one.

@maksanse – I think the issue may be a bbPress issue. I have a dev site with every version of Style Pack since version 4.8. I’ve tested 5.5.1 and previous versions and still had the issue you described. I disabled style pack completely so it’s only bbpress and loco translate and the “Notify me of follow-up replies via email” string does not get translated. Many other strings are also not translated. That’s with Style Pack disabled and a non-factor in the issue.

Loco Translate shows there is a string translated that could/should be used, but the default English string shows instead. I get the same results whether I use the system FR translation file, or a custom FR translation file.

The issue persists even with just bbPress activated an both Loco Translate and Style Pack disabled.

As far as I can see, the issue is with bbPress, and may have to do with recent WP core updates. I’ll keep digging to see if there’s anything we can do in Style Pack to fix this, but I don’t see it as a Style Pack issue.

Smileys are not part of the default TinyMCE.

They can be added to TinyMCE with plugins.

If you just want smileys and nothing else, look into the WP Monalisa plugin:
wp-Monalisa – WordPress plugin | www.ads-software.com ?????? (Emoji)

If you want more control beyond just smileys, I recommend the Advanced Editor Tools (formerly TinyMCE Advanced) plugin:
Advanced Editor Tools – WordPress plugin | www.ads-software.com ?????? (Emoji)

UPDATE:

I’ve resorted to using the GPL version of BuddyBoss from GitHub.

So far what I can see is that there is quite a few differences between BuddyBoss and a bbPress/BuddyPress site.

With that said, there’s going to be lots of things in Style Pack not compatible with BuddyBoss. Anything in BuddyBoss that uses the standard bbPress/BuddyPress code will work fine with Style Pack. Anything that deviates away from the bbPress/BuddyPress code will probably not work with Style Pack.

In order to make Style Pack 100% compatible with BuddyBoss, we’d have to test every single feature against it, and likely do a large amount of code edits. I’m not sure that makes sense at the moment.

I can see the Quotes are not working because BuddyBoss uses a different layout/elements for the Topic Reply form. I will look into it and see if there’s a way to make quotes compatible with BuddyBoss that makes sense.

That’s only addressing ONE incompatibility, and the more you use BuddyBoss/Style Pack together the more incompatibilities you will find.

We can try to address incompatibilities as they are discovered, but I’m not at a point where I can take on a major code re-write to offer full BuddyBoss compatibility.

I’ll get back to you on the quotes issue. If you discover any other “must-have” Style Pack features not working, post them here and I’ll look into those as well.

I’m going to mark this as resolved, but feel free to post any questions or issues you may have with limiting forum access to search engine spiders.

OK. I’m following you.

What @robin-w posted should do the trick.

1.) You’re manually creating a menu link that points to a generic “/profile/” URL. You should be able to place that anywhere in the menu you want, so that should take care of the menu order issue.

2.) You’re using the User Menus plugin to make that specific menu item only visible to logged-in users.

3.) You’re using the code snippet to intercept “/profile/” URLs, and redirecting them to the actual user profile page for that current logged-in user.

If the “Your Profile” link is being dynamically generated, you need to disable that auto-generation and use steps 1-3 above.

If you still run into issues with that, there are alternatives methods that can achieve the same thing, such as creating a shortcode that displays the “Your Profile” link and allowing shortcodes in nav menus. What @robin-w posted is an easier and more lightweight way to accomplish it though.

Perfect. I’ll mark as resolved. Thanks for checking back in!

@bergblume – I’m still waiting to hear back from BuddyBoss on this. If it takes longer than a few more days, you may want to reach out to them with your paid support, send them the link to this topic, and have them check their emails for the one I sent to them a week ago.

Can you also go to wp-admin > Settings > Style Pack > Plugin Information ( /wp-admin/options-general.php?page=bbp-style-pack&tab=plugin_info ), scroll down to the raw setting values towards the bottom and copy/paste the row for:

Dashboard Admin
bsp_settings_admin

• This reply was modified 1 year, 3 months ago by codejp3.

@saip1540 – I just want to verify that:

1.) The “Create New Topic” button is showing as expected, but when you click it, nothing happens? It doesn’t scroll down to the actual form?

2.) If it is displaying, is it showing as a stylized button, or a generic default link?

3.) At the bottom of all forums (not categories, just specifically forums that actually have topics within them) you’re saying there is no “Create New Topic” form shown at the bottom under the forum topic listing?

Can you do me a favor and go to wp-admin > Settings > Style Pack > Plugin Information ( /wp-admin/options-general.php?page=bbp-style-pack&tab=plugin_info ), scroll down to the raw setting values towards the bottom and copy/paste the 2 rows for:

Forums Display
bsp_forum_display

&

Forum Buttons
bsp_style_settings_buttons

@hamadkhalid07 –

If I’m not mistaken, you should be able to do that with the plugin @robin-w mentioned: https://www.ads-software.com/plugins/user-menus/

The order you add that “My Profile” link to the menu is the order it will be displayed.

If you want it before “Logout”, then move it to before “Logout”

If the “Logout” link is dynamically generated elsewhere and not actually in the menu items, then disable it wherever it’s getting generated from, and manually add a “Logout” link to your menu items and point it to:

/login/

Or use a plugin like “Login or Logout Menu Item” for more options with the ability to add login/logout links to the menu: https://www.ads-software.com/plugins/login-or-logout-menu-item/

Unless I’m missing something, it really should be that easy.

Style Pack does not add or take away SEO for the forums. Maybe one day, but not currently.

The easiest way to block search engines is with the robots.txt file in your site root folder. Not all search engines will honor your settings there, but most of the big/common ones do.
https://moz.com/learn/seo/robotstxt

A more precise method is to create a custom function that blocks search engines based on their user-agent string. You will have to specify every user-agent string you want blocked, but those user-agents will be blocked consistently. You will have to create a WordPress-friendly function to redirect them to a specific page or display a message to them, and to make it apply exclusively to the forum.
https://blog.sucuri.net/2020/08/web-crawler-user-agent-blocking-techniques.html

A layered approach using both of those techniques above will be the most effective.

Alternatively, you could just set all of the forums to private, which will accomplish the blocking of search engine crawlers, but guests will have to login to see the forum too.

Hope that helps put you in the right direction!