@Jonathan – Since you’re actively testing and tweaking things, I feel like it might make more sense for you to continue using the SVN checkout or plugin zip file from Trac. Fixes are going in nightly as reports come in, so some of what you’re experiencing might be already be addressed.
@tooltrainer – The “quick solutions” are still no reason to modify core files. Trust me when I say, and stress, very heavily, that modifying the core files is only going to cause headaches.
@jamesmarsland – Timeline is probably July or August. Right now you can run them together, and turn off the BuddyPress forums component, and things will work perfectly. Here are a few scenarios:
1. Install bbPress 2.0. Keep both BuddyPress and bbPress 2.0 active. Have two separate, disconnected forums. One using the same old way with group forums, the other specifically for your site. This is how I am currently running http://testbp.org.
2. Ditch BuddyPress Group Forums, and don’t allow new groups to create forums. Use the bundled import tool in bbPress 2.0 to move your existing group forums into bbPress 2.0, and systematically/manually edit each forum down so everything lives where you want it to.
3. Wait until we’re able to update BuddyPress to talk directly to bbPress 2.0, and take control of it like it does now with bbPress 1.0.
Ideally BuddyPress will come with a very generalized “forum” component in the next version, that will act as an API for any forum software to connect to it. There are only a few functions that it needs to use, so it shouldn’t take too long to switch up.
@bkno – @powerspawn is asking about bbPress 2.0, so those plugins won’t help him.
@powerspawn – Right now you’ll need to write a piggyback plugin for bbPress, that will add the read_private_forums capability to the roles that you want to have it.
Interesting. Looks like it thinks a function is missing, or some other plugin is interfering with the output of the page. Do you have any other plugins running? What version of bbPress 2.0 are you using?
Will be fixed in the next release.
Created a new default title length option, and set it to 80 as default.
I can guarantee you with 100% confidence that a bbPress plugin update alone will *never* nuke any files outside of the /wp-content/plugins/bbpress/ folder. 
When you update any WordPress plugin through the auto-updater, it deletes the plugin folder, recreates it, and puts the contents of the new version in there; that’s it.
Hidden fields look fine to me.
What happens if you choose to include the forum base slug in your permalinks? Are you able to post then?
Is it possible that the content you’re attempting to post is the *exact* same as the content of another post in that same topic? I noticed in your video that the template notices that are normally in the reply area have been removed in your custom theme. That means if the duplicate post is being caught, you’re not getting any feedback notices.
Good info. Thanks for sharing that. I imagine there will be other framework style themes that do some custom hijacking like that too.
@Jonathan – Do you have a folder in your install named ‘forums’ that might be conflicting? Do you have BuddyPress installed and is it using the default ‘forums’ slug for its forums component? Did you do any rewriting in your .htaccess file regarding the forums slug? Have you tried visiting your permalinks settings and resaving them to see if something is just out of alignment?
@Jonathan – No. You should *never* modify core files, ever. If you’re modifying the core, you should share what you’re changing and why, so someone can show you a better way, or we can improve the core. If you’re creating a custom theme based on the core files, then until 2.0 drops you’re on your own to monitor the traclog and see what changes might impact you.
When are adding your theme compatibility? If you are hooking in on the ‘init’ or ‘wp’ actions, then it is too late for theme compatibility to pick it up.
function anointed_theme_setup() {
add_theme_support( 'bbpress' );
}
add_action( 'after_setup_theme', 'anointed_theme_setup' );
Can you confirm the bbpress.css is inside the bbPress plugin directory and bbp-twentyten theme?
If it wasn’t working at all, then your custom theme’s bbPress template files wouldn’t be getting loaded either.
@Johnathan – Can you use a tool like Firebug or Inspector, and look at the hidden input fields in your reply form?
Should look like the following
<input type="hidden" name="bbp_reply_title" id="bbp_reply_title" value="Reply To: Updated to bbPress 2.0 pre-beta 2" />
<input type="hidden" name="bbp_forum_id" id="bbp_forum_id" value="138" />
<input type="hidden" name="bbp_topic_id" id="bbp_topic_id" value="439" />
<input type="hidden" name="action" id="bbp_post_action" value="bbp-new-reply" />
<input type="hidden" id="_wpnonce" name="_wpnonce" value="0b78bb87eb" />
<input type="hidden" name="_wp_http_referer" value="/discussion/topic/updated-to-bbpress-2-0-pre-beta-2/" />
Also, some details about your configuration would be great. WordPress version, Multisite/single-site, custom theme/theme compatibility, etc…
There’s absolutely no way that bbPress is responsible for doing anything inside your wp-content/themes/ directory. If you made changes to files inside the bbPress plugin folder, then you broke the first rule of using a WordPress plugin.
Throttle means that user has the ability to bypass the configured posts-per-time-period limit.
The sanity check that I do in the breadcrumb is to check if the root slug is being included in the forums or not. If there’s no root slug, in the URL, then there’s no definitive breadcrumb that bbPress could know about. My logic may still be flawed here though.
You could use something like Firebug or Inspector to monitor the requests and see what’s causing the delay.
You can manipulate the inclusion of the links on customized setups (such as the one I know you have.) Check out the plugin code and adjust it to suit your needs in your custom theme.
When 2.0 goes gold, we’re committed to the code and functions that ship with it. So some objects might shift during shipping.
Yes definitely. No one has reported this yet either. I’ll take a look right away.
Ah ha. That’ll do it. WordPress doesn’t have built in collision detection for these manually entered slugs. Mind creating a trac ticket and I’ll look into preventing this in the next release.
If you aren’t able follow the instructions provided, these kinds of things will happen. Revisit what you couldn’t do, and that should alleviate your woes. Hint: the functions.php code is also responsible for enqueueing the CSS.
If you aren’t able follow the instructions provided, these kinds of things will happen. Revisit what you couldn’t do, and that should alleviate your woes. Hint: the functions.php code is also responsible for enqueueing the CSS.
That function was removed and merged with another that did essentially the same check. The standard bbp-twentyten theme files won’t have this problem.
You’ve just experienced first hand why it’s best to use the built in theme compatibility if, particularly if you’re not a developer that keeps up with the code changes.
Please don’t bump topics here, especially when it’s still on the front page in the top ten topics.
Curiously I have testbp.org setup to use the same slug for blog tags and topic tags, and see no issues.
